HelloSilicon – An introduction to assembly on Apple Silicon Macs
github.com
github.com
It's a little odd seeing it treated as its own unique architecture (for instance with people specifically porting software or writing guides about Apple Silicon rather than ARM in general) when it's just ARM64. Which already has a lot of stuff already ported to it and is quite extensively documented.
Am I missing something? Did Apple do something crazy non-standard when making their chips which make them behave differently?
https://developer.apple.com/documentation/xcode/writing-arm6...
It explains how Apple constrains users, and thus the difference between general ARM and Apple Silicon. Which was the question.
> I was thinking I would find ARM architecture differences in the silicon.
Could you explain what you mean exactly? It's an ARM implementation so it has to implement the ISA.
Apple's implementation has a few interesting bits, like a TSO mode (for x86 emulation), and actually has custom ISA extensions (AMX, memory compression, APRR/GXF) which nobody else would be allowed according to Hector Martin.
I'm not sure of the meaning here. Is it:
a. ISA extensions can't be called by any program not written by Apple? (including Asahi)
b. Nobody else but Apple has the right to have these ISA extensions, but when in Silicon, programmers can use them?
c. Nobody else who licenses ARM would be allowed to add extensions to their implementation of the ISA in this way. Apple is more or less a founding member of ARM and has some other deal.
> Nobody else but Apple has the right to have these ISA extensions
Programmers "can" use Apple extensions because... they're extensions to the ISA, they're not documented but they can't really be blocked off unless they're ring0, and that would make them a lot less useful (the entire point of having extensions for matrix computation is to speed up matrix computations, which are not usually kernel work, and having to syscall to do them would waste the entire thing).
I know about Apple Silicon's total store ordering mode and other matrix extensions.
When the poster wrote "Apple diverges from standard 64-bit ARM architecture in specific ways" I expected the link to have more information on the Apple Silicon, but found it was just ABI information.
See for yourself -
https://developer.apple.com/documentation/xcode/writing-arm6...
OK?
> When the poster wrote "Apple diverges from standard 64-bit ARM architecture in specific ways" I expected the link to have more information on the Apple Silicon, but found it was just ABI information.
Yees?
That's really no clearer.
The poster wrote that Apple diverges from "standard 64-bit ARM in specific ways", and extensions aside the ABI restrictions is those specific ways: they mean that you can't take random ARM64 assembly or machine code and run it on Apple Silicon without validation that the additional restrictions are respected.
Again, what did you mean exactly? Did you expect Apple Silicon to not implement ARM despite being an implementation of the ARM ISA?
I know about Apple Silicon's total store ordering mode and other matrix extensions.
When the poster wrote "Apple diverges from standard 64-bit ARM architecture in specific ways" I expected the link to have more information on the Apple Silicon, but found it was just ABI information.
See for yourself -
https://developer.apple.com/documentation/xcode/writing-arm6...
It might also be worth reiterating that this book is, itself, a port from the original, more generic ARM version.
Getting into that separate discussion, I think there's really only one good use case for -fomit-frame-pointer and that's on 32-bit x86, which has only 8 general purpose registers (EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI); one of which is the stack pointer (ESP), the other of which is the frame pointer (EBP). Meaning that by default a quarter of the available registers are unavailable to you[1]. With -fomit-frame-pointer, you go from having 6 to 7 free registers. This can have a decent impact on performance; there's a reason you'll see it in old gentoo CFLAGS discussions.
x86_64 added R8-R15 registers (as well as RIP-relative addressing), and implementations do a hell of lot of renaming internally, meaning that the gain from using -fomit-frame-pointer is minimal these days.
[1]: This is in fact even worse when using position independent code, as EBX is used quite often as a hidden GOT argument, leaving you with only 5 useful registers.
And I suppose that's entirely typical, nothing says Apple as much as as making something as custom and incompatible as possible for literally no reason except ecosystem locking.
Reasonable people could decide they don’t want to buy Apple products, but then you’re done: you didn’t buy one! :)
The situation would have been _far_, _far_ worse otherwise.
A lot of hardware didn't get new drivers either, and macOS went and changed that around a few versions back. These are professional products, with many thousands of dollars invested into them, so the upgrade cost is often impossibly high. Hell, I forget the name of the movie, but it was cut on a version of Final Cut Pro (not X) that was five years old when the movie was cut. That editor held onto that their ancient un-upgradeable machine for dear life because that was the workflow they lived and breathed.
This has two customers today:
- on x86 Macs only: older iOS Simulators
- on x86 and arm64 Macs: x86_32 code segments (no syscall emu), for Wine to be able to run 32-bit x86 applications.
I think that the fragile base class problem might be what made Apple get rid of 32-bit x86 app compatibility at the end.
> A lot of hardware didn't get new drivers either, and macOS went and changed that around too
Yeah. KM drivers aren't exactly the most stable thing from release to release ever on macOS. And Apple has been steadily getting rid of those.
The player that actually cares the most about backwards compatibility on the desktop to an insane extent is Microsoft. 32-bit Windows editions (that are able to run 16-bit apps) are only gone in Windows 11. Apple still spends a lot of effort on it but not to the same extent at all.
Binary compatibility matters less on Linux, true; what people are actually interested in on the desktop is usually UI compatibility, as in keeping the same look and feel and workflow. That's something Linux is a lot better at than either MacOS or MS Windows, both of which force you into new UIs with the shift of fashions and corporate buzzwords.
I've used Linux and explicitly chosen open source software since 2004. There's not a single program I'd like to run that does not work today. I've never been bitten by any such compatibility issue.
Binary compatibility is crap though. You are likely to have issues if you try to use a package you found outside of your distribution's repositories for the specific release you use. I guess AppImage and things like this will improve this sad state of affair.
For products I work on, we’ve done OpenGL to Metal, 32-bit to 64-bit, Intel to Apple Silicon. Sure it would be great to never have to change existing code, but it can be done. And most of the audio plug-ins I use are from pretty small vendors who seem to have made the same switches (admittedly, not much OpenGL/Metal use in audio plug-ins).
Apple doesn’t guarantee syscall compatibility between minor versions, either. You must dynamically link libsystem instead.
While 100/hr is reasonable for many devs in Silicon Valley, it is fairly high for others.
Apple Silicon?
This is ARM ISA and architecture, also known as aarch64.
You may not like that Apple has created their own brand around their implementation of aarch64, but that's hardly reason to pretend that there is not a meaningful distinction to be made.
Some techies are already confused about the nature of the ISA and architecture.
Pretty soon, people will forget that iOS and macOS are running on ARM, like many many other devices.
For once they have the ability to adopt a standard and even push it forward with the incredible engineering of their hardware teams, but they seems to choose, again, the other route.
The ABI compatibility is never expected nor is taken for granted, for it is an internal implementation aspect of an operating system. An ISA does not equate to an ABI either. Blaming Apple for devising or augmenting an aarch64 ABI is akin to blaming IBM for using the XCOFF and the AIX ABI on their POWER platforms rather than using the SysV ELF ABI on the same POWER platform that Linux is a signatory to.
Incompatible ABI's used to be a common place across different UNIX flavours from different vendor running on the same ISA. DEC Ultrix running on MIPS used an ABI distinct from that of SGI Irix running on the same MIPS ISA. For many years the ABI was not even recognised as a thing and was rather very loosely based on the original PDP-11 ABI (e.g. the result is either in the zeroeth register of the CPU however it was actully named, or on the stack if the result was too big to fit in, input parameters either in the first 4-5 registers or on the stack etc).
It took years of bickering amongst UNIX vendors until the SysV ELF ABI was finaliased and adopted across all modern UNIX implementations (sans Mach-O on Darwin and XCOFF on AIX). Linux went all in with the ELF ABI as it was well positioned to get away from a zoo of legacy ABI's it historically had to support on different hardware plaftorms (a.out, COFF, ECOFF and whatever else there was out there) even at the cost of the performance loss on the 32-bit x86. Whereas all BSD's (Free, Net and Open) just baulked at it and stuck with the historical BSD ABI for several more years to renege later on.