The hardware has to handle this case for misaligned loads and stores.
Are load and store (multiple or misaligned) atomic? If so, then hardware has to check things in advance and trap. If not, then there is a possibility for some part of state to be lost.
Misaligned loads and stores that cross page boundaries are handled by the OS and hardware together. The OS must ensure that the post-condition of the page-fault handler leaves both pages on either side of the boundary in an accessible state.
What I am looking for is not "accessible" but "consistent".
What you describe above makes hardware design harder (one has to split unaligned access into two (unnecessary) microoperations which preclude or make harder to use techniques simpler than out-of-order execution engine with content-addressable memory). It also makes software handling harder.
One can designate unaligned access as "undefined behavior" and leave it to compiler writers to make things right.
> One can designate unaligned access as "undefined behavior" and leave it to compiler writers to make things right.
Lots of hardware architectures have tried to levy this requirement on the software. Every one has subsequently walked it back and provided unaligned access support in hardware. Even RISC-V, which is as orthodox a RISC as it gets, supports unaligned access in hardware.
So that's got to be the baseline for deciding how much additional work must be performed when supporting something new: Any memory instruction may touch two pages, but the vast majority of them won't.
MIPS has four (two instructions for loads and two for stores) instructions exactly for unaligned access situation, when it cannot be handled in software. This is exactly what I am talking about. BTW, MIPS were proud that their ISA is as good as microcode, and the solution with two instructions is exactly that - expose as much of abstract internals as possible.
Thus, I cannot agree with you on "every hardware architecture walked back".
MIPS did in fact walk it back with MIPSr6 and nanoMIPS. The old unaligned-half-access instructions were dropped entirely, and most memory access instructions support unaligned access natively.
It contains "possibly via trapping" which I am not at all against of. What is interesting there that MIPS introduced BALIGN instruction which reminds me of first generation of Alpha ISA.
Alpha did not had byte or word (16-bit) memory access. These should be provided using 32-bit word access and some shuffling. They walked back on that for code size reasons and later Alpha ISAs had byte and 16-bit loads and stores. I do not have reference ready but I believe they were aligned accesses.
The OS has to handle this case anyway for misaligned loads and stores.