specify M-bit behaviour when there's no integer mode

[tariqkurd-repo]

The spec doesn't currently specify what to do about encodings when Zcherihybrid isn't implemented.
The proposal is:

• for RV32 - setting M in quadrant 1 gives invalid permissions
• for RV64 - M is simply a reserved bit

which seems a bit inconsistent, but it's because in RV32 it's part of the permissions encodings, whereas in RV64 it's just a separate bit, and so reserved.

[jrtc27]

It's not inconsistent if for RV32 it's a reserved encoding?

[tariqkurd-repo]

The question is whether it's _reserved_ causing a tag violation on load/store dereference, or _invalid permissions_ causing a permission violation. That's the only distinction I'm aware of between the two cases. We just need to choose one.

[jrtc27]

The question is whether it's reserved causing a tag violation on load/store dereference, or invalid permissions causing a permission violation. That's the only distinction I'm aware of between the two cases. We just need to choose one.

How would it ever have a tag?

[tariqkurd-repo]

Only if it's from memory corruption, the same as the other reserved bit + tag set cases, and invalid permission cases. We already split such cases between tag violations and permission violations. I guess which we choose here doesn't really matter but it's nice to have clean definitions.

…

On Wed, 15 Jan 2025, 18:27 Jessica Clarke, ***@***.***> wrote: The question is whether it's reserved causing a tag violation on load/store dereference, or invalid permissions causing a permission violation. That's the only distinction I'm aware of between the two cases. We just need to choose one. How would it ever have a tag? — Reply to this email directly, view it on GitHub <#507 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOCTJACIBTQGJTN5GUFTJ332K2LAXAVCNFSM6AAAAABVHXFSEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJTGUZTONBSGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[arichardson]

If it's easier for consistency we could move the M bit into AP for RV64 as well? And then just treat it as a reserved permission? IMO this doesn't change anything from an implementation point just the spec wording.

[jrtc27]

I don't like thinking of it as a permission any more than necessary, it'll confuse people...

[arichardson]

I don't like thinking of it as a permission any more than necessary, it'll confuse people...

That's a good point since it's not restricted to monotonic behaviour. Probably better to keep it conceptually separate for RV64.

[jamie-melling]

I've done a review of all the cases where "reserved bits set" and "invalid perms" are checked/used.

Instruction	Reserved Bits set	Inv perms
ACPERM	clear cd tag	set all perms to 0
GCPERM	-	Return 0
jmp/br/ld/st	Tag except	Perm except
CADD/SCADDR etc	clear cd tag	-
SCBNDS etc	clear cd tag	-
SCSS & CBLD	clear cd tag	clear cd tag
CSR	clear CSR tag	clear CSR tag
LC data dependent strip*	-	cd perms =0 or unchanged

LC data dependent strip* -> this is the load mutable and Zcherilevels rules applied to loaded capabilities. The option is to return perms as 0 or not to strip any perms. This is because you wouldn't want to take an invalid/reserved input and legalize it by following the LM + zcherilevel's rules.

[jrtc27]

I'm still concerned that for RV32 this is allocating the bit / AP encodings for M even when not implemented, when instead they should all be reserved encodings that can be allocated for a different purpose by another extension. This is particularly important given the limited encoding space available on RV32; it is quite likely that a capability mode-only RV32 implementation would have a use for those encodings.

[tariqkurd-repo]

That's fair comment, it's restricting the usage to permissions.

…

On Thu, 16 Jan 2025, 15:17 Jessica Clarke, ***@***.***> wrote: I'm still concerned that for RV32 this is allocating the bit / AP encodings for M even when not implemented, when instead they should all be *reserved* encodings that can be allocated for a different purpose by another extension. This is particularly important given the limited encoding space available on RV32; it is quite likely that a capability mode-only RV32 implementation would have a use for those encodings. — Reply to this email directly, view it on GitHub <#507 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOCTJAFKAWUL42LXGM5VJG32K65PPAVCNFSM6AAAAABVHXFSEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJVHA2DQMZZGE> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[jrtc27]

That's fair comment, it's restricting the usage to permissions.

Not just permissions, it's enforcing it as being M.

[tariqkurd-repo]

This is fair comment - the way that the bit is encoded means that it can only represent something which is used for code-capabilities in future - so some other attribute we havne't though of yet. It effectively means that bit 0 of quadrant 1 for RV32 only is up for grabs.