What are the implications when Zicsr is absent?

[ken...@imperas.com]

I don't fully understand the implications of not implementing Zicsr, and I'm hoping someone can enlighten me.

Superficially, not implementing Zicsr simply means that all CSR access instructions are absent. Does this mean that it is therefore impossible to handle any exceptions, because doing so would inevitably require CSR access in the handler? If so, what happens on a machine without Zicsr when (for example) an illegal instruction is executed? Is this treated as a NOP?

I'm sure this must be documented somewhere, but I can't find anything about it - any pointers would be very welcome.

Thanks.

[Anthony Coulter]

A system that does not implement Zicsr is free to design its own crazy
and independent way to handle interrupts, exceptions, and the like.
Consider the commentary at the beginning of the privileged spec which
notes that it was designed in such a way that the entire privileged
spec could be redesigned without changing the unprivileged spec. I
interpret the Zicsr extension the same way: if you want to handle
status registers in a way that is compatible with the rest of the
RISC-V ecosystem, you should use the standard CSR instructions. But if
you're doing an experimental architecture that handles global chip
state differently, you have the option of cleanly splitting the CSR
instructions off from the rest of the RISC-V base instructions while
still calling your core RV64I-compatible.

So a design that doesn't implement Zicsr isn't necessarily one that
doesn't have exception handlers or any chip-global state; it should
really be thought of as a design with nonstandard exception handlers
and nonstandard means of reading and setting chip-global state. As
such, the details would be documented on a chip-by-chip basis, since
the official RISC-V specifications are focused on standardization.

Anthony

[Andrew Waterman]

Yes, if Zicsr is present, then the standard privileged architecture is inherently not present, either.

A place this might manifest in practice is an RV32I unprivileged virtual machine.  Think: qemu-user without the performance counters and without any extensions that 

need the fcsr.  There are no CSRs, hence no need for Zicsr.  This is a real-world instance of what Anthony mentioned: the privileged architecture is completely replaced.  The ECALL interface still exists, and traps can occur, but they are handled by host software, rather than by RISC-V software written for the standard privileged architecture.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/686abbb880c62b12%40raines.redjes.us.

[James Kenney]

Ok, thanks. I wonder if something based on these explanations could be usefully added as a short commentary in the manuals somewhere?

James.

[Iztok Jeras]

I am writing my own RISC-V for practice and fun.

I did not get to writing interrupt support yet, although I did implement CSR instructions.

I was thinking of what use would a CPU without interrupt support be.

One use case would be a programmable FSM with polling instead of interrupts.

Or a system performing a complex initialization sequence and going silent afterwards.

I have also seen a lot embedded of software without any interrupts (not good SW), if there is also no OS (tick timer for task switching), than interrupt support might not be needed.

Regards,

Iztok Jeras