RISC-V exceptions and C extension

[SiliconWizard]

Something I hadn't run into before - possibly obvious. Dunno.
When using the C extension, how do you handle incrementing xEPC from the exception handler, to return to the next instruction? How do you know if it was a 16-bit or 32-bit instruction that triggered the exception?

[kjpye]

The bottom two bits of an instruction opcode are both 1 for a 32-bit instruction, and at least one is 0 for a 16-bit instruction.

Note that there are potential future enhancements to use instructions of more than 32 bits. These will also have the bottom two bits as 1.

See section 1.5 of the RISC-V Instruction Set Manual volume 1.

[brucehoult]

Something I hadn't run into before - possibly obvious. Dunno.
When using the C extension, how do you handle incrementing xEPC from the exception handler, to return to the next instruction? How do you know if it was a 16-bit or 32-bit instruction that triggered the exception?

Read the byte at xEPC and if the low two bits are 11 then it's a 4 byte instruction, otherwise it's a 2 byte instruction.

This situation should only arise if you're parsing and emulating the instruction anyway e.g. doing a misaligned load/store, or if the instruction is ecall / mcause is 8-11.

Otherwise you're returning -- if at all -- to the same instruction.
 

[brucehoult]

Note that there are potential future enhancements to use instructions of more than 32 bits. These will also have the bottom two bits as 1.

The encoding scheme for instructions longer than 4 bytes has not yet been settled on. What is in the manual is just one (now unlikely) possibility.

What you *can* be sure of is that it's a longer instruction IFF the bottom 5 bits of the first byte of the instruction are 11111. You could choose to panic if you see that.

[SiliconWizard]

OK thanks, so no other way than reading the instruction @xEPC (at least one byte of it).
Yes it's only for some types of exceptions, indeed.

From what I seem to remember now, isn't the instruction that triggered an exception stored into xTVAL? Or is that maybe not guaranteed, and just implementation-defined?

[brucehoult]

From what I seem to remember now, isn't the instruction that triggered an exception stored into xTVAL? Or is that maybe not guaranteed, and just implementation-defined?

If it's illegal/unimplemented instruction, then yes, for sure. But not if it's a load/store hitting an invalid address (misaligned, protected) -- in that case it's the address that was trying to be accessed (saves you having to parse the instruction and extract the pointer register and the offset and add them etc). Also an invalid address can be on instruction fetch.

RISC-V has no data-dependent exceptions e.g. overflow, divide by zero, floating point stuff.

[SiliconWizard]

Yes, the two cases I have in mind are: illegal instructions (but then the instruction is in xTVAL), and load/store access errors (which is the only case I can now think of that will require reading the instruction, if one wants to handle the exception in a recoverable way).

Speaking of xTVAL, there is a STVAL, but I'm not completely sure it gets the treatment described above. From what I could read in the specs, they seem to only document that for MTVAL. But, gray area for me.

[DiTBho]

From MIPS1 to MIPS32r2 and even MIPS5++, MIPS does this somewhat worse.
We have made progress with RISC-V, and this makes me very very happy