specify M-bit behaviour when there's no integer mode (#507)

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.

src/insns/acperm_32bit.adoc

@@ -61,12 +61,14 @@ The rules from <<acperm_rules>> must be followed when removing permissions.
 | 13  (RV32 only) | <<x_perm>>   | (<<c_perm>> and <<lm_perm>> and <<el_perm>> and (<<sl_perm>> == ∞)) or +
                                    (not(<<c_perm>> and not(<<lm_perm>>) and not(<<el_perm>>) and (<<sl_perm>>==0)))^1^
 | 14              | <<asr_perm>> | <<x_perm>>
-| 15^2^           | <<m_bit>>    | <<x_perm>>
+| 15^2^ (RV32 only) | <<m_bit>>  | <<x_perm>> and {cheri_default_ext_name} is implemented
 |===
 
 ^1^ All the listed permissions in the set are either minimum or maximum. +
-^2^ The <<m_bit>> only exists if {cheri_default_ext_name} is implemented.
- Otherwise it is reserved and this rule is not relevant.
+^2^ For RV32, the encodings which have the <<m_bit>> set to {int_mode_value} for {cheri_int_mode_name}
+ are only valid if {cheri_default_ext_name} is implemented. Otherwise those encodings represent invalid permissions.
+
+CAUTION: For RV64 without {cheri_default_ext_name}, the <<m_bit>> is a _reserved_ bit, and so is not relevant to ACPERM.
 
 The behavior of currently illegal combinations from <<acperm_rules>> is to clear the permission if invalid (or in the case of <<sl_perm>> set it to 0 (_local_)).
 

src/riscv-hybrid-integration.adoc

@@ -22,7 +22,7 @@ is a new unprivileged register: the default data capability, <<ddc>>, that is
 used to authorize all data memory accesses when in
 {cheri_int_mode_name}.
 
-The current CHERI execution mode is given by the <<m_bit>> field of <<pcc>> that
+The current CHERI execution mode is given by the <<m_bit>> of <<pcc>> that
 is encoded as described in xref:m_bit[xrefstyle=short].
 
 The CHERI execution mode impacts the instruction set in the following ways:
@@ -55,7 +55,7 @@ Setting both registers to <<infinite-cap>> ensures that:
 * The bounds authorize accesses to the entire address space i.e base is 0 and
 top is 2^MXLEN^
 
-[#m_bit,reftext="CHERI Execution Mode Encoding"]
+[#m_bit,reftext="M-bit"]
 === CHERI Execution Mode Encoding
 
 {cheri_default_ext_name} adds a new CHERI execution Mode field (M) to
@@ -66,10 +66,15 @@ when the <<x_perm>> is set.
 _even though it is not a permission_ as shown in <<cap_perms_encoding32>>.
 ** Only quadrant 1 represents executable capabilities, and so it's the only
 one which encodes the Mode.
-* When MXLEN=64, the Mode is encoded separately; a new <<m_bit>> field is
+** If {cheri_default_ext_name} not implemented, then setting the <<m_bit>> to
+ {int_mode_value} for {cheri_int_mode_name} in quadrant 1 causes the permissions
+ to be invalid, i.e. an encoding which cannot be produced by <<ACPERM>>.
+* When MXLEN=64, the Mode is encoded separately; a new <<m_bit>> is
 added to the capability format as shown in
 xref:cap_perms_encoding64[xrefstyle=short].
 The <<m_bit>> is only valid for code capabilities, otherwise the field is reserved.
+** When {cheri_default_ext_name} is not implemented then the bit allocated to the <<m_bit>>
+ is _reserved_ for future use.
 
 NOTE: Mode is encoded with permissions for MXLEN=32, but is not a permission. It is
 orthogonal to permissions as it can vary arbitrarily using <<SCMODE>>.