5 ms·

So what's the difference between ARM and Apple Silicon? It's a little odd seeing it treated as its own unique architecture (for instance with people specifical

So what's the difference between ARM and Apple Silicon? 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?

galad87 4y ago
The differences are listed in the linked page.
- jws 4y ago
  The Apple ABI has requirements not present in the generic ARM. https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms https://developer.apple.com/documentation/xcode/writing-arm6...
andsoitis 4y ago
Apple diverges from standard 64-bit ARM architecture in specific ways: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms https://developer.apple.com/documentation/xcode/writing-arm6...
- sounds 4y ago
  I mean, that page only describes ABI differences. I was thinking I would find ARM architecture differences in the silicon. I understand that the ABI is considered part of the specification for 64-bit ARM silicon.
  - masklinn 4y ago
    > I mean, that page only describes ABI differences. 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.
    - throwme_123 4y ago
      > 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?
      - kzrdude 4y ago
        It might be something like this? 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.
        masklinn 4y ago
        Yes, though that's a different formulation of (2) really: > 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).
        saagarjha 4y ago
        Apple exposes these behind APIs that hide these implementation details. Their own compilers never emit them. Nothing can stop you from embedding them into your binary yourself, of course, but this would be annoying to both you and Apple.
    - sounds 4y ago
      I replied to this post: "Apple diverges from standard 64-bit ARM architecture in specific ways" 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-arm64-code-for-apple-platforms https://developer.apple.com/documentation/xcode/writing-arm6...
  - kevin_thibedeau 4y ago
    They have features to simplify x86 emulation like additional ALU flags.
    - sounds 4y ago
      I replied to this post: "Apple diverges from standard 64-bit ARM architecture in specific ways" 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-arm64-code-for-apple-platforms https://developer.apple.com/documentation/xcode/writing-arm6...
fragmede 4y ago
The book assumes running Darwin/OS X, which has consequences specific to that, eg https://github.com/below/HelloSilicon#listing-9-1 https://github.com/below/HelloSilicon#listing-9-1 but one of the biggest changes is the GPU attached to the arm core, resulting in non-native Apple-specific code. It may not affect the ARM CPU core directly, but if someone is running on Apple Silicon you can assume MPS support whereas you cannot do that for ARM64 targets. It might also be worth reiterating that this book is, itself, a port from the original, more generic ARM version.
saagarjha 4y ago
TL;DR it's AAPCS, with a handful of changes that are generally not relevant to most people. The one I would point out is that the frame pointer must always point to something valid; in other words, don't use -fomit-frame-pointer on Apple silicon. (Don't use it elsewhere either, but that's a separate discussion.)
- stephencanon 4y ago
  Technically it has to point to _a_ valid frame, but it doesn’t have to be the active function’s frame. So it’s safe to omit setting up a normal call frame, you just aren’t supposed to use it as a GPR.
  - stephencanon 4y ago
    I.e. don’t do what a former coworker did (on x86) and use both the stack pointer and frame pointer registers as index registers for your FFT implementation.
    - saagarjha 4y ago
      lmao
      - stephencanon 4y ago
        When you only have a few GPR names, this sort of thing starts to look tempting. IIRC it was about a 10% perf win, but we didn’t ship it. (We did ship one that used the frame pointer as an index, though.)
- messe 4y ago
  > in other words, don't use -fomit-frame-pointer on Apple silicon. (Don't use it elsewhere either, but that's a separate discussion.) 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.
pjmlp 4y ago
Not all ARM chips are made alike, Apple Silicon is yet another variation.
- moffkalast 4y ago
  Sure, but the bottom line is can you compile something for ARM64 and have it work on it or not? Since people keep bringing it up I assume the answer is no. 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.
  - saagarjha 4y ago
    The answer is yes.
    - moffkalast 4y ago
      Then why the ruckus?
      - dagmx 4y ago
        Because it’s a superset, and there’s specific characteristics to keep in mind that people have linked multiple times above

galad87 4y ago

The differences are listed in the linked page.

jws 4y ago
The Apple ABI has requirements not present in the generic ARM. https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms https://developer.apple.com/documentation/xcode/writing-arm6...

andsoitis 4y ago

Apple diverges from standard 64-bit ARM architecture in specific ways: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms https://developer.apple.com/documentation/xcode/writing-arm6...

sounds 4y ago
I mean, that page only describes ABI differences. I was thinking I would find ARM architecture differences in the silicon. I understand that the ABI is considered part of the specification for 64-bit ARM silicon.
- masklinn 4y ago
  > I mean, that page only describes ABI differences. 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.
  - throwme_123 4y ago
    > 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?
    - kzrdude 4y ago
      It might be something like this? 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.
      - masklinn 4y ago
        Yes, though that's a different formulation of (2) really: > 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).
        saagarjha 4y ago
        Apple exposes these behind APIs that hide these implementation details. Their own compilers never emit them. Nothing can stop you from embedding them into your binary yourself, of course, but this would be annoying to both you and Apple.
  - sounds 4y ago
    I replied to this post: "Apple diverges from standard 64-bit ARM architecture in specific ways" 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-arm64-code-for-apple-platforms https://developer.apple.com/documentation/xcode/writing-arm6...
- kevin_thibedeau 4y ago
  They have features to simplify x86 emulation like additional ALU flags.
  - sounds 4y ago
    I replied to this post: "Apple diverges from standard 64-bit ARM architecture in specific ways" 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-arm64-code-for-apple-platforms https://developer.apple.com/documentation/xcode/writing-arm6...

fragmede 4y ago

The book assumes running Darwin/OS X, which has consequences specific to that, eg https://github.com/below/HelloSilicon#listing-9-1 https://github.com/below/HelloSilicon#listing-9-1 but one of the biggest changes is the GPU attached to the arm core, resulting in non-native Apple-specific code. It may not affect the ARM CPU core directly, but if someone is running on Apple Silicon you can assume MPS support whereas you cannot do that for ARM64 targets. It might also be worth reiterating that this book is, itself, a port from the original, more generic ARM version.

saagarjha 4y ago

TL;DR it's AAPCS, with a handful of changes that are generally not relevant to most people. The one I would point out is that the frame pointer must always point to something valid; in other words, don't use -fomit-frame-pointer on Apple silicon. (Don't use it elsewhere either, but that's a separate discussion.)

stephencanon 4y ago
Technically it has to point to _a_ valid frame, but it doesn’t have to be the active function’s frame. So it’s safe to omit setting up a normal call frame, you just aren’t supposed to use it as a GPR.
- stephencanon 4y ago
  I.e. don’t do what a former coworker did (on x86) and use both the stack pointer and frame pointer registers as index registers for your FFT implementation.
  - saagarjha 4y ago
    lmao
    - stephencanon 4y ago
      When you only have a few GPR names, this sort of thing starts to look tempting. IIRC it was about a 10% perf win, but we didn’t ship it. (We did ship one that used the frame pointer as an index, though.)
messe 4y ago
> in other words, don't use -fomit-frame-pointer on Apple silicon. (Don't use it elsewhere either, but that's a separate discussion.) 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.

pjmlp 4y ago

Not all ARM chips are made alike, Apple Silicon is yet another variation.

moffkalast 4y ago
Sure, but the bottom line is can you compile something for ARM64 and have it work on it or not? Since people keep bringing it up I assume the answer is no. 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.
- saagarjha 4y ago
  The answer is yes.
  - moffkalast 4y ago
    Then why the ruckus?
    - dagmx 4y ago
      Because it’s a superset, and there’s specific characteristics to keep in mind that people have linked multiple times above