The opcode map tells a different story, however. x86 looks very organised in octal:

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

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.

> 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.

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.

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.

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

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.

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.

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.

> 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.

> 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.

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.

> 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

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), 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).

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.

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.

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.

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.

Indeed.

    mov esp, 0

"Move 0 into esp".

Seriously, X86? Who came up with that?

The same engineer who came up with

    dest := source;

and

    memcpy(dest, src, size);

as well as

    obj.set(0);

Numerous assembly languages have destinations on the left.

Some have load/store instructions where the memory is always on one side:

    load [r1], r3   ; --> direction
    store [r1], r3  ; <-- direction

it's a matter of assembler syntax; the "AT&T" syntax used by the GNU assembler and gcc for x86 has destination on the right.

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).

I'm not sure AT&T syntax is much better.

  movl $1, %esp

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

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.

I read "mov a,b" as "Move a into b".

It is canonical in Intel syntax that the parameter order is always "destination, source" (in AT&T syntax it is "source,destination").