Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ingr!b11!lhughes From: lhughes@b11.ingr.com (Lawrence Hughes) Newsgroups: comp.arch Subject: Re: The CPU with 3 brains---486 compatibility with 8008 Summary: intel cpu compatibility Message-ID: <9333@b11.ingr.com> Date: 7 Nov 90 14:01:37 GMT References: <42737@mips.mips.COM> <1990Nov4.014901.23819@zoo.toronto.edu> <1990Nov6.223738.13265@ux1.cso.uiuc.edu> Organization: Intergraph Corp. Huntsville, AL Lines: 100 In article <1990Nov6.223738.13265@ux1.cso.uiuc.edu>, msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas) writes: > In <2841@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > > >In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > > >| Except for oddities like the 860 and 960, isn't the 486 still designed > >| to be almost binary compatible with the 8008? Sigh! > > > As far as I know the 80486 and 8008 are completely compatible at the > >level of the first two digits of the part number. The instruction set is > >100% diferent, so the only binary compatibility is that they both will > >read ones and zeros. > > I don't know anything about the 8008, but I know that although the > 8086 is not binary compatible with the 8080, it is similar enough > that porting assembly code is (I mean, was) supposed to be so easy > that it could be done automatically. The 80486 is (of course) binary > compatible with the 8086. This is why you can run Wordstar 3.0 on > your 486 box. (That may well be better than whatever the latest > version is.) (A few years ago, I tried (for laughs) running Wordstar > 3.0 on a 20 MHz 386. It was no faster than on a 4MHz Z80. Amazing.) First off, the 8008 and 8080 were compatible only in the mind of Intel's marketing folks - different register architecture and different binary opcodes. It was possible to do "automatic" translation of source code from 8008 to 8080, but then again, you COULD do the same for PDP-11 to VAX... (about as "compatible"). Of course, if you did this, you wound up with programs that ran incredibly slow, since they did not take advantage of any of the 8080's 16 bit capabilities, etc. Fortunately, there was such a vanishingly small amount of 8008 code ever written than this wasn't much of an issue. The Z80 WAS upward compatible with the 8080, at both architecture and binary opcode level - curiously enough, though, the bright boys at Zilog invented a better (read "different and incompatible") symbolic assembly langauge which made it much more difficult to take advantage of the Z80's extended instructions: you either stuck with Intel mnemonics (and the 8080 subset) or worked with Zilog's "preverted" ones (e.g. almost half the actual binary opcodes mapped onto the single symbolic opcode "LD"). Zilog's symbolic language was SUCH a turkey, that several extended Intel symbolic assembly languages were developed (and widely used) leading to a regular tower of Babel. Clever, Zilog. When Intel introduced the 8086, they managed to make BOTH of these mistakes! Again, compatibility existed mainly in the minds of the marketing department (although there was somewhat of an upward compatibility in registers, they didn't work the same way in many cases and entire classes of instructions such as conditional calls and returns, and indirect addressing via some registers, curiously disappeared on the way to the 8086). There was of course NO support for the Z80 extensions to the 8080 (don't be SILLY). One of the worst design decisions (still plaguing us today) is that *&^%$ segmented addressing scheme. But the crowning glory of the 8086 introduction was one of the silliest symbolic assembly languages ever introduced (ever hear of a STRONGLY TYPED assembler?). I figure this was concocted by some PASCAL nuts who had fried their brains on structured programming, or some such. Again, several folks attemped to design and support saner assembly language, resulting in another fine mess (was that written with the Microsoft/Intel or Digital Research mnemonics?). I actually had to translate a major piece of 8080 code (25,000 lines) to 8086, and TRIED to use the automatic translation tools - what a pain. Would have been simpler to translate to PDP-11. The resulting code (without extensive hand optimization) really did run SLOWER on the original 4.77 MHz PC than it did on my 4 MHz Z80. I finally did get the program translated and optimized to a large extent, but you'll never convince ME the 8086 is "upward compatible" with the 8080. Fortunately, the 80186 (ever see that one outside of a dedicated controller?), the 80286 (universally recognized as the first commercially successful brain dead processor - waddya mean, I can't get back out of protected mode without rebooting the processor???), the 80386 (the 8086 finally done almost right - knew they would get the hang of it if they kept trying...) and the 80486 (really getting pretty slick - too bad it costs so friggin' much) are all durn near really and truly upward compatible (for which they have been soundly denounced by the forces of chaos everywhere, but not by much of anyone who actually has to WORK with these little buggers...). As far as WORDSTAR on 8086, I really appreciated having a well thought out and mature word processor on what was otherwise a truly poorly supported system. Does anyone else remember the rumors that the original translation of Wordstar to 8086 was done by a wigged out druggie who demanded payment in cocaine? There were several times I seriously considered whether taking a snootful might make the 8086 architecture and bizarre symbolic language make more sense! With Wordstar 4.0, it really took advantage of the 8086 and was quite fast, thank you. I still consider my 5.x versions to be the best combined word processor / page layout product available. Beats the hell out of using Ventura as a post processor (whadda knee-walking turkey). Alas, Wordstar (not the "2000" gobbler, but the REAL one) may be one of the last commercial products written (at least primarily) in assembly language. Welcome to the wonderful world of multi-megabyte executables that barely fit in 2 MB systems, barely crawl on 25 MHz CPUs and won't even run on any known diskette system. Compliments of brothers Kernigan and Ritchie. Let's not even talk about the marvelous POINT AND GRUNT interfaces that are being shoved down our throats now... I used to run on a MAINFRAME with 300 other folks that had less CPU/FPU/MEMORY/DISK resources than a system that can barely run Windows.... Larry (in shaky voice: "When I was a lad - we barely had 64K bytes of memory, and were GRATEFUL for it".... cough cough) Hughes