fix removing SL from quadrant 1

Author: tariqkurd-repo

src/insns/acperm_32bit.adoc

@@ -50,7 +50,7 @@ The rules from <<acperm_rules>> must be followed when removing permissions.
 |  6  (RV32 only) | <<x_perm>>   | <<w_perm>> or <<c_perm>>
 |  7              | <<el_perm>>  | <<c_perm>> and <<r_perm>>
 |  8              | <<lm_perm>>  | <<c_perm>> and <<r_perm>>
-|  9  (RV32 only) | <<x_perm>>   | <<c_perm>> == <<lm_perm>> == <<el_perm>>
+|  9  (RV32 only) | <<x_perm>>   | (<<c_perm>> == <<lm_perm>> == <<el_perm>>) and (<<sl_perm>> == ∞)
 | 10              | <<sl_perm>>  | <<c_perm>>
 | 11              | <<asr_perm>> | <<x_perm>>
 | 12              | <<m_bit>>    | <<x_perm>>

src/level-ext.adoc

@@ -74,14 +74,14 @@ endif::[]
 11+| bit[0] - <<m_bit>> ({CAP_MODE_VALUE}-{cheri_cap_mode_name}, {INT_MODE_VALUE}-{cheri_int_mode_name})
 |Bits[4:3]| R | W | C | LM | EL | SL  | X | ASR | Mode^1^ |
 | 0-1   | ✔ | ✔ | ✔ | ✔  | ✔  | ∞   | ✔ |  ✔  | Mode^1^  | Execute + ASR (see <<infinite-cap>>)
-| 2-3   | ✔ |   | ✔ | ✔  | ✔  | ∞   | ✔ |     | Mode^1^  | Execute + Data & Cap RO
+| 2-3   | ✔ |   | ✔ | ✔  | ✔  | ∞^1^| ✔ |     | Mode^1^  | Execute + Data & Cap RO
 | 4-5   | ✔ | ✔ | ✔ | ✔  | ✔  | ∞   | ✔ |     | Mode^1^  | Execute + Data & Cap RW
-| 6-7   | ✔ | ✔ |   |    |    | N/A | ✔ |     | Mode^1^  | Execute + Data RW
+| 6-7   | ✔ | ✔ |   |    |    | ∞^1^| ✔ |     | Mode^1^  | Execute + Data RW
 11+| *Quadrant 2: Restricted capability data read/write*
 11+| bit[2] = write, bit[1:0] = store level. R and C implicitly granted, LM dependent on W permission.
 |Bits[4:3]| R | W | C | LM | EL | SL    | X | ASR | Mode^1^ |
 | 0-2   10+| reserved
-| 3       | ✔ |   | ✔ |    |    | N/A   |   |     | N/A | Data & Cap R0 (without <<lm_perm>>)
+| 3       | ✔ |   | ✔ |    |    | ∞^1^  |   |     | N/A | Data & Cap R0 (without <<lm_perm>>)
 | 4       | ✔ | ✔ | ✔ | ✔  |    | _(3)_ |   |     | N/A | Reserved for `LVLBITS=2`
 | 5       | ✔ | ✔ | ✔ | ✔  |    | _(2)_ |   |     | N/A | Reserved for `LVLBITS=2`
 | 6       | ✔ | ✔ | ✔ | ✔  |    | 1     |   |     | N/A | Data & Cap RW (with store _local_, no <<el_perm>>)
@@ -91,13 +91,15 @@ endif::[]
 11+| _Reserved bits for future extensions must be 1 so they are implicitly granted_
 |Bits[4:3]| R | W | C | LM | EL | SL    | X | ASR | Mode^1^ |
 | 0-2   10+| reserved
-| 3       | ✔ |   | ✔ | ✔  | ✔  | N/A   |   |     | N/A | Data & Cap R0
+| 3       | ✔ |   | ✔ | ✔  | ✔  | ∞^1^  |   |     | N/A | Data & Cap R0
 | 4       | ✔ | ✔ | ✔ | ✔  | ✔  | _(3)_ |   |     | N/A | Reserved for `LVLBITS=2`
 | 5       | ✔ | ✔ | ✔ | ✔  | ✔  | _(2)_ |   |     | N/A | Reserved for `LVLBITS=2`
 | 6       | ✔ | ✔ | ✔ | ✔  | ✔  | 1     |   |     | N/A | Data & Cap RW (with store _local_)
 | 7       | ✔ | ✔ | ✔ | ✔  | ✔  | 0     |   |     | N/A | Data & Cap RW (no store _local_)
 |==============================================================================
 
+^1^ SL isn't applicable in these cases, but is specified as ∞ to help the definition of <<ACPERM>>
+
 [#section_cap_level_change]
 === Changing capability levels and permissions
 While capability levels (<<section_cap_level,CL>>) are conceptually a label on the capability rather than a permission granted by the capability, they are adjusted using the <<ACPERM>> instruction.