> 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
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
(this is not a concern in x86-32 and x86-64 bit code, since there you can address relatively to esp/rsp).