Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!vsi1!altnet!ernie!koll
From: koll@ernie.NECAM.COM (Michael Goldman)
Newsgroups: comp.unix.wizards
Subject: Re: Data in text segment
Summary: 8088/86 vs 80x86 I & D segments
Message-ID: <169@ernie.NECAM.COM>
Date: 20 Oct 88 16:00:15 GMT
References: <159@taux02.UUCP> <7124@rpp386.Dallas.TX.US> <10420@tekecs.TEK.COM> <7599@rpp386.Dallas.TX.US>
Organization: NEC America RATS, San Jose, CA
Lines: 27


This is just to point out that the 8088/8086 does not distinguish
sufficiently between code and data (or stack) segments to make
any real difference in your programming.  I know because I
have over-written code with data and my stack has overflowed
into my code and or data segments at various times (stupid pointers !)
The 80286 and 80386 on the other hand do have complex but significant
distinctions between code and data spaces (when operating in protected
mode - i.e., not emulating an 8086) and, in fact, have 4 layers of
protection, modeled on UNIX I'm told.  One can designate all kinds
of data/code/stack combos including read only, read-write, and for
all I know, write-only.  The layers correspond to driver, kernel,
shell, and user space ( my own very rough approximation) with all
sorts of "layer N can call to layer M but only through layer K"
restrictions.  The idea is to put into hardware a lot of UNIX type
stuff to speed up context switching, and enforce system integrity.
OS/2 does not use all the features provided but I have no knowledge
of whether 286 or 386 UNIX(tm)s do.  It all makes life much more complex
if you like to work in assembly, and/or close to the hardware but
it probably cuts in half the context-switch timings.

"I have some advice for you, son on going your own way in life.
 Wait, where are you going ?"

Regards,
Michael Goldman
:w