What's the difference between "RV32 only" and "*XLEN=32 only"

[liweiwei90]

In current privilege spec, most upper half CSRs are described as "RV32 only". But htimedeltah is described as "HSXLEN=32 only", and mseccfgh is described as "RV32 only" and "MXLEN=32 only" in two different position(Table 2.5 and section 3.1.19).

Does "RV32 only" mean "MXLEN=32 only" or "*XLEN=32 only" based on privilege mode of the CSRs?

If so, how about "RV32 only" instructions?

[aswaterman]

In the unprivileged spec, "XLEN=32 only" and "RV32 only" mean the same thing.

HSXLEN=32 means something more specific: it means RV32 is the selected mode within HS-mode. (Recall that different modes can have different XLEN.)

[liweiwei90]

@aswaterman Thanks for your explanation. However, I still have some question:

• As most of the length of CSRs for different modes is related to the XLEN for that mode. -- if MXLEN=64, HSXLEN=32, and we try to access 64bits CSR such as henvcfg from M-mode, is low 32 bits of henvcfg accessed? And whether it's legal to access henvcfgh in this case? -- What's the XLEN for unprivileged CSRs? U-mode or VU-mode or current XLEN?

• If we do a back-to-back change MXLEN (64-> 32->64), whether the high half of CSRs are cleared?

• If we change mstatus.sxl to 1(32 bits), whether mstatus.uxl should be also auto-updated to 1 since UXLEN=SXLEN=32 when SXLEN=32 for sstatus CSR? If so, whether mstatus.uxl is read-only when mstatus.sxl is 1?

[aswaterman]

@jhauser-us should confirm my answers, but I think that:

• The currently active XLEN is the one that matters, so HSXLEN is not relevant in M-mode. The full henvcfg is accessed, and henvcfgh is illegal.
• The back-to-back change preserves the upper half of henvcfg.
• It is implementation-defined what happens to UXL in this case. M-mode software should set UXL=1 when setting SXL=1.

[liweiwei90]

• The currently active XLEN is the one that matters, so HSXLEN is not relevant in M-mode. The full henvcfg is accessed, and henvcfgh is illegal.

However, the length of henvcfg is stated as HSXLEN in the spec.

[jhauser-us]

@liweiwei90: Thanks for raising this issue. I'm sorry the issue has languished for so long without a proper resolution. The Architecture Review Committee discussed the matter earlier this week and is working to provide a clarification/correction soon for Privileged ISA version 1.13.

In 1.13, CSRs henvcfg and htimedelta will be described as always being 64-bit, even for RV32. Also, the high-half CSRs henvcfgh and htimedeltah will exist only for RV32 code (that is, only when the current XLEN = 32). With these fixes, it should become clear that accesses to these CSRs will work the same way that accesses to 64-bit unprivileged counters do (time/timeh, cycle/cycleh, etc.).

[liweiwei90]

Thanks for your clarification. If henvcfgh/htimedeltah will exist only when the current XLEN == 32 instead of HSXLEN == 32, do you mean the length of other *XLEN CSRs will also be current XLEN? Or this is only suitable to the always 64-bit CSRs?

[jhauser-us]

do you mean the length of other XLEN CSRs will also be current* XLEN?

No.

Or this is only suitable to the always 64-bit CSRs?

For CSRs that are always 64-bit (like henvcfg), high-half CSRs (like henvcfgh) will be accessible only when the current XLEN = 32, i.e., only for RV32 code.

[liweiwei90]

OK. Thanks.

[jhauser-us]

Should be addressed by commit f0f67a2.