segments and Unix

Tom Kohrs tomk at intsc.UUCP
Thu Nov 20 13:44:00 AEST 1986


> This is (if I understand correctly) exactly what happened in the object
> oriented environment of the Intel 432 processor.  Each data (and code)
> object could only be accessed in the appropriate context.  All objects not
> explicitly referenced in the current execution context where turned off,
> and would cause a detectable fault.  
 
This is a correct assumption.

>                                      The problem with doing this on a
> 286, for instance is again the extreme overhead necessary to set up
> (or check access permissions) on each data reference. 

In the 286 the hardware takes care of the overhead associated with checking
the access writes.  The time to do this is hidden in the pipeline.

>                                                        It is also not
> a general solution on a 286; you can run out of segments too quickly.

16K segments is a lot to run out of. Typical of what is done in a segmented
programming environment is to give each array its own segment and lump all 
of the single element variables together in one segment.  From a c portability
issue it can be hidden from the programmer by the compiler using the 14 bit
segment pointer as the base of the variable, the offset is the index.  Of
course programmers that try to index into an array off of the base address
of an adjacent array will get in trouble (nobody writes code like that do
they? (:-) ).   What you run out of on the 286 is bytes in a segment,  the 
386 should fix that, though I sure somebody is going to come back and complain
about crippling 4GByte segments.

> It was the overhead (and the general confusion about how you programmed
> object oriented hardware) that killed the 432 off. 

The confusion (fear) about object oriented programming is probably what
will shy programmers away from segments in the 386 for a long time.
-- 
------
"Ever notice how your mental image of someone you've 
known only by phone turns out to be wrong?  
And on a computer net you don't even have a voice..."

  tomk at intsc.UUCP  			Tom Kohrs
					Regional Architecture Specialist
		   			Intel - Santa Clara



More information about the Comp.lang.c mailing list