4 ms·

> Apple was able to just create a new CPU based on the much more modern ARM architecture Is that accurate? x86 launched in 1978. (64bit in 2003). ARM launche

> Apple was able to just create a new CPU based on the much more modern ARM architecture Is that accurate? x86 launched in 1978. (64bit in 2003). ARM launched in 1985. (64bit in 2011). https://en.m.wikipedia.org/wiki/X86 https://en.m.wikipedia.org/wiki/X86 https://en.m.wikipedia.org/wiki/ARM_architecture_family https://en.m.wikipedia.org/wiki/ARM_architecture_family

dmitrygr 4y ago
X86-64 INCLUDES all the legacy cruft of x86-32 and x86-16 and is thus 44 years old. Aarch64 in Apple chips doesn’t include A32 and is thus 11 years old. It is indeed a large age difference.
- agsnu 4y ago
  Apple was also the first vendor to ship an ARMv8-A compatible chip; I'm sure there have been reports that they heavily influenced the design of AArch64 but I can't dig them out right now.
  - NobodyNada 4y ago
    To back this up, here’s a Twitter thread from an Apple engineer: https://twitter.com/stuntpants/status/1346470705446092811 https://twitter.com/stuntpants/status/1346470705446092811 > arm64 is the Apple ISA, it was designed to enable Apple’s microarchitecture plans. There’s a reason Apple’s first 64 bit core (Cyclone) was years ahead of everyone else, and it isn’t just caches. > Arm64 didn’t appear out of nowhere, Apple contracted ARM to design a new ISA for its purposes. When Apple began selling iPhones containing arm64 chips, ARM hadn’t even finished their own core design to license to others. > ARM designed a standard that serves its clients and gets feedback from them on ISA evolution. In 2010 few cared about a 64-bit ARM core. Samsung & Qualcomm, the biggest mobile vendors, were certainly caught unaware by it when Apple shipped in 2013. > Apple planned to go super-wide with low clocks, highly OoO, highly speculative. They needed an ISA to enable that, which ARM provided. > M1 performance is not so because of the ARM ISA, the ARM ISA is so because of Apple core performance plans a decade ago.
- alberth 4y ago
  But ARMv8-A is backward compatible.
  - dmitrygr 4y ago
    Armv8 aarch32 (32-bit) support is optional and hasn’t existed in Apple CPUs for years… (according to jail breakers and public SDK info). Aarch32 is a separate mode so dropping it is easy. In x86 you cannot drop 32bit because… it is part of the 64-bit mode and needed.
  - hajile 4y ago
    Apple dropped support years ago and the last couple ARM chip designs finally dropped support too. A715 in particular made it's decoder 20+% wider while reducing die area by 75% all due to eliminating 32-bit support.
    - skavi 4y ago
      IIRC, you’re a bit wrong with the numbers. The decoder is now a fourth the size it used to be, and they’re now using 5 (up from 4).
      - hajile 4y ago
        It's more nuanced than that though 75% smaller is a fourth the size (I guess depending on where you're looking from). A710 had a uop cache. A710 had 4 decoders but it was like Intel's decoders where one (I assume one, but less than all of them) decoder could decode anything and the others could decode common instructions, but would block and send complex decodes to the complex one. A715 now has not just 5 decoders, but every one of them can decode anything reducing pipeline complexity and increasing theoretical throughput (depending on how often those complex instructions would be used). A710 did instruction fusion in the uop cache, but A715 now does it in the L1 cache during fetch which increases effective instruction throughput by occasionally turning 2+ instructions into one. Finally, A710 used a uop cache. The decoders would fill the uop cache at a rate of 4 instructions per cycle (less if one of those complex decodes happened). Once the uop cache would fill, it would provide 5 instructions per cycle to the rest of the frontend. If A710 could prefetch and keep the uop cache full and there were always enough loops to reuse some parts while others were refilling, then you could keep the full 5 instruction theoretical output. A715 gets rid of all these exceptions making it more consistent. In truth, the final difference is definitely less than 20% in the real world, but even a 0% increase in throughput while getting rid of 75% of your transistors would still be a massive win.
phoe-krk 4y ago
You should not consider the dates that support for these initial revisions had started, you should consider the dates it had been dropped. For x86, it's "never", unlike for modern ARM (see sibling comment).
- alberth 4y ago
  ARM only officially dropped 32bit support last year. https://m.gsmarena.com/arm_will_drop_32bit_support_in_the_big_cortexa_cores_starting_in_2022-news-45688.php https://m.gsmarena.com/arm_will_drop_32bit_support_in_the_bi...
  - NobodyNada 4y ago
    ...“in big Cortex-A cores.” ARM designs both the architecture specification and some reference designs. 32-bit support has been an optional part of the specification since ARMv8 in 2011. The article you link is saying that ARM’s Cortex-A reference designs will no longer include 32-bit support, which has nothing to do with Apple since Apple uses their own custom designs. Apple dropped 32 bit support in their own designs in (IIRC) 2016.
    - doublepg23 4y ago
      afaik the last remaining 32 bit Apple SoC is in the Apple Watch Series 3.

