And we should be careful to define the corner cases, e.g. the values that are in the registers when the features are enabled: the values they last held, or undefined, or.... something else.

Thanks. This is the interpretation we expected to be correct. For the sake of some future readers of the spec that may not apply the broadest meaning of "behaves" when reading "behaves as though this

Greg Favor wrote: The overriding statement in the document is this one: When misa[7] (bit H) is clear, the hart behaves as though this extension were not implemented, .... I sympathize with

I think the solution is even simpler. Even if MTVEC[1] had not been used, data dependent traps are prohibited in Risc-V (that might be too strong a word; I don't know that its explicited prohibited,

I think this is one of dozens of little mistakes you can make in bare-metal RISC-V programming, and adding an sstatus bit for it is IMO not a great allocation of resources. Hopefully you are

Lol Do you feel it is worth to add a bit in sstatus to restrict csrw stvec to 1) mask bit1~0; 2) fire an exception when writing non-0 value to bit1~0? A separate elf section can work in some

It's already used: https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc#44-new-xtvec-csr-mode-for-clic

Are we going to use bit1 soon in the future? We are wondering if we can use bit1 to indicate there’s illegal value (WLRL) – if bit1 is written with 1 then fire exception. From:

I have been bitten by this, too, but I have little in the way of advice. There are various software approaches to reduce the likelihood of encountering this problem, even if the programmer forgets to

Hi Andrew, all, The current priv spec reserves lower 2bits of mtvec (ad stvec) to indicate vectored interrupts, there’s an issue that if exception handler is word aligned but SW mis-program the

Thanks for your input, as always. I agree that, if we ultimately agree to tighten the behavior here, we need to specify the behavior for both HW and SW writes.

That sounds good. It would be great to see this software write behavior added to the Priv spec (along with whatever hardware write behavior that Allen's polling concludes with). Thanks, Greg

I focused on the HW writes to mtval when I described the Rocket core's behavior to Allen. The behavior for SW writes is that it unconditionally sign-extends from the most-significant implemented bit:

Allen, How is compliance testing going to handle this issue for software (versus hardware) writes to *tval CSRs? For example, when software writes stval with an address, how is the validity judged?

Yes: X (our implementation conforms to this constraint or implements XLEN bits)

When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address. However, the spec also says: Implementations may convert some invalid address patterns into

When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address. However, the spec also says: Implementations may convert some invalid address patterns into

It certainly has been a goal, e.g., the CLIC was designed so that M-mode software that's oblivious to the CLIC still runs correctly on systems with the CLIC. I don't think there's a clear statement of

Can someone provide a definitive answer (Andrew?) as to the architectural intent of whether implementations supporting new architecture extensions must maintain backward compatibility with "legacy" M

A bit more on that. There are a few debug CSRs which can be accessed as both CSRs and as Debug registers, specifically for communication. Otherwise, debug registers are in their own address space, and