6502.org

I can't find it now, but I've read a comment to the effect that Inmos' OCCAM compiler would sometimes not manage to converge: every pass changed the lengths of the machine code and therefore the branches. Transputer machine code has an interesting construction.

As I understand it, individual Transputers are just a typical Von Neumann stack machines with instructions for serial I/O. The only oddity I can think of for them is how they construct immediate literals. However, anything beyond 8 literal instructions in a row should overflow a 32-bit Transputer's capacity to hold the number. That should set some kind of limit on code size.

yes, but you can imagine even passes bumping up the length by one byte, and odd passes bumping it back down again, such that neither pass is self-consistent and the process can't converge.

(in fact, the machine code is somewhat word-width neutral - same coding for the earlier 16-bit and the later 32-bit models. Each byte in the instruction stream is a pair of nibbles, which constructs the actual opcode in a word-sized buffer. You could, I think, have an instruction stream which constructs a 128-bit constant using lots of PFIX nibbles, and that would be valid (accepted) on any machine, although the machine would doubtless truncate the constant. See http://en.wikipedia.org/wiki/Transputer#Instruction_set)

Ooooh, yes, good point. I hadn't thought of that kind of interaction before now.

My assembler normally uses two passes but switches to three when it detects the structured programming (IF/THEN/ELSE, etc.) directives being used so that it can generate the smallest code for the tests (e.g BEQ vs BNE+JMP) and branches (e.g. BRA vs JMP).