Mail Archives: djgpp/1994/10/09/19:56:48
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
- Raw text -