Closed tomaird closed 3 weeks ago
Hmm, that does seem odd. I suspect it's a hangover from before we had mode-dependent CSR access?
I think this might be from when we added new CSRs instead of extending existing ones. Maybe the rationale was that updating the address on these is not useful behaviour and most likely to be a programming mistake.
I think this restriction is not required so for consistency we should probably drop it.
If this restriction is dropped, there should be some other clarification on what action to take on writing a non-extended CLEN CSR in integer pointer mode, ideally just adding them to the CLEN CSR tables at the end of the spec
ok, this gets added to the list. I think the intended spec is clear, we just need to bring the doc up to date to match it.
In section 5.4.4 CSR Instructions, there is this section:
Where Table 25 lists: dddc, mtdc, stdc, vstdc, ddc
Is it correct for these CSRs to raise an exception? This seems inconsistent with accessing other CLEN CSRs in integer pointer mode where only the XLEN address (and possibly the tag) is updated. If it is correct, what is the motivation behind it?