Mail Archives: djgpp/1994/10/14/06:05:10
Delivery-date: Tue, 11 Oct 1994 13:53:49 UTC+0200
From: <cnc AT netcom19 DOT netcom DOT com>
To: <djgpp AT sun DOT soe DOT clarkson DOT edu>
Message-ID: inbox:509
Subject: Re: 32/16bit?
>X-Mailer: Mail User's Shell (7.2.5 10/14/92)
>This is incorrect. If you refer to the Intel processor manuals for the i486
>and Pentium processors, you will find that when an instruction with 16-bit
>operands exists in a 32-bit segment, it requires an OPERAND SIZE prefix.
>The same is true for 32-bit instructions in a 16-bit segment. This OPERAND
>SIZE prefix is 1 byte long and takes 1 clock cycle to decode on both i486
>and Pentium processors. This means that for simple instructions like ADD
>or MOV which normally take 1 clock cycle, using the wrong bitness will DOUBLE
>the execution time of that instruction. The upshot of all this is that for
>time-critical code, you should use 32-bit instructions in 32-bit segments and
>16-bit instructions in 16-bit segments. Since djgpp executes all of its
>code in 32-bit segments, this means you should avoid 16-bit operands like
>the plague. Avoid the "short" data type when reasonable.
>Christopher
that would explain why a program i made takes 30 seconds compiled under DJGPP
and 20 with other compiler that doesn't use protected mode. In that program
I make lots of calculations with BYTES. You mean if I replace every where i
put UNSIGNED CHAR for UNSIGNED INT i will get a better perfomance ?
When i get some time i'll do a couple of defines and i'll tell ya whats on !
frankie
- Raw text -