Add per field mutable_misa config options

[Jordan Carlin (jordancarlin)]

This is one approach to fix #1517 by adding a parameter per extension that has a field in misa indicating whether the bit is writable. I think this is easier to use than a bitmask for the whole misa CSR, but that is another approach that we should consider.

[Allen Baum (allenjbaum)]

I really really really prefer the bitmap approach; it is a mechanism that can be used over and over, and if you're writing an entire CSR, that's how you want to do it instead of having to decompose it into N separate mechanisms. That single mechanism will probably handle the great majority of CSRs. MISA is just one example; there are hundreds of other CSRs that will need to do the same thing. Do't special case it.

…

On Tue, Feb 3, 2026 at 11:52 PM Jordan Carlin ***@***.***> wrote: This is one approach to fix #1517 <#1517> by adding a parameter per extension that has a field in misa indicating whether the bit is writable. I think this is easier to use than a bitmask for the whole misa CSR, but that is another approach that we should consider. ------------------------------ You can view, comment on, or merge this pull request online at: #1524 Commit Summary - b13c131 <b13c131> Add per field `mutable_misa` config options File Changes (2 files <https://github.com/riscv/sail-riscv/pull/1524/files>) - *M* config/config.json.in <https://github.com/riscv/sail-riscv/pull/1524/files#diff-b36f1a8f6855995358dfe9f8843ccb79130c81a8fe726131945d966e8ac3bf50> (30) - *M* model/core/sys_regs.sail <https://github.com/riscv/sail-riscv/pull/1524/files#diff-8361ff6a3ca7cb9fd9c94b9b654b8d20da064cfae31411d484e42c03e31e8213> (25) Patch Links: - https://github.com/riscv/sail-riscv/pull/1524.patch - https://github.com/riscv/sail-riscv/pull/1524.diff — Reply to this email directly, view it on GitHub <#1524>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJXIUR6VQWYEMJTAM2L4KGQKJAVCNFSM6AAAAACT5P64SSVHI2DSMVQWIX3LMV43ASLTON2WKOZTHA4TKMJXG4YDKMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[github-actions]

Test Results

2 117 tests  ±0   2 117 ✅ ±0   23m 40s ⏱️ -15s
    1 suites ±0       0 💤 ±0 
    1 files   ±0       0 ❌ ±0 

Results for commit b13c131. ± Comparison against base commit 0f291de.

[Tim Hutt (Timmmm)]

Yeah I'm still on the fence. I kind of think that although at first glance CSRs seem nice and uniform and a generic mechanism would work, if you look closer there are all sorts of horrible special snowflakes like seed, sstatus, senvcfg, etc.

Can we see what the alternative would look like for this PR though?

I think something like this?

private function legalize_misa(m : Misa, v : xlenbits) -> Misa = {
  let misa_writable_mask : xlenbits = config ...;
  let v = Mk_Misa(v & misa_writable_mask | m.bits & ~(misa_writable_mask));
  ...

[Tim Hutt (Timmmm)]

If C is immutable and hard-coded to 1, and you write 0, should this still ignore the entire write?

[Allen Baum (allenjbaum)]

Some CSRs are in read_only category (predefiined for the entire CSR by address) For CSRs not in that category, if there are bits/fields that are readOnly, and (possibly) others that are not, the writes to readOnly fields are ignored I am a bit puzzled about your snowflake example. Sstatus is a "restricted view" CSR, a copy of Mstatus with some bits treated as RdOnly0. I think that lends itself to a mask/value approach, with the mask having a few more bits set from the status mask (except the 2bit UXL field, FS, and VS fields are each enums with the same values taken from Mstatus. The general approach is mask/value for the, CSR as a whole, and multibit RW fields defined either by hi/lo ranges, or enum (for widths <=6b) The trickiest part is not so much legalizing the write, but legalizing the WARL definition as a subset of the spec definition with the spec'ed constraints (e.g. bits in a RW field that are defined as RdOnly in implementation are OK, or a RW field is only large <param> bits wide.

…

On Wed, Feb 4, 2026 at 5:43 AM Tim Hutt ***@***.***> wrote: ***@***.**** commented on this pull request. Yeah I'm still on the fence. I kind of think that although at first glance CSRs *seem* nice and uniform and a generic mechanism would work, if you look closer there are all sorts of horrible special snowflakes like seed, sstatus, senvcfg, etc. Can we see what the alternative would look like for this PR though? I think something like this? private function legalize_misa(m : Misa, v : xlenbits) -> Misa = { let misa_writable_mask : xlenbits = config ...; let v = Mk_Misa(v & misa_writable_mask | m.bits & ~(misa_writable_mask)); ... ------------------------------ In model/core/sys_regs.sail <#1524 (comment)>: > @@ -101,24 +98,24 @@ val ext_veto_disable_C : unit -> bool private function legalize_misa(m : Misa, v : xlenbits) -> Misa = { let v = Mk_Misa(v); - // Suppress updates to MISA if MISA is not writable or if by disabling C next PC would become misaligned or an extension vetoes - if not(sys_enable_writable_misa) | (v[C] == 0b0 & (nextPC[1] == 0b1 | ext_veto_disable_C())) + // Suppress updates to MISA if by disabling C next PC would become misaligned or an extension vetoes + if (v[C] == 0b0 & (nextPC[1] == 0b1 | ext_veto_disable_C())) If C is immutable and hard-coded to 1, and you write 0, should this still ignore the entire write? — Reply to this email directly, view it on GitHub <#1524 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJVEYYRRB2VFJH5CCWL4KHZPNAVCNFSM6AAAAACT5P64SSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTONJRGEZDENZRGI> . You are receiving this because you commented.Message ID: ***@***.***>