You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can't see anywhere in the spec what to do with the mode bit when there is no Zcherihybrid.
If you have a purecap only machine and a capability has the Mode-bit set, should this be treated as an invalid permission or as a reserved bit set? I think invalid permission might make more sense for RV32 systems as the mode bit is part of the AP encoding.
However, for RV64, reserved bit makes more sense but it would be a bad idea to have an inconsistency between RV64 and RV32.
While searching the spec, the only thing I could find was
When MXLEN=64, the Mode is encoded separately; a new CHERI Execution Mode Encoding field
is added to the capability format as shown in Table 5. The CHERI Execution Mode Encoding is
only valid for code capabilities, otherwise the field is reserved.
I think it might be better to reword the last sentence as
The CHERI Execution Mode Encoding is only valid for code capabilities, otherwise, the combination Mode bit set for non-executable capabilities is reserved for future use.
The text was updated successfully, but these errors were encountered:
I can't see anywhere in the spec what to do with the mode bit when there is no Zcherihybrid.
If you have a purecap only machine and a capability has the Mode-bit set, should this be treated as an invalid permission or as a reserved bit set? I think invalid permission might make more sense for RV32 systems as the mode bit is part of the AP encoding.
However, for RV64, reserved bit makes more sense but it would be a bad idea to have an inconsistency between RV64 and RV32.
While searching the spec, the only thing I could find was
I think it might be better to reword the last sentence as
The text was updated successfully, but these errors were encountered: