As an example, consider page fault handling for a situation where part of access is valid and other part is not, especially for store operation. Or out-of-order execution. Or, for whatever sake, "load multiple" from PC (which is exposed to programmer in quite peculiar way) - you have to have it.
ARM is full of these quirks. I can see why they did that back in the day, but today or even 30 years ago these quirks are not a good decisions.
It has been replaced with LDP (load pair, i.e load two registers) which is not nearly as nice for software developers but made the life of the ARM designers much easier. For comparison:
https://elixir.bootlin.com/linux/v4.14.52/source/arch/arm64/...
https://elixir.bootlin.com/linux/v4.14.52/source/arch/arm/ke...
BUT, I don't think we will see real benefits of this unless we remove aarch32 support from ARMv8.
• Support AArch32 at EL0-EL3 (everywhere)
• Support AArch32 at EL0 (user mode)
• No AArch32 support
The most fielded cores fall into the first category. The newer cores - A76 and it’s contemporaries IIRC - fall into the second category. Only it’s recently disclosed data center cores fall into the third category.
As an example, consider page fault handling for a situation where part of access is valid and other part is not, especially for store operation.
You do a check for the full range before the access, because for best performance you would want to pull in as much as possible in one go anyway.
Or out-of-order execution.
Everything gets turned into uops, this instruction can emit more than one.
"load multiple" from PC (which is exposed to programmer in quite peculiar way)
What's hard about that?
Cache coherence across cores is easy. The number of corner cases is much smaller.
The number of corner cases of old architectures (MIPS, or SPARC) is staggering. I designed a MIPS core prototype and I was done in single week with all arithmetic and memory access commands and spent three weeks designing, implementing and debugging branch handling, due to branch delay slot "feature".
>You do a check for the full range before the access, because for best performance you would want to pull in as much as possible in one go anyway.
You cannot do that - pull as much as possible in one go, - for case page boundary is crossed. But the very fact that you have to check before issuing operation make things more complex than they can be.
>>"load multiple" from PC (which is exposed to programmer in quite peculiar way)
>What's hard about that?
State handling. Can this instruction be interrupted?
>>Or out-of-order execution.
>Everything gets turned into uops, this instruction can emit more than one.
There are more than "everything gets turned into uops" out-of-order execution engines - scoreboarding, for example, provides most of benefits for much less energy cost.
I think PowerPC's EIEIO wins on cute.
The OS has to handle this case anyway 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 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.
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.
Thus, I cannot agree with you on "every hardware architecture walked back".
https://en.wikipedia.org/wiki/Lexra - for an historical expose.
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.