Path: utzoo!mnetor!uunet!mcvax!ukc!stl!stc!idec!alice!fox
From: fox@alice.marlow.reuters.co.uk (Paul Fox)
Newsgroups: comp.unix.microport
Subject: Re: --- GCC on an iAPX286 (?) ---
Message-ID: <329@alice.marlow.reuters.co.uk>
Date: 20 Apr 88 12:03:45 GMT
References: <435@zap.UUCP>
Reply-To: fox@alice.UUCP (Paul Fox)
Organization: Reuters Ltd PLC, Marlow, Bucks, England
Lines: 43

In article <435@zap.UUCP> fortin@zap.UUCP (Denis Fortin) writes:
>
>All that is required in order for software to believe that the '286 is
>a 32-bit machine is a C compiler that makes the hardware appear that
>way.  Of course there would be a performance penalty to pay, but when
>the choices are to either run a large program somewhat slowly or not
>run it at all, I don't really think it matters all that much!  Besides,
>those trusty little old Z-80s and 6502s in the 8-bit micros have been
>emulating 16-bit integers on 8-bit machines for years (:-).
>
Your basic premise is correct. The Large model 286 compilers attempt to
give the C programmer a virtual 32-bit environment. The problem that
crops up is that say we have an address: 0x4700:0xFFFF (seg = 47, offset =ffff)
there is no 'next' address. On a 32-bit machine the next address would be
0x4701:0x0000. On the 286 architecture, usually incrementing a 'far' 
pointer would produce: 0x4700:0x0000, since the high 16-bits are
separate from the lower 16-bits. The compiler could treat all 32-bit
addresses as if they were 'longs', and thus generate address '0x4701:0x0000'
but then the problem is that 0x4701:0x0000 is not a valid address. The
286 defines the segment address as 14-bits of segment number (8192 segments)
and two bits of 'protection level'. Thus the '0x4701' refers to invalid
address. The kernel would need to do something about this.

What one normally finds in large model programs is that segments are allocated
in the following sequence: 0x67, 0x6f, 0x77, 0x7f, 0x87, ... Thus
making the compiler 'correct' would not get over the problem of the underlying
o/s. 

Some of the compilers support a 'huge' model abstraction which attempts
to hide the 'funnies' of the acrhitecture. However, not only do 
they have sever limitiations (data structures are limited to powers of 2 
if > 128K , etc), but if you look at the code generated, you will see something
like 30 instructions generated for a single *ptr++ type operation. Performance
is real-real bad.


=====================
     //        o      All opinions are my own.
   (O)        ( )     The powers that be ...
  /    \_____( )
 o  \         |
    /\____\__/      
  _/_/   _/_/         UUCP:     fox@alice.marlow.reuters.co.uk