4 ms·

True, but the original 8086 was already ultra kludgy (segment registers etc), even though it was NOT backwards compatible with its predecessor 8080; and every n

by beagle3 10y ago

True, but the original 8086 was already ultra kludgy (segment registers etc), even though it was NOT backwards compatible with its predecessor 8080; and every new x86 generation had seen more kludges added. The 68000, which was essentially a contemporary of the 8086 (something like 6 month difference in market availablity IIRC), was clean and orthogonal, and they kept it kludge free at least through the 68040 (which was the last one I used, and which was contemporary with the super-ultra-kludgy 486). I don't disagree with your statement, but I think it gives the impression that Intel did a reasonable job at any given time subject to compatibility constraints, and in my opinion that is not so.

WalterBright 10y ago
While the 8086 could not directly execute 8080 code, it was designed to make translation of 8080 to 8086 code straightforward. This turned out to be a sound business decision for Intel. I was less impressed than others with the orthogonality of the 68000 when it came out. I was used to the PDP-11 instruction set, which was genius in its orthogonality and simplicity.
gpderetta 10y ago
While the 680x0 might have been nicer to program, because of its very CISCy semantics, turns out that making a performing OoO implementation was impossible with the transistor budget of the 90s. Not so much with the much uglier but simpler x86. Worse is better.
- josteink 10y ago
  > While the 680x0 might have been nicer to program, because of its very CISCy semantics It indeed was. I don't understand why Intel at least didn't try to be inspired by the good bits here. > turns out that making a performing OoO implementation was impossible with the transistor budget of the 90s. Not so much with the much uglier but simpler x86. Yup. This killed the Amiga, and this was what forced Apple to move to PowerPC. Motorola just couldn't deliver fast enough chips at a reasonable cost. No reason not to praise them for what they did do right though.
  - taway_1212 10y ago
    > Yup. This killed the Amiga Business reasons (i.e. Commodore's collosal incompetence) aside, the fact that screen image was represented as bitplanes (instead of a byte/bytes per pixel) was also a major problem. It made 3D games very computationally expensive, hence no Wolf3D, Doom etc. on Amiga.
    - dogprez 10y ago
      I'll add too that most of the software bypassed the APIs and ran at a low level. Amiga would have had a difficult time updating their architecture without invalidating all their software.
- wolfgke 10y ago
  > While the 680x0 might have been nicer to program, because of its very CISCy semantics Convince me to be wrong, but to my knowledge the 68k was more comfortable to program since * it simply had more general purpose registers available (this "register shortage" was only reduced in x86-64) * at that time x86 was in DOS particular used in real mode (which is not very comfortable to program for), though protected mode was theoretically available from 286 on * there are some commonly instructions that had/have to be used with specific registers, which made the x86 instruction set feel "rather unorthogonal" (though in my opinion it was better than its reputation). For example the "MUL" instruction (unsigned multiplication) only accepts some specific register(s) as destination > http://x86.renejeschke.de/html/file_module_x86_id_210.html http://x86.renejeschke.de/html/file_module_x86_id_210.html This was IMHO much worse in real mode, since for example - there in/out were common instructions for writing DOS applications - you could not address relatively to the stack pointer sp in x86-16 bit code (cf. https://reverseengineering.stackexchange.com/q/11442/12822 https://reverseengineering.stackexchange.com/q/11442/12822), so that you had to write introns and outrons like push ebp mov ebp, esp mov esp, ebp pop ebp (this is not a concern in x86-32 and x86-64 bit code, since there you can address relatively to esp/rsp).

by beagle3 10y ago

WalterBright 10y ago

While the 8086 could not directly execute 8080 code, it was designed to make translation of 8080 to 8086 code straightforward. This turned out to be a sound business decision for Intel. I was less impressed than others with the orthogonality of the 68000 when it came out. I was used to the PDP-11 instruction set, which was genius in its orthogonality and simplicity.

gpderetta 10y ago

While the 680x0 might have been nicer to program, because of its very CISCy semantics, turns out that making a performing OoO implementation was impossible with the transistor budget of the 90s. Not so much with the much uglier but simpler x86. Worse is better.

josteink 10y ago
> While the 680x0 might have been nicer to program, because of its very CISCy semantics It indeed was. I don't understand why Intel at least didn't try to be inspired by the good bits here. > turns out that making a performing OoO implementation was impossible with the transistor budget of the 90s. Not so much with the much uglier but simpler x86. Yup. This killed the Amiga, and this was what forced Apple to move to PowerPC. Motorola just couldn't deliver fast enough chips at a reasonable cost. No reason not to praise them for what they did do right though.
- taway_1212 10y ago
  > Yup. This killed the Amiga Business reasons (i.e. Commodore's collosal incompetence) aside, the fact that screen image was represented as bitplanes (instead of a byte/bytes per pixel) was also a major problem. It made 3D games very computationally expensive, hence no Wolf3D, Doom etc. on Amiga.
  - dogprez 10y ago
    I'll add too that most of the software bypassed the APIs and ran at a low level. Amiga would have had a difficult time updating their architecture without invalidating all their software.
wolfgke 10y ago
> While the 680x0 might have been nicer to program, because of its very CISCy semantics Convince me to be wrong, but to my knowledge the 68k was more comfortable to program since * it simply had more general purpose registers available (this "register shortage" was only reduced in x86-64) * at that time x86 was in DOS particular used in real mode (which is not very comfortable to program for), though protected mode was theoretically available from 286 on * there are some commonly instructions that had/have to be used with specific registers, which made the x86 instruction set feel "rather unorthogonal" (though in my opinion it was better than its reputation). For example the "MUL" instruction (unsigned multiplication) only accepts some specific register(s) as destination > http://x86.renejeschke.de/html/file_module_x86_id_210.html http://x86.renejeschke.de/html/file_module_x86_id_210.html This was IMHO much worse in real mode, since for example - there in/out were common instructions for writing DOS applications - you could not address relatively to the stack pointer sp in x86-16 bit code (cf. https://reverseengineering.stackexchange.com/q/11442/12822 https://reverseengineering.stackexchange.com/q/11442/12822), so that you had to write introns and outrons like push ebp mov ebp, esp mov esp, ebp pop ebp (this is not a concern in x86-32 and x86-64 bit code, since there you can address relatively to esp/rsp).