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

Also a good implementation approach - adding a second variation to what WARL compliance testing would probably need to allow for. At the end of the day, with both the "1-bit" and "2-bit" schemes, one

One could view the effect of MPRV as changing the mode that is in effect for a memory access. For *tval purposes that end result is all that matters. Ditto for the new-ish HLV/HLVX/HSV

The Rocket approach works here if you set the width of mtval to 1+max(VAbits,PAbits) and then sign-extend from the most-significant implemented bit. The extra 1 bit allows for zero-extension of PAs.

You said: Sign extend if translated Zero extend otherwise (I don’t think that’s is quite the same as Bare+Mmode because of MPRV, and not sure how hypervisor modes affect that) Then you said

Coming back to designs where the implemented PA size is greater than the supported VA size (for example, 48b VA's and 50b+ PA's), and in contrast to always sign-extending when VA size is greater than

It seems like Mark's FAQ suggestion was more general and different from his specific "well documented guidance" comment on this particular issue. To me this particular guidance would belong in the

I think it's the kind of thing that belongs in the FAQ that Mark mentioned in his previous email.

This seems like a fairly big nail in the coffin for answer "A". And responses by others (e.g. Anup and Mark) also fall on the side of answer "B". Are we at a point to call the ball, i.e. adopt answer

Thank you. If I understand this correctly I agree with all you have said. If this is a once at boot time requirement regardless of mode and there is a reasonable way to do it, then i concur that well

FWIW, I think supervisor mode already follows answer "B", inasmuch as the satp and medeleg registers are not reset. Consider M-mode software written to run on a system with only M and U modes, but

This would seem to argue for answer "B" to my question. I find this preferable since it doesn't require architecture extension spec's to specify additional arch state that must be initialized by hart

Mark, Hi and welcome on board the RISC-V train. I agree with the general broad issue of ecosystem compatibility and support. The much narrower current question is whether the issue I'm touching on

how is this intended to work with versions? so we ratify some 1.0 spec and we come along and call it 1.1 that has additive changes, i thought i heard that ecosystem around risc-v including compilers

The M-mode runtime firmware cannot be totally unaware of new extensions. At least, this is true for H-extension. Currently M-mode runtime firmware (OpenSBI) does following to support

I want to bring back up the Yes/No question I posed a couple of weeks ago - in which I was looking for a clear architectural statement of principle as to whether: A) A new architecture extension must

Jonathan Behrens wrote: It seems obvious, right? :^) A small problem is that most of the extensions are actually defined in the unprivileged ISA document, which speaks a few times of

My response to Allen's post and my use of "unimplemented" in quotes was referring to the H extension spec's statement that "When misa[7] is clear, the hart behaves as though this extension were not

Couldn't you just change the wording to be "disabled" when referring to having misa.H=0 and leave "unimplemented" to mean having misa.H hardwired to 0? Jonathan

While I would have to go through all the bits/fields affected by the H extension to double-check, the main issue are bits/fields that were previously reserved (and hardwired to zero). So there isn't