Aligned access config options are confusing

[Timmmm]

See #1468 for more discussion.

Currently we have these options that affect the behaviour of misaligned memory accesses:

memory.misaligned.supported : bool - this is a global option that applies to all accesses. It checks the alignment of the virtual address before translation and raises a misaligned address exception if it's not aligned. This is intended for CPUs that don't support misaligned access at all.

memory.misaligned.allowed_within_exp : range(0, 11) - after the memory.misaligned.supported check and still before translation we check if the access is within an aligned region size 2^allowed_within_exp. If it isn't we split it into multiple aligned memory accesses. This is used to handle page-crossing accesses and probably Zama16b (accesses that don't cross a 16-byte boundary are atomic).

memory.misaligned.byte_by_byte : bool - when an access is split into multiple memory operations due to allowed_within_exp then it is either split into maximally-sized aligned operations, or single-byte operations depending on the value of this setting.

memory.misaligned.order_decreasing : bool - this just controls the order of the operations.

After all of those settings are applied, we do address translation to the N memory operations, look up the PMA, and then apply the PMA option:

memory.regions[N].attributes.misaligned_fault : "NoFault"/"AccessFault"/"AlignmentFault" - if the physical address of the memory operation is misaligned and this is not NoFault then we raise an exception of the given kind.

I tried to capture most of this in a flow chart:

There are some things we need to resolve:

• We need to document this better.
• "AlignmentFault" is probably the wrong word since it's never referred to as a "fault" in the ISA manual. (What even is a fault?)
• It's a bit weird that we split into multiple memory operations before address translation. For example if byte_by_byte is true then each byte is translated separately. We should only ever need to do a max of two address translations.
• The flow of the code is kind of weird and doesn't actually match the above flow chart (though the result is the same). I think it could be simplified.
• Whether or not these options apply to atomics or instruction fetch is undefined, because we never do misaligned instruction fetch and misaligned atomics aren't supported by the model yet.
• The names memory.misaligned.supported and memory.misaligned.allowed_within_exp kind of sound like they do the same thing, but in fact one causes an exception and one splits up the access. We should make the names clearer, e.g. memory.misaligned.dont_split_if_within_exp or something like that.

[pmundkur]

This is great! It would be good to eventually explicitly differentiate load/stores and atomics in the diagram, to clarify handling for extensions like Zicclsm and Zama16b.

[Alasdair]

It's a bit weird that we split into multiple memory operations before address translation. For example if byte_by_byte is true then each byte is translated separately. We should only ever need to do a max of two address translations.

That's true, but we need to think about what is the most relaxed permitted behaviour. In particular, what is allowed to happen when another hart is modifying the page tables concurrently with the hart doing the address translation. Byte-by-byte accesses with individual per-byte translations should give us that behaviour.

[allenjbaum]

The first two together appear to define the "misaligned_has_higher_priority_than_page,access-fault" option. You could combine it into just one, because the first is a special case of the second, where the boundary is not a constant, but the size of the access. (which could be signalled with the parameter being negative)

…

On Wed, Jan 28, 2026 at 6:05 AM Alasdair Armstrong ***@***.***> wrote: *Alasdair* left a comment (riscv/sail-riscv#1506) <#1506 (comment)> It's a bit weird that we split into multiple memory operations before address translation. For example if byte_by_byte is true then each byte is translated separately. We should only ever need to do a max of two address translations. That's true, but we need to think about what is the most relaxed permitted behaviour. In particular, what is allowed to happen when another hart is modifying the page tables concurrently with the hart doing the address translation. Byte-by-byte accesses with individual per-byte translations should give us that behaviour. — Reply to this email directly, view it on GitHub <#1506 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJTJDYRUQ2DKJMARKSL4JC6ZJAVCNFSM6AAAAACTEWV3OWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMJRGUYDONJYGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Timmmm]

Not quite - the first one (memory.misaligned.supported) causes an exception if it fails, whereas the second one (memory.misaligned.allowed_within_exp) splits the access up into multiple operations if it fails.

That's not very clear from the names tbf so I'll add that to the todo list!

[pmundkur]

Another thing @jordancarlin brought up was to make sure during config validation that if the global memory.misaligned option disallowed misaligned accesses, that none of the PMA regions allowed misaligned. Perhaps this should be a warning if not an error.