shac ron ₪Ten years ago today #Apple launched the #iPhone 5S and announced the #arm64 CPU inside. It was the first public disclosure of a 64-bit ARM architecture, and it was available for you to buy in a phone. Nobody else was even close to having a chip ready to tape out, much less put in a product, and it was a performance monster.
For many of us it was the culmination of years of effort creating this chip and porting all of our software to it. I was working on the kernel and EL3 monitor. When we started we had no compiler, no assembler, no debugger, and really no documentation and the ISA still in flux. Someone wrote a macro-based assembler. Code gen bugs were a huge problem as clang was adding support. LLDB never caught up so someone on my team did a port of GDB.
I skipped thanksgiving vacation 2012 because FPGAs were coming in. We were booted to Springboard in about a week, the result of a huge amount of preparation in simulation. The first tapeout booted in one day. I remember talking to an Arm engineer about that time and was not allowed to say where we were, but gathered their core was still purely software simulation.
When iOS shipped, it was a full 64-bit native release. There was no 32-bit code in the OS image* (including complicated things like the Safari JavaScript engine). Everything was ported day one.
*except the bits required to support 32-bit third party apps
*except the bits required to support 32-bit third party apps
The reception was very confused. Most of the tech pundits didn’t understand why a phone needed a 64-bit processor. They mostly focused on the ability to have more than 4 gigs of memory (5S had 1gb). When they got it in their hands they knew. Apples first core, Swift, was released in the previous year and it was a perf leader. This chip was much faster than that, it was an insane leap that put Apple 3-5 years ahead of the rest of the industry.
My favorite quote:
“I know there's a lot of noise because Apple did [64-bit] on their A7," said [Qualcomm senior vice president and chief marketing officer] Anand Chandrasekher. "I think they are doing a marketing gimmick. There's zero benefit a consumer gets from that."
"Predominantly... you need it for memory addressability beyond 4GB. That's it. You don't really need it for performance, and the kinds of applications that 64-bit get used in mostly are large, server-class applications," said Chandrasekher.
“I know there's a lot of noise because Apple did [64-bit] on their A7," said [Qualcomm senior vice president and chief marketing officer] Anand Chandrasekher. "I think they are doing a marketing gimmick. There's zero benefit a consumer gets from that."
"Predominantly... you need it for memory addressability beyond 4GB. That's it. You don't really need it for performance, and the kinds of applications that 64-bit get used in mostly are large, server-class applications," said Chandrasekher.
Dougall@shac Yeah, I remember that I didn't see why you'd double the size of all your pointers at the time. Chrome stuck with 32-bit builds on low memory devices for the longest time, but Safari was faster anyway.
Who designed the ISA? Was it was mainly designed/motivated by Apple?
@dougall The ISA was designed by Arm. It was commissioned by Apple to align with its microarchitecture goals. Other customers were involved in the design process. I have little insight into their contribution, but Apple was clearly doing the driving in the early years.
Double size pointers hurt us a lot. It was about 15% increase in heap usage IIRC. But TBI pointer tagging was a big perf gain for ObjC and JavaScript.
dzhoTBI is "top byte ignore"
obviously not needed for anyone already using the term in this discussion
that's an FYI for the rest of us reading along from an interest in sorting out useful claims from industry hype, but only somewhat conversant with the latest chip architectural features
took me several tries to get a useful search, one that didn't return articles about, uh, neurological illness