Ensure GCPERM result is forwards-compatible with software

src/img/acperm_bit_field.edn

@@ -6,13 +6,14 @@
 (def left-margin 100)
 (def right-margin 100)
 (def boxes-per-row 32)
-(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "1" "2" "3" "4" "5" "6" "" "" "SDPLEN+5" "" "" "" "" "" "15" "16" "17" "18" "19" "" "" "" "" "" "" "" "" "" "" "" "XLEN-1"])})
+(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "1" "2" "3" "4" "5" "6" "" "" "SDPLEN+5" "" "" "" "" "" "15" "16" "17" "18" "19" "" "23" "" "" "" "" "" "" "" "" "" "XLEN-1"])})
 
-(draw-box "Reserved" {:span 13})
+(draw-box "Reserved 0" {:span 10})
+(draw-box "Reserved 1" {:span 3})
 (draw-box "R"        {:span 1})
 (draw-box "X"        {:span 1})
 (draw-box "ASR"      {:span 1})
-(draw-box "Reserved" {:span 6})
+(draw-box "Reserved 1" {:span 6})
 (draw-box "SDP"      {:span 4})
 (draw-box "C"        {:span 1})
 (draw-box "CL"       {:span 1})
@@ -21,7 +22,8 @@
 (draw-box "LM"       {:span 1})
 (draw-box "W"        {:span 1})
 
-(draw-box "XLEN-19"   {:span 13 :borders {}})
+(draw-box "XLEN-23"   {:span 10 :borders {}})
+(draw-box "5"         {:span 3 :borders {}})
 (draw-box "1"         {:span 1 :borders {}})
 (draw-box "1"         {:span 1 :borders {}})
 (draw-box "1"         {:span 1 :borders {}})

src/insns/acperm_32bit.adoc

@@ -80,9 +80,14 @@ The behavior of currently illegal combinations from <<acperm_rules>> is to clear
 [#acperm_bit_field]
 include::../img/acperm_bit_field.edn[]
 
-NOTE: The <<el_perm,EL>>, <<sl_perm,SL>> and <<section_cap_level,CL>> fields are only defined if the implementation supports <<cheri_levels_ext,{cheri_levels_ext_name}>>.
+NOTE: The <<el_perm,EL>>, <<sl_perm,SL>> and <<section_cap_level,CL>> fields are only modifiable if the implementation supports <<cheri_levels_ext,{cheri_levels_ext_name}>>.
 
-NOTE: Even though being included here <<section_cap_level,CL>> is not considered an architectural permission.
+
+NOTE: Even though included here <<section_cap_level,CL>> is not considered an architectural permission.
+
+
+NOTE: If a future extension adds a new permission that is a refinement of an existing permission (e.g. finer-grained <<asr_perm>>), then clearing the superset must also clear the refined permission.
+This ensures software forward-compatibility: for example, a kernel that does not know about finer-grained <<asr_perm>> subsets must still be able to prevent all access to privileged instructions and CSRs by clearing <<asr_perm>>.
 
 Exceptions::
 include::require_cre.adoc[]

src/insns/gcperm_32bit.adoc

@@ -25,6 +25,7 @@ Convert the unpacked AP permissions as well as the SDP fields of capability `cs1
 into a bit field, with the format shown in xref:gcperm_bit_field[xrefstyle=short],
 and write the result to `rd`. A bit set to 1 in the bit field indicates that
 `cs1` grants the corresponding permission.
+All bits in the `[0:23]` range that are reserved or assigned to extensions that are not implemented by the current hart always report 1.
 +
 If the AP field cannot be produced by <<ACPERM>> then all architectural
 permission bits in `rd` are set to 0.
@@ -33,6 +34,12 @@ permission bits in `rd` are set to 0.
 [#gcperm_bit_field]
 include::../img/acperm_bit_field.edn[]
 
+NOTE: When {cheri_levels_ext_name} is not implemented, the `CL`, `SL`, and `EL` fields always report 1.
+This ensures forwards-compatibility since loads/stores on a core without {cheri_levels_ext_name} behave as if these permissions are always present.
+
+NOTE: Any future extension that defines new permission that are a refinement of existing permissions (e.g. finer-grained <<asr_perm>>) must be allocated to the bits that are currently reported as 1 to ensure forward-compatibility.
+Completely new permissions (e.g. sealing) should use the bits that are reported as zero in the current specification.
+
 Exceptions::
 include::require_cre.adoc[]