LMARV-1 reboot part 5: formal verification of the CPU 

I need traps to handle interrupts. Otherwise the only other way to handle external signals is to poll for them, and who wants to do that?

The standard seems to indicate that if you don't implement an extension, you get to decide what to do when you encounter instructions in that extension. I decided to just skip over the instruction :)

​@@RobertBaruch I don't think you are reading that quite right (or otherwise I'm not ;-) ). Any instruction that you don't implement is supposed to generate a "Illegal instruction" trap. But any instruction encoding not specified in the base instruction set or a supported extension can be reused for an instruction in a custom extension if you want to (Though if you use any instruction encoding other than those explicitly reserved for custom extensions, [i.e. major opcodes custom-0, custom-1, custom-2, and custom-3] it would be a non-conforming custom extension). I *guess* you could create a non-conforming custom extension that uses all instruction encodings not used by RV32I and then not document the behaviour of most of you custom instructions, but that would be seriously bad manner. Also, that would prevent software emulation of unsupported extensions, which can be quite useful.

@@JonSeverinsson Well, 2.2 says that "The behavior upon decoding a reserved instruction is unspecified" so that covers the "holes" in instructions. But I suppose it does make sense that if an extension is not supported, then an instruction in that extension should generate a trap, so that either an exception is signaled, or the execution environment implementation could emulate the instruction. In that case I should probably just lock everything down and throw an illegal instruction exception.

32 bits is 4 bytes. If you remove any of those bits you only make things more difficult in other ways.

There’s two (well, three) solutions: a “coprocessor flag” that signals another card to do something and throw an illegal instruction exception if nothing responds. The other option is to have a way for the sequencer to know about coprocessors (like an I2C side bus for communications) and what opcodes they support, then when a “new” instruction is reached, see if a “coprocessor” claims to support it and toss control over to that card (by doing nothing and letting the card deal with the instruction) until it’s done. The third “solution” is to just do nothing which would possibly require a new sequencer card for each extension. I’m reminded of Intel when the x87 was a physical (optional) coprocessor. If a 0xD? byte was reached (as the first of an instruction), the main CPU would just ignore it and the x87/FPU would work in the background to compute the result. Then the FPU would tell the CPU that it was done so the CPU could get the result.

Correct, but the usual way the trap handler runs is to push/pop all registers. I just shortcut that by doing it in hardware.

@@RobertBaruch Here is a RISC-V with the option of a different bank of registers for interrupts: github.com/darklife/darkriscv Note that while the counter CSRs were part of the 32I base instruction set until recently, they have become optional in the latest revision (now they are extension Zicsr in chapters 9 and 10)

@@RobertBaruch I think, the correct (i. e. standard conforming) way would be, that you create an instruction set extension to do that. That means, that the interrupt handler would be called as the standard describes and then performs a register swap instruction. There is plenty of space in the opcode matrix to do that. Also this would mean, that you could possibly do it as an optimization for for function calls. Instead of pushing the arguments to the stack, the caller would now copy the arguments to a fresh bank of registers, then switch to it and call the function. I imagine this being a big performance boost for some programs. That would mean, that you need to change the api though.

@@lukasschwager5876 Actually, now that I think about it -- automatically swapping the register page might not be great, since a trap might want to know what the registers were when the trap happened. So then yeah, a register page swap instruction would be in the CUSTOM extension.