Date: Sun, 9 Oct 1994 23:22:06 +0100 (MET)
From: Alexander Kjeldaas <astor AT ild DOT alkymi DOT unit DOT no>
Subject: Re: 32/16bit?
To: Mailing List DJGPP <djgpp AT sun DOT soe DOT clarkson DOT edu>



On 10 xxx 1994, Bryan Pendleton wrote:

>  
> Well, but, I think part of the problem is using a 16-bit integer in an
> otherwise 32-bit program makes it necessary to change a couple of things
> on the processor before and after handling it, each time.... which is
> where the extra cycles come in...
>  

I think you are mixing different things here.

 There is nothing you have to 'change' on the processor to use 16 and 32 
bit operations. The extra cycles you mention come if you have to switch 
between protected mode and real mode - in DJGPP usually for calling MS-DOS 
services

Btw: Here is what my Turbo Assembler 3.0 Quick Reference Guide tells me:

486:

add r8,r8   1 clk
add r16,r16 1 clk
add r32,r32 1 clk

...and 1 clock for all other simple operations..(NOT,AND,SUB,OR,MOV,CMP..)

div r8     16
div r16    24
div r32    40

idiv r8    19
idiv r16   27
idiv r32   43

imul r8       13-18
imul r16,r16  13-26
imul r32,r32  13-42

and similar for the mul instruction

All these instructions are available both in real mode and protected 
mode (although they are coded differently) and take just as long to 
execute regardless of which mode the processor is in. 

So using 32 bit interger atithmetic has nothing to with protected mode. 
GCC should optimize 'down' to using 16 or 8 bit instructions if it can.

Ex.
  i &= 0xfffffff0 

should be coded as an 8-bit operation: 
	and al, 0f0h
which is 2 bytes long and takes 1 clock cycle instead of 
	and eax, 0fffffff0h
which is 5 bytes long taking 1 clock as well.


A mix of 8,16 and 32 bit operations can if not increase the speed of 
the program reduce the size of the executable. I don't know how good 
DJGPP is at this, but an expert in the field is the WATCOM C++ compiler. 
It produces protected mode programs and usually makes my programs 2x 
faster than borland and somewhat faster than GCC. Another thing is that 
it produces the smallest executable and I think part of the reason is 
that it doesn't always use the 32 bit instructions.


Astor