Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!spdcc!dyer
From: dyer@spdcc.COM (Steve Dyer)
Newsgroups: comp.unix.xenix
Subject: Re: 386 Unix/Memory Models
Message-ID: <295@spdcc.COM>
Date: Thu, 8-Oct-87 00:05:38 EDT
Article-I.D.: spdcc.295
Posted: Thu Oct  8 00:05:38 1987
Date-Received: Sat, 10-Oct-87 16:38:43 EDT
References: <143@conexch.UUCP> <140@turnkey.UUCP>
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Lines: 23

This may be picking nits, but:

In article <140@turnkey.UUCP>, jack@turnkey.CTS.COM (jack) writes:
> Also, there is only one memory
> model, large (all segment registers, and hence pointers are now 32 bits wide).

XENIX 386 has only one memory model, SMALL (actually, split I/D).  There are
no explicit loads/reloads of segment registers within user code generated by
the C compiler.  All pointers are 32-bits wide, which reflects the native size
of the 386 general (cough) registers.  "Large" model on the 386 would require
48-bit pointers, with 32-bit offsets and 16-bit selectors.  Needless to say,
there are many benefits to be had when it comes to porting code from machines
like the VAX and 68K family by having pointers and ints the same size.

But, yes, it's true.  No more segmentation headaches.  It's like dying and
going to heaven.  Linear addresses everywhere.  Programs which didn't have
a chance of working now "just compile and run".  Of course, XENIX 386 provides
the ability to generate and run 286 binaries, so if you ever want to remember
your "roots", it's just a compiler flag away.  Not me, buddy...
-- 
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer