Xref: utzoo comp.lang.c:23781 comp.unix.xenix:8582
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!ateng!chip
From: chip@ateng.com (Chip Salzenberg)
Newsgroups: comp.lang.c,comp.unix.xenix
Subject: Re: Separate data and function address spaces
Message-ID: <25644B00.161@ateng.com>
Date: 17 Nov 89 18:16:30 GMT
References: <25604050.26537@ateng.com> <935@fiver.UUCP>
Organization: A T Engineering, Tampa, FL
Lines: 29

According to palowoda@fiver.UUCP (Bob Palowoda):
>According to chip@ateng.com (Chip Salzenberg):
>> Unlike SysV, SCO Xenix/286 and Xenix/386 versions 2.2 and 2.3 create
>> disjoint code and data segments.  The exceptions are called "impure"
>> binaries.  I've never seen impure binaries except for the '286/186/8086,
>> and such 16-bit binaries limit code and data to a total of 64K.
> 
>   Does this mean the the 386 version (a 32bit version of Xenix) has 
>limitations on huge array sizes?  I was under the impression that the
>386 version of Xenix C compilier was a non-segmented 32bit compilier 
>in all respects.

Not quite.  As long as a program runs on a '386 it is "segmented", since the
'386 uses segments for all memory references.  However, since small model on
the '386 (one code segment, one data segment) provides 4G of code and 4G of
data, no one bothers with the more complicated models.

To state plainly what I described in convoluted way above:

	'286 tiny model         code+data 64K, executable data
	'286 small model        code 64K, data 64K, no executable data
	'386 tiny model         code+data 4G, executable data
	'386 small model        code 4G, data 4G, no executable data

It seems that SysV/386 uses tiny model, whereas Xenix/386 uses small model.
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>
    "Did I ever tell you the Jim Gladding story about the binoculars?"