Re: GNU gcc/g++ with 386 segmented architecture.

> [John: C compiler that did 386 large model]
>
> [Dave: Watcom V10.5 claims it does them]
>
> I've used far pointers in Watcom 10.5. They work, but while I
> haven't gone and disassembled the generated code, they seem to
> be very slow. Some code we have here which interfaces to some
> hardware runs at about 1/2 performance when the hardware is
> mapped through far pointers instead of near.


That is interesting. If you are in a tight loop accessing the hardware (so
that pointer operations are a large part of the total code) I am not
hugely surprised. It would be interesting to know if the compiler is
using FS/GS or if it is just thrashing ES. I believe that
segment register loads used to be slow in this mode because they are
selectors and the corresponding address has to be looked up. If this
is still the case on later processors (eg Pentium), and the compiler cannot
schedule or hoist the segment register loads, you are going to take a
significant hit. [Then there is the issue of register pressure ... ]


Thanks for the information.


David L Moore.
[Loading a protected mode segment register is slow on every '86 processor
with which I am familiar, since there's so much baggage that goes with
the selector. I'd think that optimizing segment loads would be tough, since
you'd have to do a lot of inference about what pointers would share the
same selector. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.