GNU gcc/g++ with 386 segmented architecture.
Martin G C Davies
I have asked the question below in gnu groups but got no reply so am posting
here in case someone has been tried before who no longer looks at those
group.
The delivered GNU gcc/g++ 386 support only works in a flat architecure i.e.
pointers are 32bit (just a base/index/offset) so DS is always used as the
segment.
I would like gcc and g++ on an Intel 386 but with a segmented architecture
i.e. pointers are 48 bits (a segment (DS/ES/FS/GS) and a base/index/offset).
I have had a look at the document "Using and Porting GNU CC" and there seems
to be no mode that I can use for such a pointer e.g. SImode, PDImode,
BLKmode etc.
Is it possible to do this and, even better, has anyone done it?
Any help or suggestions would be very useful (even if the answer is "it
can't be done").
--
= Martin G C Davies BSc CEng MBCS | Internet: mg...@se.bel.alcatel.be
* Richard Daley Associates | Phone: (44) 1279 830 141
= 100 Elmbridge, Churchgate Street | Fax: (44) 1279 758 550
* Old Harlow, Essex, CM17 OJU |
= England
*
= Working for:-
* Alcatel Bell (Dept. VE141)
= F. Wellesplein 1 | Fax: (32) 3 240 99 50
* B-2018 Antwerpen
= Belgium
[GCC believes very strongly that its target machine has a flat address space.
It may be doable, but it'd be a huge project. I've never seen a C compiler
that did 386 large model. Are there any? -John]
--
Send compilers articles to comp...@iecc.com,
meta-mail to compiler...@iecc.com.
James Kanze US/ESC 60/3/141 #40763
The moderator writes:
> [I've never seen a C compiler that did 386 large model.
> Are there any? -John]
The one from Intel handles compact, at least, with 48 bit pointers to
data. It's worth noting that in this compiler, pointers are larger
than the largest integral type, which seems to bother some people.
--
James Kanze Tel.: (+33) 88 14 49 00 email: ka...@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
bill.w...@gecm.com
den...@netcom.com (Dennis Yelle) writes:
> Please tell us why you want to [use 386 segmented addresses].
> Do you have more than 4GB that you want to point at?
The moderator natters:
> [The Intel architecture doesn't handle more than 4GB, segments or no, because
> everything is mapped into the 32 bit linear address space. But there are
> environments where you've already got segmented data and your code has to
> deal with that. -John]
One example that I came accross recently is operating system code. If
you're writing scheduler code, memory manager code, I/O driver code,
you frequently have to deal with the segment architecture on the x86
processors. The only workaround is to put lots more assembler than I
am really comfortable with as a potential inspector of other people's
code:-)
Bill
--
Bill Williams
GEC-Marconi Research Centre
bill.w...@gecm.com
Tel: +44 1245 242016
Fax: +44 1245 242003
David L Moore
> [I've never seen a C compiler that did 386 large model. Are there any? -John]
Watcom V10.5 (the latest but .1) says it does 48 bit pointers in the online
documents and goes on to describe why you may need to use them. I have not
actually tried them.
I like Watcom. They treat their users like they have a clue. I reported two
small bugs and one they have already fixed while they got back to me when
they could not reproduce the other. Their IDE is still a bit primitive (this
may be fixed in 10.6, which I do not yet have), but at least it is nice and
quiet. The last thing I want in a compiler system is an IDE that runs back
and forth across my keyboard and says "pet me".
pa...@3dfx.com
[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.
Sam Paik
--
Samuel S. Paik / pa...@3dfx.com / 415-919-2441 / I speak only for myself
David L Moore
> [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]
Brian Stecher
David L Moore <dlm...@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
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
br...@watcom.on.ca
Watcom International Corporation
Sean Eric Fagan
>I would like gcc and g++ on an Intel 386 but with a segmented architecture
>i.e. pointers are 48 bits (a segment (DS/ES/FS/GS) and a base/index/offset).
>that did 386 large model. Are there any? -John]
I know of gcc ports to segmented architectures; the z8000 is one of those, I
believe.
For the 386, there is, however, no real point -- the 386 (and later, of
course) only handle 32-bits worth of memory. The segments take
segment:offset and translate it to a logical memory address (32-bits worth),
and then pass that off to the MMU. It is not possible, as a result, to have
multiple 4Gbyte segments in the machine, and each segment that you *would*
have would have to be restricted to a contiguous real address space. If it
were possible to associate pages with a segment identifer, then, well,
things would be quite different ;).