RISC-V exceptions and C extension - Page 1
Forum section: electronics / general

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 29, 2024, 04:41:16 am
content: 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?

author: kjpye
author_rank: Contributor
timestamp: June 29, 2024, 05:45:18 am
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: June 29, 2024, 05:47:12 am
content: Quote from: SiliconWizard on June 29, 2024, 04:41:16 amRead 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.

author: brucehoult
author_rank: Super Contributor
timestamp: June 29, 2024, 05:51:23 am
content: Quote from: kjpye on June 29, 2024, 05:45:18 amThe 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 29, 2024, 06:46:41 am
content: 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?

author: brucehoult
author_rank: Super Contributor
timestamp: June 29, 2024, 07:20:22 am
content: Quote from: SiliconWizard on June 29, 2024, 06:46:41 amIf 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 29, 2024, 08:27:13 am
content: 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.

author: DiTBho
author_rank: Super Contributor
timestamp: June 29, 2024, 02:56:05 pm
content: 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