Describe misaligned data access scenarios #2
Conversation
riscv-unix.md
Outdated
| 3. *v<sub>0</sub>* is a permissible virtual address; *v<sub>1</sub>* lies | ||
| in a different, impermissible page. | ||
| The access raises a page-fault exception with a trap value equal | ||
| to the base virtual address of the page containing *v<sub>l</sub>*. |
There was a problem hiding this comment.
Is that a L instead of a "one"?
| 2. Loads and stores to *P* succeed without guarantee of atomicity. | ||
|
|
||
| 3. Loads and stores to *P* proceed partially, then raise access exceptions. | ||
| No register writebacks occur. |
There was a problem hiding this comment.
This is awkward. What's the reason for it?
There was a problem hiding this comment.
This happens when emulating misaligned loads & stores in M-mode software, when the access spans two pages. The load or store proceeds bytewise but encounters a page fault or access exception once it hits the second page.
This means that a store can complete partially then trap. For loads, it only matters for memory regions that have side effects. Usually, the load case will never happen, since such regions should forbid misaligned accesses altogether.
aswaterman
force-pushed
the
misaligned
branch
from
1900c7a
to
783f27c
Compare
|
@palmer-dabbelt is this still the right place to discuss this matter? |
|
Hey, we just ran into the misaligned access issues in the oreboot project. It made us realize that a RISC-V platform can only be considered one when a note on the behavior regarding misaligned access is part of it. I.e., the same code that runs perfectly on one processor would otherwise act different on another one with the same profile, or with significant performance loss. I also noticed a handful of other PRs here without response or gotten stuck. Can I help out somehow? |
No description provided.