dmitrygr 4y ago

X86-64 INCLUDES all the legacy cruft of x86-32 and x86-16 and is thus 44 years old. Aarch64 in Apple chips doesn’t include A32 and is thus 11 years old. It is indeed a large age difference.

agsnu 4y ago
Apple was also the first vendor to ship an ARMv8-A compatible chip; I'm sure there have been reports that they heavily influenced the design of AArch64 but I can't dig them out right now.
- NobodyNada 4y ago
  To back this up, here’s a Twitter thread from an Apple engineer: https://twitter.com/stuntpants/status/1346470705446092811 https://twitter.com/stuntpants/status/1346470705446092811 > arm64 is the Apple ISA, it was designed to enable Apple’s microarchitecture plans. There’s a reason Apple’s first 64 bit core (Cyclone) was years ahead of everyone else, and it isn’t just caches. > Arm64 didn’t appear out of nowhere, Apple contracted ARM to design a new ISA for its purposes. When Apple began selling iPhones containing arm64 chips, ARM hadn’t even finished their own core design to license to others. > ARM designed a standard that serves its clients and gets feedback from them on ISA evolution. In 2010 few cared about a 64-bit ARM core. Samsung & Qualcomm, the biggest mobile vendors, were certainly caught unaware by it when Apple shipped in 2013. > Apple planned to go super-wide with low clocks, highly OoO, highly speculative. They needed an ISA to enable that, which ARM provided. > M1 performance is not so because of the ARM ISA, the ARM ISA is so because of Apple core performance plans a decade ago.
alberth 4y ago
But ARMv8-A is backward compatible.
- dmitrygr 4y ago
  Armv8 aarch32 (32-bit) support is optional and hasn’t existed in Apple CPUs for years… (according to jail breakers and public SDK info). Aarch32 is a separate mode so dropping it is easy. In x86 you cannot drop 32bit because… it is part of the 64-bit mode and needed.
- hajile 4y ago
  Apple dropped support years ago and the last couple ARM chip designs finally dropped support too. A715 in particular made it's decoder 20+% wider while reducing die area by 75% all due to eliminating 32-bit support.
  - skavi 4y ago
    IIRC, you’re a bit wrong with the numbers. The decoder is now a fourth the size it used to be, and they’re now using 5 (up from 4).
    - hajile 4y ago
      It's more nuanced than that though 75% smaller is a fourth the size (I guess depending on where you're looking from). A710 had a uop cache. A710 had 4 decoders but it was like Intel's decoders where one (I assume one, but less than all of them) decoder could decode anything and the others could decode common instructions, but would block and send complex decodes to the complex one. A715 now has not just 5 decoders, but every one of them can decode anything reducing pipeline complexity and increasing theoretical throughput (depending on how often those complex instructions would be used). A710 did instruction fusion in the uop cache, but A715 now does it in the L1 cache during fetch which increases effective instruction throughput by occasionally turning 2+ instructions into one. Finally, A710 used a uop cache. The decoders would fill the uop cache at a rate of 4 instructions per cycle (less if one of those complex decodes happened). Once the uop cache would fill, it would provide 5 instructions per cycle to the rest of the frontend. If A710 could prefetch and keep the uop cache full and there were always enough loops to reuse some parts while others were refilling, then you could keep the full 5 instruction theoretical output. A715 gets rid of all these exceptions making it more consistent. In truth, the final difference is definitely less than 20% in the real world, but even a 0% increase in throughput while getting rid of 75% of your transistors would still be a massive win.

phoe-krk 4y ago

You should not consider the dates that support for these initial revisions had started, you should consider the dates it had been dropped. For x86, it's "never", unlike for modern ARM (see sibling comment).

alberth 4y ago
ARM only officially dropped 32bit support last year. https://m.gsmarena.com/arm_will_drop_32bit_support_in_the_big_cortexa_cores_starting_in_2022-news-45688.php https://m.gsmarena.com/arm_will_drop_32bit_support_in_the_bi...
- NobodyNada 4y ago
  ...“in big Cortex-A cores.” ARM designs both the architecture specification and some reference designs. 32-bit support has been an optional part of the specification since ARMv8 in 2011. The article you link is saying that ARM’s Cortex-A reference designs will no longer include 32-bit support, which has nothing to do with Apple since Apple uses their own custom designs. Apple dropped 32 bit support in their own designs in (IIRC) 2016.
  - doublepg23 4y ago
    afaik the last remaining 32 bit Apple SoC is in the Apple Watch Series 3.