On Wed, Sep 29, 2010 at 09:15:11PM -0700, H. Peter Anvin wrote:
On 09/29/2010 08:51 PM, Kevin O'Connor wrote:
On Wed, Sep 29, 2010 at 08:19:33AM -0700, H.
Peter Anvin wrote:
That brings up an interesting question. Do you know if instruction
prefixes result in slower cpu execution? I know they bloat the code,
but it's not been clear to me if there is a speed impact (besides a
small cost to insn fetching). Real mode execution is documented to be
slow, but it's unclear if using regular 32bit operations (via
prefixes) would be even slower, the same, or a little faster.
On older processors they do slow down the CPU, on modern CPUs they
generally don't, except for icache footprint, of course.
In general real mode execution is no slower than the corresponding
Sorry - I meant: 16bit code segments are documented to be slow, but
it's unclear if using regular 32bit instructions in them (via
prefixes) would be even slower, the same, or faster.
> BTW, I calculate that prefixes represent 12% of
the seabios 16bit code
> size (4720 of 38920 bytes). I've found the code size with gcc (using
> prefixes) was smaller than the code size was with bcc - largely due to
> the optimizations and improved code structure that gcc enabled.
I worked for a while on a 16-bit gcc backend... I kind
because of perceived lack of interest, and it wasn't fully usable yet,
but perhaps Seabios would be enough of a reason. It seemed to produce
code about 15% smaller than gcc with prefixes.
Oh, yes, there is of course also OpenWatcom, which I
personally had high
hopes for ... and it is quite a good 16-bit compiler, it's just that
I've found the OW community to not always have goals compatible with my
needs, which of course are for a decent cross-compiler.
I don't think either would be worthwhile just to shrink the 16bit code
Granted, the seabios memory macros (eg, GET_GLOBAL, GET_FARVAR,
GET_FLATPTR) are ugly. However, since SeaBIOS handles real-mode,
bigreal-mode, 16bit protected mode, 32bit "flat" mode, 32bit mode with
segments, and 32bit segmented PIC mode, I doubt any normal 16bit
compiler could handle all of these without macros anyway.