Hacker News Reader

Its not meaningful to distinguish Thumb and Thumb2 - Thumb2 was just a bunch of new instructions added to Thumb.

A typical ARMv8-A processor needs to decode the A64, A32 and T32 instruction sets, but that doesn't strike me as a significant burden. A32 and T32 are essentially just different encodings of the same instruction set - there are very few A32 or T32 instructions that don't have an equal in the other instruction set. A64 has more and wider registers, but is otherwise broadly similar in capabilities. I would expect that most ARMv8-A implementations unify the three instruction sets very early in the decoding process.

Retaining the system level aspects of AArch32 strikes me as more expensive, especially support for short page tables, the subtly different system register layout, the more complex relationship between PSTATE.M and the security state, and the banked system registers between the secure and non-secure states. I'm surprised ARM-designed cores haven't pushed harder to eliminate AArch32 at the higher exception levels (although I'm aware of some cores designed by ARM Architecture licensees that do so). Perhaps that ARM has retained AArch32 all the way up to EL3 is evidence that they believe doing so isn't very expensive.

> I'm surprised ARM-designed cores haven't pushed harder to eliminate AArch32 at the higher exception levels

It seems like they are very slowly phasing it out and heading to 64-bit only. A32 ISA is only supported in userspace mode (EL0) on the Cortex-A76[1].

[1] https://www.theregister.co.uk/2018/05/31/arm_cortex_a76/

> That's... not the way hardware works. Those transistors are still there, it's not like you can make them go away by switching "modes".

First, even in T32 mode, there are only two instruction lengths, 2 and 4 bytes. Requires much less transistors than modern Intel and AMD CPUs which supports single cycle decoding of instruction lengths from 1 to 15 bytes.

Second, due to prefix bytes, the bits which control the x64 instruction length a spread all throughout the instruction, and they interact with each other. There are instructions where every single byte modifies the length. Decoding variable length T32 is easy, there are only a few bits in the first byte that select between 16 and 32bit.

Third, T32 support is technically optional. Apple has required all apps to be recompiled in A64 mode for years, I'm not even sure if their latest CPUs still support switching to T32 mode.

Forth, mode switching does use less transistors than a design that has to chose on a per-instruction basis. It takes a lot of extra transistors to dynamically detect the instruction type, which have to be replicated 4 or 8 times are unnecessary. All you need is a single bit register to store the current state and a special instruction to switch between modes.

I recall at least the (now discontinued) Qualcomm Centriq (Falkor) did away with 32-bit ARM (ARMv7, thumb*, etc.) and only supported the 64-bit ARMv8. If the market you're targeting doesn't value backwards compatibility, why bother?

Wouldn't surprise me if there are other A64-only chips as well.

Indeed. Both falkor and thunderX2 are A64-only. The backwards compatible A32 mode is optional only and not implemented by the ARM server vendors except Ampere eMag.

Yes, and I wouldn't be surprised some year down the road, or even next iPhone A13 would be AArch64 only.

iOS 11 removed support for 32bit applications. Because the iPhone X requires iOS 11 I’m not aware of any way to run 32bit code on A11 processors and above. A32 support is likely already gone at the hardware level.

Thanks. Anyone know whether the recently announced ARM 'Ares' core supports anything but A64?

> That's... not the way hardware works.

Regarding transistor / area budget, sure.

Regarding power budget, that absolutely could be the way hardware works. Modern chips can and do power off pieces of silicon when they are not needed. Whether that would be worth it for instruction decoding, I don't know, but it could be.

Powering off pieces of silicon when they are not needed is done through "clock gating", where you stop feeding a clock to a block that is not needed.

That is only possible when you deal with isolated parts. You cannot, for example, power down an instruction decoders ability to understand different syntaxes, but only power down the entire instruction decoder. Trying to design it so that sub-features of a block like that can be powered down would not be productive.

A realistic clock-gating would be something like powering down the actual execution units ("We don't need AVX-512, so lets not waste power on the execution units"), but that doesn't help in saving power wasted on legacy.

You can absolutely design the instruction decoder into two parallel decoders that decode AArch32 and AArch64 respectively. Splitting Thumb from the rest of AArch32 probably doesn't make sense, and on x86 it probably doesn't make sense to break out 32 and 64 bit, but I can absolutely see the case for AArch32 vs AArch64.

> You can absolutely design the instruction decoder into two parallel decoders that decode AArch32 and AArch64 respectively.

You can design anything. The question is whether the added design complexity (which for silicon directly translates to increased power consumption) outweighs the benefits.

Thus

>> Whether that would be worth it for instruction decoding, I don't know

There would be significant overhead to design a decoder such that it could switch between legacy and aarch64 only, but it could conceivably be done.

fyi clock gating isn't the same as power gating.

> There would be significant overhead to design a decoder such that it could switch between legacy and aarch64 only, but it could conceivably be done.

What you'd do then is to split the decoder into several blocks, so that there's a fan-out from a main decoder into the different sub-decoders, and then power down the sub-decoders. It's still entire blocks you power down.

Plus, I think the increased power consumption from this design (especially considering that the decoder now needs to stall on powered down sub-decoders) will outweigh the savings of powering down any sub-decoders.

> fyi clock gating isn't the same as power gating.

Of course not. Both clock gating and power gating are power saving designs. Clock gating and power gating both eliminate switching current entirely, while power gating also removes leakage current at the cost of larger architectural changes than those required by clock gating.

I'm out on a limb here, but I don't think power gating makes much sense outside extreme low-power devices.

I'm not a CPU guy, so forgive me for asking what is probably a really dumb or unclear question, but given that Apple controls the whole stack, couldn't they just remove the non-64 bit micro-code to save space?

It seems like if it's doable, that Apple would do it - especially since they killed off 32-bit apps in iOS 11 already, and therefore were able to remove the 32-bit code from the iOS codebase too.

"Microcode" is the wrong word, it will be physical hardware on the chip, but yes - the sibling comment by jabl claims that some of the A64 chips had no 32-bit mode.

>jabl claims that some of the A64 chips had no 32-bit mode.

Fair Enough. [1] States it is AArch 64 only. I spent some time trying to find the official answer to AArch32 being optional, unfortunately nothing concrete has come up.

[1] https://www.qualcomm.com/news/onq/2017/10/05/qualcomm-centri...

The reference you're looking for is likely to be the ARMv8-A Architecture Reference Manual. For example, it mentions in multiple places "if AARCH32 is not implemented".