Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!cca!ima!johnl
From: johnl@ima.UUCP
Newsgroups: net.micro
Subject: Re: Intel 286 microprocessor problems
Message-ID: <451@ima.UUCP>
Date: Thu, 29-Nov-84 23:37:21 EST
Article-I.D.: ima.451
Posted: Thu Nov 29 23:37:21 1984
Date-Received: Sun, 2-Dec-84 02:42:13 EST
Lines: 26
Nf-ID: #R:cornell:-267200:ima:11700003:000:1397
Nf-From: ima!johnl    Nov 29 12:54:00 1984

You're right.  The 286 segmentation is a big pain in the neck if all of
your data doesn't naturally fall into 64K or less chunks.

Having your code in multiple segments is not much of a problem, since there
are long call and return instructions that do pretty much what you want.
But dealing with multi-segment data is hard, and multi-segment stacks are
nearly impossible.  As noted, the low three bits of a segment number are
magic, so to simulate linear addressing, you have to do a lot of shifting
and masking.  Also remember that the 286 won't access operands over a segment
boundary, so that if you have an array of structures, you have to make sure
that no structure is partially in one segment and partially in another,
because it won't work.

Finally, simulating large data is very, very, slow.  Most data manipulation
instructions take 2 or 3 cycles, but reloading a segment register takes 17
cycles because of all of the table lookup the microcode has to do.  And is
the CPU smart enough to notice that the new ES value you're loading is the
same as the current one?  Don't be silly.

Vague claims have been made that the 386 will have 32 bit registers and
large paged segments (the 286 segment descriptors have lots of bits
reserved for 386 expansion) but I'm not holding my breath.  Perhaps I
can interest you in an NS16032.

John Levine, ima!johnl (uucp), Levine@YALE.ARPA (Internet)