There seems to be a few "shortcomings" with the 68000 that I wonder if there has been given any further explainations for?
- Word aligned access for long/word. That was abandoned with the 68020. Is the handling of it transistor expensive, or was it 'ideologic'?
- No dbCC.l version. That seems at odds with something you want to be compiler friendly. Not added later either.
- No conditional jump/jsr. Is this not common on other CPUs?
- No pre-increment nor post-decrement. Are these 'mathematically' equivalent and as such superfluous(sp???)? I could imagine a RISC style cpu with 2 destination registers of which one would be basically a pre-increment equivalent "ld #offset,sR,dR1,dR2"
- (a7) is the return address and not free/writeable after a subroutine entry, I guess this is because RTS is basically an "(a7)+" addressing mode instead of "+(a7)". What is most the common way of pushing to the stack, pre or post decrement?
- Potentially odd offset branches. Why didn't they just define that byte/word size branch offsets were shifted once right and as such would span 512byte / 128K offsets?

Interesting questions - I'll offer some answers, but based on gut feeling more than actual evidence!

It's fairly expensive - getting load/store alignment working was one of the most painful parts of 832: https://github.com/robinsonb5/EightThirtyTwo/blob/master/RTL/eightthirtytwo_aligner.vhd
OK, it's a 32-bit rather than 16-bit CPU so there are more permutations to handle, but it's surprisingly difficult for something that sounds so simple! There might have been speed concerns as well as transistor count concerns, too.

Agreed - you can't reliably know whether a branch target is within range until link time, so not having a long form to fall back on is a strange omission.

Do other CPUs have the semantic difference between branch and jump? I've always considered that a slightly strange facet of 68k.

I'd guess implementing both was simply considered wasteful so the more useful variant was implemented?

Semantically A7 points to the item most recently written to the stack - having it point there rather than the next free entry maximises how far into the stack you can reach with a d8(a7) or d16(a7) - reaching backwards into the free stack area is less useful. So I'd argue that pre-decrement is the more useful variant, and it's what I implemented for 832.

Probably to share some addition logic without having to add extra shifts and multiplexers?

My thoughts:
For the dbcc instruction, I think the 68k ALU was only 16-bits wide, reused twice for 32-bit ops. They probably figured it was not worth the extra transistors and state to allow dbcc to handle 32-bit decrements.

Pertaining to post increment and pre-decrement addressing this is the way most stacks work. Since it is possible to get by in most circumstances without pre-increment and post decrement addressing it is not supported.

Conditional jump subroutine is not that common. Usually there are subroutine arguments, set by expressions to evaluate and one wants to branch around the whole mess.

IIRC, the low order bit of the branch displacement is used to indicate long branches, +/- 32k for some versions of the cpu.

The 68k is a favorite of mine despite its idiosyncrasies.

Other things that could be improved: multiply is only 16-bit. Immediate operands for 32-bit instructions must always be 32-bit. There is room in the instruction opcode to code 16-bit immediates for 32-bit ops.

(This was the intended point of the question, not branch length. Sorry about that.)
But with all the extras they stuffed into the 68020 you would think they would have considered adding it in?
Also, given the potential space saving with less pre/post loop handling I think it is kinda surprising they didn't make both word and longword size versions.


Isn't if-then-call-function pretty common occurences in code? It might have been prohibitive for all the addressing modes, but I was for some reason limiting myself to the CC equivalent of "jsr (a0)". As it is you have to branch around the call.
Do other (say x86) architectures only have branch conditionals or do they also have jmp/jsr ones?

Oh, and one last thing: Why is the addressing mode "jsr (a0)" and not "jsr a0"? It's kind of a lie, isn't it?

IIRC the x86 does not have conditional jsr. I think the PowerPC has this though.



I have found that perplexing too. Maybe they were worried the address mode jmp a0 would imply jumping to an instruction in a0 as opposed to using a0 as a memory address. It is a value versus value at semantic. Usually anytime there is a ‘at’ it implies indirection which is usually indicated by enclosing the operand in brackets of some sort. However, some assemblers do not require the brackets because the operand is understood, it cannot be anything else but an indirect access.

Having stared at the lz4 depacker for most of Saturday I also found "exg.b" and "exg.w" to be curiously lacking. I know you have the logical 3-way XOR equivalent, but since it was obviously put in for saving space and cycles I would have expected them to be there, at least for 68020. The encoding has lots of space for it as well.

Things like having only (An)+/-(An) addressing modes, rather than +(An)/(An)+/-(An)/(An)-, gives you obvious savings in logic. But frequently forgotten is also the savings in bits in your instruction fields.

Consider the MOVE instruction:


The modes are as follows:


If you were to add two more modes, +(An) and (An)-, you now need four bits to encode your modes, rather than three. Where do you put the extra two bits?


I don't think either way is predominant over the other in late-'70s and early-'80s microprocessors; it really just depends on what the CPU designers felt was better for their particular design. Both the 6800 and the 6502 postdecrement when they push. Motorola changed that to predecrement-on-push with the 6809 and (obviously) the 68000. Perhaps significantly, the former two do not have addressing modes that index from the stack pointer; the latter two do.

Of all the addressing modes, most really make sense for only load and store.
Want to use (An)+ for a stack machine, you still need to mess around, as divide and subtract/compare
now have reversed sense, using the same amount of code as machine with pop/psh. Threaded code
like FORTH still stays theaded.rather than direct code.

Most of the time you have a frame register for stack offsets.
I think the PDP 6 was the first computer to have stacks,but addressing on them was strange.
PDP 6 -> PDP 10 -> PDP 11 -> 68000