4 ms·

The beauty of old school 68k assembly is astounding compared to the unstructured, messy piece of garbage that is X86 assembly. Intel should be ashamed of thems

The beauty of old school 68k assembly is astounding compared to the unstructured, messy piece of garbage that is X86 assembly. Intel should be ashamed of themselves for 20 years later still not having cleaned up their act.

fahadkhan 10y ago
I can't see them being anything but proud of that legacy! In fairness they tried with IA-64, but the world didn't want it. And perhaps both HP & Intel were half hearted about it.
- beagle3 10y ago
  IA-64 was not a clean break; it was an enormous bet on compilers getting sufficiently smart by the time the cheap gets out. They didn't. In fact, today's compilers are still not smart enough to make the IA-64 a reasonable architecture.
- pjc50 10y ago
  IA-64 was a terrible fit for anything other than carefully targeted code for very specific algorithms. Anything data-dependent ended up with poor code density. It was left to AMD to deliver the 64-bit instruction set that people actually wanted.
WalterBright 10y ago
The x86 kludginess is a result of decades of new features being layered in while maintaining backwards compatibility.
- 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.
dzdt 10y ago
Modern X86 machine code is optimised as an intermediate language between compilers and the microcode the processor runs internally, subject to the constraint of backwards compatibility to all previous X86 machine code versions. Clean design is impossible due to the backwards compatibility constraint.
userbinator 10y ago
The opcode map tells a different story, however. x86 looks very organised in octal: http://i.imgur.com/xfeWv.png http://i.imgur.com/xfeWv.png 68k and a lot of the other Motorola CPU's opcode layout looks far less organised to me; there's no common pattern among all the ALU ops, for example, and there seems to be plenty of undefined/unused gaps: http://goldencrystal.free.fr/M68kOpcodes-v2.3.pdf http://goldencrystal.free.fr/M68kOpcodes-v2.3.pdf
- ksherlock 10y ago
  Let's assume the x86 octal layout is the pinnacle of enlightenment and the 68k instructions were assigned by rolling a 65536-sided die. So what? I don't write my assembly using DIP switches, I write my assembly using mnemonics.
  - wolfgke 10y ago
    > I don't write my assembly using DIP switches, I write my assembly using mnemonics. In other words: Not the x86 instruction set is bad, but the common assembly language(s) (there is Intel and AT&T syntax) that are used to describe it.
- kazinator 10y ago
  I wrote an emulator for M68K nearly 25 years ago. I wrote a generator to produce the opcode dispatch table. It used regular expressions on bits (textual strings of 1's and 0's) to condense the generator's specification; I remember it being quite condensable that way.
- pubby 10y ago
  I don't see how this is relevant to anything at all. >there's no common pattern among all the ALU ops, for example, and there seems to be plenty of undefined/unused gaps: Presumably there is a pattern and that is why the gaps exist.
hota_mazi 10y ago
Indeed. mov esp, 0 "Move 0 into esp". Seriously, X86? Who came up with that?
- CoC_CRUSHER 10y ago
  What's wrong with "mov esp,0" ? It makes sense.
- tmccrmck 10y ago
  I'm not sure AT&T syntax is much better. movl $1, %esp
- GuB-42 10y ago
  Read it as "esp = 0". "add eax, 3" is like "eax += 3" in C. This is the Intel syntax and it is the most popular for doing x86 assembly. The other syntax, the AT&T syntax, works the other way ("mov $0, %esp" puts 0 into esp).
- wolfgke 10y ago
  What is wrong with that? Besides the fact that the canonical way to zero a register on x86 if flags are of no concern is xor reg,reg (recommended way) or sub reg,reg
  - Jach 10y ago
    It's wrong if you try to read it as "move 0 into esp" because the source and destination are reversed in code from how it's expressed in English. The way to fix that is to use the other syntax, or change how you think of the English. If read like Lisp, then it's "set esp to 0" and 'mov' is just a poor mnemonic.
    - deleted 10y ago
      [deleted]
  - hota_mazi 10y ago
    I read "mov a,b" as "Move a into b".

fahadkhan 10y ago

I can't see them being anything but proud of that legacy! In fairness they tried with IA-64, but the world didn't want it. And perhaps both HP & Intel were half hearted about it.

beagle3 10y ago
IA-64 was not a clean break; it was an enormous bet on compilers getting sufficiently smart by the time the cheap gets out. They didn't. In fact, today's compilers are still not smart enough to make the IA-64 a reasonable architecture.
pjc50 10y ago
IA-64 was a terrible fit for anything other than carefully targeted code for very specific algorithms. Anything data-dependent ended up with poor code density. It was left to AMD to deliver the 64-bit instruction set that people actually wanted.

WalterBright 10y ago

The x86 kludginess is a result of decades of new features being layered in while maintaining backwards compatibility.

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.

dzdt 10y ago

Modern X86 machine code is optimised as an intermediate language between compilers and the microcode the processor runs internally, subject to the constraint of backwards compatibility to all previous X86 machine code versions. Clean design is impossible due to the backwards compatibility constraint.

userbinator 10y ago

The opcode map tells a different story, however. x86 looks very organised in octal: http://i.imgur.com/xfeWv.png http://i.imgur.com/xfeWv.png 68k and a lot of the other Motorola CPU's opcode layout looks far less organised to me; there's no common pattern among all the ALU ops, for example, and there seems to be plenty of undefined/unused gaps: http://goldencrystal.free.fr/M68kOpcodes-v2.3.pdf http://goldencrystal.free.fr/M68kOpcodes-v2.3.pdf

ksherlock 10y ago
Let's assume the x86 octal layout is the pinnacle of enlightenment and the 68k instructions were assigned by rolling a 65536-sided die. So what? I don't write my assembly using DIP switches, I write my assembly using mnemonics.
- wolfgke 10y ago
  > I don't write my assembly using DIP switches, I write my assembly using mnemonics. In other words: Not the x86 instruction set is bad, but the common assembly language(s) (there is Intel and AT&T syntax) that are used to describe it.
kazinator 10y ago
I wrote an emulator for M68K nearly 25 years ago. I wrote a generator to produce the opcode dispatch table. It used regular expressions on bits (textual strings of 1's and 0's) to condense the generator's specification; I remember it being quite condensable that way.
pubby 10y ago
I don't see how this is relevant to anything at all. >there's no common pattern among all the ALU ops, for example, and there seems to be plenty of undefined/unused gaps: Presumably there is a pattern and that is why the gaps exist.

hota_mazi 10y ago

Indeed. mov esp, 0 "Move 0 into esp". Seriously, X86? Who came up with that?

CoC_CRUSHER 10y ago
What's wrong with "mov esp,0" ? It makes sense.
tmccrmck 10y ago
I'm not sure AT&T syntax is much better. movl $1, %esp
GuB-42 10y ago
Read it as "esp = 0". "add eax, 3" is like "eax += 3" in C. This is the Intel syntax and it is the most popular for doing x86 assembly. The other syntax, the AT&T syntax, works the other way ("mov $0, %esp" puts 0 into esp).
wolfgke 10y ago
What is wrong with that? Besides the fact that the canonical way to zero a register on x86 if flags are of no concern is xor reg,reg (recommended way) or sub reg,reg
- Jach 10y ago
  It's wrong if you try to read it as "move 0 into esp" because the source and destination are reversed in code from how it's expressed in English. The way to fix that is to use the other syntax, or change how you think of the English. If read like Lisp, then it's "set esp to 0" and 'mov' is just a poor mnemonic.
  - deleted 10y ago
    [deleted]
- hota_mazi 10y ago
  I read "mov a,b" as "Move a into b".