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.
Intel should be ashamed of themselves for 20 years later still not having cleaned up their act.
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:
>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.
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.
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.
Worse is better.
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.
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.
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
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.
mov esp, 0
Seriously, X86? Who came up with that?
movl $1, %espThis 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).
xor reg,reg
sub reg,reg dest := source;
memcpy(dest, src, size);
obj.set(0);
Some have load/store instructions where the memory is always on one side:
load [r1], r3 ; --> direction
store [r1], r3 ; <-- direction