[danbruc]

Assuming 32 bit instructions at least every third instruction would have to be a call or jump - this seams no reasonable assumption. And if you have code with such a high density of jumps you will run into a lot of other problems, too, for example branch mispredictions and cache inefficiency due to non-locality. Maybe there is really a niche where this design has advantages but I don't think it is good for general purpose code.

[prutschman]

> Assuming 32 bit instructions

You don't have to assume, the article itself says the author is contemplating 9-bit instructions.

[danbruc]

I did not read it like that. 9 bit is not really enough for an interesting instruction set for a register machine. It is however enough for a stack machine or something similar with implicit operands, but then again you need more instructions for the same task than with a register machine.

[prutschman]

If you search for the phrase "To add more 'regular' instructions" in part 1, you'll see where he references 8 or 9 bit instructions. The author goes on, in subsequent sections, to expand the idea of tokenized jump references to tokenized instructions.

Each instruction token may only be 8 or 9 bits, but the secondary memory which contains jump targets is expanded to also contain full-width instructions.

The operating hypothesis is that just it's desirable to be able to "reach" any 32-bit destination address despite any given code segment not needing that flexibility, it's likewise desirable to be able to execute any, say, 36-bit instruction even though any given code segment only needs a subset of them.

It's really worth a read.