Alastair Reid
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.
Greg Parker
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
Brendan Shanks
I Can't Believe It's Not Zero!@shac I continue to be amazed by that statement today.
Steve Bollinger@shac 640K should be enough for anyone.
David Rogers@shac I think from a pedant kind af view, I don’t think he is wrong. But getting hung up on that is a distraction from what made that chip so awesome.
Alex Rosenberg@shac Similar energy to Ballmer saying that iPhone was too expensive and would be a failure because it didn't have a physical keyboard.
Howard Chu @ Symas@shac and yet iOS still restricts all processes to only 4GB, so the full 64bit address space isn't even being used.
Saagar Jha@saagar @shac The Apple docs don't mention any exceptions to the 4GB limit on iOS. Wouldn't make sense either, since iOS has no pager/swapper. This limitation makes it a real pain to use #LMDB on iOS.
@hyc @shac That documentation is fairly old. The limit is already more than that for standard processes: https://github.com/apple-oss-distributions/xnu/blob/aca3beaa3dfbd42498b42c5e5ce20a938e6554e5/osfmk/arm/pmap/pmap.c#L11327. If you get https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_kernel_extended-virtual-addressing it goes up much higher.
@saagar @shac I see, since iOS 14 which was released 3 years ago. (Sept 16 2020. In my mind that was just yesterday, since pandemic etc...) Thanks for the pointer. I take it the restriction on paging still stands?
So, props to Apple for pushing the first ARM64 smartphone out the door, but they were last to release OSs that let smartphone applications leverage the full potential of a 64bit architecture.
Saurabh@shac Great story and accomplishment, thanks for sharing
JohnHedge@shac A0 silicon booting in a day felt so good. IIRC there was like one memory issue in iBoot to get to where it previously had taken a few weeks.
Siguza@shac the toolchain situation must've been madness. Just reversing an A7 ROM, the assembly is so distinct that it's obvious that compiler was barely ready.
Jevin Sweval
raytraced@shac @steve gdb on macos rip. i’m sure there’re great technical advantages to lldb, but i always thought that the spotlighton for lldb should have opened with “forget everything you know about debugging.” the gnu quick reference format is still the north star https://www.cs.utexas.edu/~dahlin/Classes/UGOS/reading/gdb-ref.pdf. it’s the gnu equivalent of “all of our products fit on one table”.
@raytraced @steve LLDB was designed to be used by machines, specifically Xcode, not humans. The human interface was terrible at the start. It has improved a little over the years.
@shac @raytraced @steve For something intended to be used by machines it fails a lot in ways that require humans to recover
systemd-jaded.timer@shac @raytraced @steve last time i found a bug in lldb i cursed the significant lack of logging. i wound up having to stick rr on it and then use pernosco iirc.
lldb is. not my favourite debugger.
Christian Kent 𝘊𝘒 :＼﹥@shac good to have 3nm as the 10th anniversary 😍
amarioguy@shac I still remember that announcement lol, Alcatraz (and the Cyclone family of cores lol) really set a lot of fun things in motion
I still remember how *almost* no one was able to gain introspection into SEP until 2016 or so when more of the mitigations started to get in, it's definitely one of the best parts about that SoC and one that continues to get better lol
Wustin@shac over the years, Apple has proven themselves to be really f'ing good at product transitions
katch wreck@shac ah, calling a pocket computer a "phone", how clever! that way, they can prevent competitors from launching any products by colluding with mobile service providers. a computational cartel! such a great achievement jk
Gnutella@shac Apple is the only company with a vision for its products.
Blake Patterson@shac As I recall, a Samsung high level was fired for publicly scoffing at 64-bits when this was announced.