5 ms·
This instruction makes design of ARM CPUs harder. As an example, consider page fault handling for a situation where part of access is valid and other part is n
by thesz 6y ago
This instruction makes design of ARM CPUs harder.
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.
- saagarjha 6y agoWhat, you don’t like xoring (or should I say, eoring…thanks ARM) the program counter?
- fanf2 6y agoARM got the EOR spelling from the 6502.
- dspillett 6y agoI always preferred EOR. Maybe the cute factor, or maybe because I first played with assembly language on an Acorn Electron (and later a full BBC Master Series) where I think the nomenclature comes from (the 6502 assembler built into BBC BASIC called the instruction EOR). ARM was originally Acorn Risk Machines, and the original designs evolved from the CPUs designed for the Acorn Archimedes range of computers.
- mwcremer 6y agothe cute factor I think PowerPC's EIEIO wins on cute.
- deleted 6y ago[deleted]
- smallpipe 6y agoVery true, but that’s the classic 32b arch only, aarch64 is much cleaner. The next big A class CPUs will be aarch64 only.
- panpanna 6y agoYes, this instruction was removed in 64-bit arm for this very reason. 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/kernel/entry.S#L308 https://elixir.bootlin.com/linux/v4.14.52/source/arch/arm64/... https://elixir.bootlin.com/linux/v4.14.52/source/arch/arm/kernel/entry-armv.S#L167 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.
- gok 6y agoMany aarch64 chips have no aarch32 support for reasons like this
- repiret 6y agoMany? Arm Ltd designed Armv8-a chips fall into three tiers: • 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.
- gecko 6y agoI've heard POWER engineers kvetch for the same reason about lm/lmw (Load Multiple Word, which is an equivalent instruction). I recall discussion about whether to deprecate it, but, as far as I'm aware, it's still a legal instruction as of 2020.
- userbinator 6y agoIf that is "hard", I would hate to see what you think of things like cache coherency across cores... 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?
- thesz 6y ago>If that is "hard", I would hate to see what you think of things like cache coherency across cores... 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.
- brandmeyer 6y ago> As an example, consider page fault handling for a situation where part of access is valid and other part is not, The OS has to handle this case anyway for misaligned loads and stores.
- thesz 6y agoThe 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.
- brandmeyer 6y agoUnaligned loads and stores are not atomic. 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.
- thesz 6y agoWhat 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.
- brandmeyer 6y ago> 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.