Hello again litwr !
Your distaste for 68k and strange love for x86 never fail to amaze me
Wanting to find wrong data in your articles ?
Let's start with 68k article (there are wrong things in x86 as well).
First, code density isn't worse on 68k than it is on x86. While x86 is marginally better for very small code, its code density collapses for larger programs. You might well find a 40-byte routine that's smaller in x86, but (as an example) HOMM2 is a 1.5MB program in x86 and 0.9MB for 68k (while still being largely suboptimal code).
Having two stacks is nothing like "clumsiness and contrived oddities". But this has already be explained in the past, apparently with no effect. I may try again if you ask.
I agree that two carries are a little poor, they wanted to separate testing from multi-precision. Not much to worry about, as it does not have dramatic consequences on coding. And x86 also has two carries anyway (you know, that little useless AF flag).
The CLR problem is implementation bug and has nothing to do with the ISA's quality. On the other hand, x86 lacks the very useful CLR, TST, and MOVEM.
Arithmetic and logical shifts are indeed a little redundant, but nothing like the x86's way of handling it (two strictly equal commands). ASL might be slightly slower than LSL but has the full functionnality.
Address registers don't need to load 4 bytes (not always). There are relative modes, especially 16-bit PC-relative mode which x86 lacks.
The codes aren't cumbersome and clumsy in comparison to x86 and arm. Actually, quite the opposite. I challenge you to give me a complete opcode map for those two !
The 68010 doesn't lose in comparison to 80286 because the 68000 already doesn't - yes, bare 68000 is still faster than 80286 !
Bitfield operations may look bulky, but they're very far from being useless. While they need some time to be mastered, once this is done it's just a pleasure to use them.
Yes 68020 does not have built-in memory management but a 68451 can be added to fix this - using that ability to connect coprocessors that you seem to dislike.
Of course 68040 is still faster than 80486 - but indeed heats too much and has shortcomings so it started to kill the 68k family.
With all that said, comparison of processors may be a lot easier by writing code (a routine doing the same thing) for each of them. Something around 100-200 instructions, without OS dependencies that may falsify the result.
It would be fun to see code (and actual encoding) compared for 68k, x86, and arm (and whatever else). But who will write the x86/arm code ?