I'm currently designing a CPU in VHDL. The CPU has a variable-length instruction set (1-4 bytes), with a 16-bit bus, meaning that I need some kind of buffer to hold bytes not yet processed (which will also facilitate if I want to pipeline instruction fetch and decoding). My question is what the best way is to implement this. I currently keep track of the number of bytes in the buffer, and when reading put the two new bytes at locations count and count+1. After the instruction has been decoded, I copy the remaining bytes to the start of the buffer. But it all somehow seems inefficient (though it seems to work). What is the typical way to implement an instruction buffer like this? Any help appreciated.

I've thought of this problem often enough.

Here's the best solution I've come up with: Maintain a register one word longer than the normal register. The next instruction is always aligned to the MSB's of this word. As an instruction is decoded, the decoder tells this (shift) register how many bytes to move up. When there's room to stuff a new word into the register, it's stuffed in at the bottom. This allows some of bottom bytes to be unused until a new instruction is moved in.

That said, I've never built an instruction set architecture that worked like this. Multiple instruction length support is a complex topic.

The ZipCPU solved this problem in a rather innovative fashion: most instructions were one word in length (32-bits), however there were also compressed instructions that stuffed two 16-bit instructions into one 32-bit word. The CPU was not allowed to jump into the middle of a word, neither was an interrupt allowed to split a word. All of the compression was handled in the assembler: If the compressed instructions couldn't maintain alignment, the assembler wouldn't pack them. Further, all jumps are to aligned addresses--again insured by the assembler.

Not sure if this helps, but it's what I know of the problem.
Dan

Hi Dan,

Thanks for the reply. The solution you describe looks almost exactly with what I've come up with (even though perhaps I worded it not completely clear in my question), except I align it the other way around (align to LSB, shift/copy down).

I've actually studied the ZipCPU's documentation (and some of the source), it's indeed quite a neat design. The reason why I chose a variable instruction length is that I'm designing an oldskool CPU with an instruction set leaning to CISC, and the 80s CPUs typically had variable instruction length.