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

David L Moore <dlmoore@ix.netcom.com> wrote:
>> [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. ...


In the default flat memory model it will use GS. FS and ES are not alterable.
ES is assumed to have the same value as DS, and FS just has some value that
we can't touch. This is because some operating systems (NT, OS/2) use FS to
point at thread specific data and get _highly_ irate if the compiler fiddles
with the value. If you were to actually compile something for large memory
model, the compiler would use all three (and DS as well) for far pointer
operations (large model versions of the C library aren't included in the
package, but I've heard some embedded systems people have done it).


Since the compiler started out life for a 16-bit X86 target and we had to
implement the far pointer garbage for that anyway, it wasn't that big of a
deal to keep it in the 32-bit version (we needed the far pointers for the
DOS extender environments anyway).


>[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]


It is a major pain in the butt. We try to treat the segment and offset
portions of a pointer as seperate items as much as possible. That helps
us track when the segments are the same, but stores into memory tend to
invalid the values that have been cached in the segment registers and force
reloads.


The other thing about the segment registers that's a major hassle is the
way they fault the program as soon as you load an 'invalid' value in them,
rather when you attempt to use the invalid value. Attempting to preload a
value into a segment register can't be done until you can prove that all
possible execution paths will actually use that value as a segment. It also
means that you can't attempt to preserve segment registers across a function
call because the selector value might be freed by something in the function.
--
Brian Stecher
brian@watcom.on.ca
Watcom International Corporation
--

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