Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!houxm!vax135!petsd!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.arch Subject: Re: Re to the nth: 286 vs. 68k Message-ID: <1072@peora.UUCP> Date: Sun, 16-Jun-85 21:11:04 EDT Article-I.D.: peora.1072 Posted: Sun Jun 16 21:11:04 1985 Date-Received: Tue, 18-Jun-85 04:27:09 EDT References: <675@dataio.UUCP> <195@tut.UUCP> <10148@rochester.UUCP> <328@spar.UUCP> Organization: Perkin-Elmer SDC, Orlando, Fl. Lines: 27 [The referenced article speculates on why the 8086 might have been designed the way it was.] This brings up an interesting point, one I've seen little data on. I've heard it said that a lot of the reason why the 8086 was designed the way it was was that, in the early days, there was an assembler for the 8086 that took 8085 assembler source and generated 8086 object code. Yet the only evidence I've ever seen that this was actually the case is in the listings provided with a popular word processor that show how to customize it; these indeed use 8085 register names in place of the 8086 ones (although it clearly is generating code for an 8086). Thus perhaps the properties of the 8086 are partly the result of this attempt at upward compatibility. On the other hand, as far as I can tell the 68000 designers did not make such an attempt, to make the 68000 upward compatible with the 6800 (or 6809). (It's a good thing they didn't try to make it compatible with the 6809! The 6809 was starting to take on some of the irregularities of the 8086 in terms of the difficulty of generating object code for it.) -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Gnyx gb gur fhayvtug, pnyyre..."