Ssu64xl is actually mandatory in RVA20S64 and RVA22S64 #141
Conversation
RVA20S64 is ratified and so should not be changed, but I claim this is not a semantic change. It isn't possible to implement RVA20U64 and RVA20S64 together without having implemented the Ssu64xl extension along the way. The reasoning is as follows. When SXLEN=64 (as is the case for RVA20S64), the PrivArch v1.11 spec requires the sstatus.UXL field exist and be encoded the same as MXL. The table in the M-mode chapter that describes MXL's encoding only lists 3 values (RV32=1, RV64=2, RV128=3); it does not provide for representing XLEN=64 with any value other than 2. Since RVA20U64 requires UXLEN=64, it follows that sstatus.UXL must be capable of holding the value 2, which is exactly what Ssu64xl stipulates.
RVA22S64 is ratified and so should not be changed, but I claim this is not a semantic change. It isn't possible to implement RVA22U64 and RVA22S64 together without having implemented the Ssu64xl extension along the way. The reasoning is as follows. When SXLEN=64 (as is the case for RVA22S64), the PrivArch v1.12 spec requires the sstatus.UXL field exist and be encoded the same as MXL. The table in the M-mode chapter that describes MXL's encoding only lists 3 values (RV32=1, RV64=2, RV128=3); it does not provide for representing XLEN=64 with any value other than 2. Since RVA22U64 requires UXLEN=64, it follows that sstatus.UXL must be capable of holding the value 2, which is exactly what Ssu64xl stipulates.
|
For completeness I should note that not making this change is technically acceptable. It would just be misleading, since the current text suggests a degree of optionality that doesn't exist in actuality. |
|
misa is allowed to be zero, and some could have interpreted that to mean MXL=0 was a valid setting when MXLEN=64. I agree the SXL text only refers to the non-zero encodings of MXL, but is open to this misinterpretation. Given that RVA20S64 was meant to encode current practice, keeping ssu64xl as optional would avoid an errata on implementations that had hardwired this field to zero. Given that RVA22S64 was defined at the same time as RVA20, the same optional status was preserved. It should be mandatory in RVA23S64 onwards (there is error in RVA23S64 text saying it was mandatory in RVA22S64). |
|
OK, I'll fix the RVA23S64 spec's claim that this was previously mandatory, and otherwise we can leave this alone. |
RVA20S64 and RVA22S64 are ratified and therefore mustn't be changed, but I claim that the behavior described by Ssu64xl was always mandatory anyway, and so it should have been listed as mandatory, rather than optional, all along. So this is not a semantic change.
It isn't possible to implement RVA20U64 and RVA20S64 together without having implemented the Ssu64xl extension along the way. The reasoning is as follows. When SXLEN=64 (as is the case for RVA20S64), the PrivArch v1.11 spec requires the sstatus.UXL field exist and be encoded the same as MXL. The table in the M-mode chapter that describes MXL's encoding only lists 3 values (RV32=1, RV64=2, RV128=3); it does not provide for representing XLEN=64 with any value other than 2. Since RVA20U64 requires UXLEN=64, it follows that sstatus.UXL must be capable of holding the value 2, which is exactly what Ssu64xl stipulates.
The same is true of PrivArch v1.12, and so the same argument holds for RVA22S64.