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?
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.
https://developer.apple.com/documentation/xcode/writing-arm6...
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.