> 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).
Is that accurate?
x86 launched in 1978. (64bit in 2003).
ARM launched in 1985. (64bit in 2011).
> 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.
A715 in particular made it's decoder 20+% wider while reducing die area by 75% all due to eliminating 32-bit support.
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.
https://m.gsmarena.com/arm_will_drop_32bit_support_in_the_bi...
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.