How can RISC-V SYSTEM instructions be implemented as trap?

Question

I am currently studying the specifications for RISC-V with specification version 2.2 and Privileged Architecture version 1.10. In Chapter 2 of RISC-V specification, it is mentioned that "[...] though a simple implementation might cover the eight SCALL/SBREAK/CSRR* instructions with a single SYSTEM hardware instruction that always traps [...]"

However, when I look at the privileged specification, the instruction MRET is also a SYSTEM instruction, which is required to return from a trap. Right now I am confused how much of the Machine-level ISA are required: is it possible to omit all M-level CSRs and use a software handler for any SYSTEM instructions, as stated in Specification? If so, how does one pass in information such as return address and trap cause? Are they done through regular registers x1-x31?

Alternatively, is it enough to implement only the following M-level CSRs, if I am aiming for a simple embedded core with only M-level privilege?

mvendorid
marchid
mimpid
mhartid
misa
mscratch
mepc
mcause

Finally, how many of these CSRs can be omitted?

Hypothetical

In my experience, it is better to say "I do everything," than it is to explain to each customer, or worse, have a competitor explain to your customers, what it is that you do not do. But perhaps someone who knows the CSRs better could help; it is not something I do. – Novelistic

Sounds like an alternative to microcode, farming it out of the CPU entirely, to instructions stored in memory. (Unless that memory is internal to the CPU, then it is basically a microcode ROM.) – Pinsky

Answer 1

1. ECALL/EBREAK instructions are traps anyway. CSR instructions need to be carefully parsed to make sure they specify existent registers being accessed in allowed modes, which sounds like a job for your favorite sparse matrix, whether PLA or if/then.

2. You could emulate all SYSTEM instructions, but, as you see, you need to be able to access information inside the hardware that is not part of the normal ISA. This implies that you need to add "instruction extensions."

3. I would also recommend making the SYSTEM instructions atomic, meaning that exceptions should be masked or avoided within each emulated instruction.

4. Since I am not a very trusting person, I would create a new mode that would enable the instruction extensions that would allow you to read the exception address directly from the hardware, for example, and fetch instructions from a protected area of memory. Interrupts would be disabled automatically. The mode would be exited by branching to epc+4 or the illegal instruction handler. I would not want to have anything outside the RISC-V spec available even in M-mode, just to be safe.

5. In my experience, it is better to say "I do everything," than it is to explain to each customer, or worse, have a competitor explain to your customers, what it is that you do not do. But perhaps someone who knows the CSRs better could help; it is not something I do.

Novelistic

If you have more than on thing to say, edit this answer and add more paragraphs. Optionally separate them with --- horizontal breaks and / or ### headlines if you want to make sections in one answer. Don't post 3 related paragraphs as 3 separate answers. Please merge them into this and delete the other posts. – Pinsky

I tried my best, but my comment will not stay deleted. Does this only happen to me? – Novelistic

You can still see your own deleted posts. (And so can users with 10k rep). What you did is exactly what I was recommending. (Although one of your answers was converted to a comment by a moderator; that's why it also shows up as a comment on the question. Are you saying you can't delete that one?) – Pinsky

Yes. Mod Magic is beyond my ken. – Novelistic