chip@ateng.com (Chip Salzenberg) (11/15/89)
According to cpcahil@virtech.uucp (Conor P. Cahill): >According to chip@ateng.com (Chip Salzenberg): >> The '286 and '386 processors, in protected mode, do not permit >> program execution from any data segment. This restriction can be >> bypassed only by the subterfuge of pointing two segment descriptors >> at the same piece of memory. > >I don't know what unix you are using... Conor then proceeds to describe how "real" SysV for the '386 actually does perform the two-descriptors-pointing-at-the-same-memory trick. 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. Incidentally, Xenix/386 2.3 can execute COFF binaries without conversion. Perhaps Xenix would give them executable data... -- 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>
palowoda@fiver.UUCP (Bob Palowoda) (11/16/89)
From article <25604050.26537@ateng.com>, by chip@ateng.com (Chip Salzenberg): > According to cpcahil@virtech.uucp (Conor P. Cahill): >>According to chip@ateng.com (Chip Salzenberg): [some stuff deleted] > 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. Other than the 32bit int's pointers etc. What are the other features that are different than the 286 version of the Xenix compilier? ---Bob -- Bob Palowoda pacbell!indetech!palowoda *Home of Fiver BBS* login: bbs Home {sun|daisy}!ys2!fiver!palowoda (415)-623-8809 1200/2400 Work {sun|pyramid|decwrl}!megatest!palowoda (415)-623-8806 2400/9600/19200 TB Voice: (415)-623-7495 Public access UNIX XBBS
chip@ateng.com (Chip Salzenberg) (11/18/89)
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?"