segments and Unix

Mike McNally m5d at bobkat.UUCP
Sat Nov 22 00:20:20 AEST 1986


In article <407 at intsc.UUCP> tomk at intsc.UUCP (Tom Kohrs) writes:
>	[ ... ]
>>                                      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.
>
>  tomk at intsc.UUCP  			Tom Kohrs
>					Regional Architecture Specialist
>		   			Intel - Santa Clara

The protection checks which involve already loaded descriptors are
indeed "free" (ignoring RISCy arguments along the lines that the chip
real estate and hardware sophistication could have been better used in
making instructions faster (and maybe curing my pet peeve, the
affection for AX felt by IMUL) (but I digress)).  However, a scenario
in which each individual object lies in its own data segment would
involve an LDS or LES or something before each reference.  Check your
handy iAPX 286 reference guide and see how long these instructions
take.  A long time, right?  While you're at it, ask your local Intel
rep why it's a bad idea to have too many code segments in a protected
environment.

Don't get me wrong; I like the 286.  I strongly believe that it could
be used to great advantage in a machine like the Macintosh; that is, a
machine which is to run its own custom-designed OS.  Or, if you're so
inclined, I suppose the machine works just fine under iRMX (I'm not so
inclined...I'd like to more directly express my feelings here, but I
can't spell the noise I make when I think about RMX...sort of like
coming into work in the morning, pouring some coffee, taking a sip,
then realizing that you grabbed the wrong pot and got last nights cold
mouldy scum-laden black death...).  Of course, as I look through my
iAPX 386 Programmer's Reference Manual, I get warm feelings when I
think about stacks > 64K...

BUT THE MULTIPLY INSTRUCTION STILL SUCKS.

-- 
****                                                         ****
**** At Digital Lynx, we're almost in Garland, but not quite ****
****                                                         ****

Mike McNally                                    Digital Lynx Inc.
Software (not hardware) Person                  Dallas  TX  75243
uucp: ...convex!ctvax!bobkat!m5                 (214) 238-7474



More information about the Comp.lang.c mailing list