[tcas]

I'm working on a multicycle implementation that I will be able to push to a FPGA. There's no way I'll be able to get the same cycle timing as the specs indicate however. 3 cycles for a divide is very, very generous for such a simple CPU, I'll probably either end up implementing a shift and subtract algorithm (will take more than 3 cycles), or using huge look up tables (probably too big fit in a single blockRAM as well...) to try and achieve it. On the other hand, SHR and SHL are trivial to do in hardware via a barrel shifter, but he assigned 2 cycles for them.

The [next word + register] instruction is also a bit annoying to deal with in the given time tables and a simple register file design, though I haven't thought about the design of that too much.

[obtu]

Would it be a good idea to run the instructions as fast as you can, adding some cycle accounting and using it to generate some external interrupt to help implement quotas? Though when it gets IO support you might have to run things entirely in lockstep again.

[monological]

Notch said it'll run around 100khz in-game, so it should be a piece of cake for an FPGA to do it in even one in-game clock cycle.