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)