[HN Gopher] HelloSilicon - An introduction to assembly on Apple ...
___________________________________________________________________
HelloSilicon - An introduction to assembly on Apple Silicon Macs
Author : andsoitis
Score : 199 points
Date : 2022-12-25 17:01 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| snvzz wrote:
| The opposite of accessible. Gated behind an expensive purchase.
| thewebcount wrote:
| This is really neat! My first thought when I read about Perry's
| project was that it would be nice to have a macOS translation of
| the book, so thanks for doing this!
| TheBrokenRail wrote:
| 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 wrote:
| The differences are listed in the linked page.
| jws wrote:
| The Apple ABI has requirements not present in the generic
| ARM.
|
| https://developer.apple.com/documentation/xcode/writing-
| arm6...
| saagarjha wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| lmao
| stephencanon wrote:
| 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.
| messe wrote:
| > 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.
| andsoitis wrote:
| Apple diverges from standard 64-bit ARM architecture in
| specific ways:
| https://developer.apple.com/documentation/xcode/writing-arm6...
| sounds wrote:
| 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 wrote:
| > 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.
| pjmlp wrote:
| Not all ARM chips are made alike, Apple Silicon is yet another
| variation.
| fragmede wrote:
| The book assumes running Darwin/OS X, which has consequences
| specific to that, eg
| 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.
| moonchild wrote:
| This tutorial seems to perform syscalls directly. That is
| inadvisable on macos, as the kernel interface is unstable. You
| should call through libc instead.
| pmalynin wrote:
| libsystem is what you want to use, not libc per se
| moonchild wrote:
| Depends on priorities. Libc is likely to be better documented
| and work across oses with less or no hassle.
| pourred wrote:
| AFAIK there's no "libc" on macOS. libSystem is "libc".
| stephencanon wrote:
| libc (under the name libsystem_c.dylib) is one of several
| components that make up libSystem. But none of these
| dylibs (including libSystem itself) actually exist in the
| installed image as dylibs: they're part of the dyld
| shared cache.
| andai wrote:
| Unstable per major macOS version? Don't those break a
| substantial fraction of working software anyway?
| Gigachad wrote:
| They usually give a very long notice when things are going so
| it would only be abandonware that breaks.
| my123 wrote:
| macOS has a lot of work spent on it to ensure backwards
| compatibility between releases for software.
|
| The situation would have been _far_, _far_ worse otherwise.
| duped wrote:
| Nowhere to the degree as Windows or Linux. MacOS updates
| are very fragile and almost guaranteed to break software.
| my123 wrote:
| Linux on the desktop has far less backwards compatibility
| than macOS I'd argue. Yes the kernel <-> user space ABI
| is stable, but anything above that tends to be very messy
| on Linux.
| msla wrote:
| Not in my experience. I've been using the same window
| manager and the same applications since before my current
| distro existed.
| pjmlp wrote:
| I bet compiled from source, while what is being discussed
| here is binary compatibility.
| msla wrote:
| No, I use the distro packages, and have for quite a while
| now.
|
| 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.
| pjmlp wrote:
| It is still not what is being discussed here, as binary
| compatibility across OS versions.
| fragmede wrote:
| It depends on what you use on their respective OSes. If
| you use your MacBook as an expensive Chrome/Slack/Netflix
| machine, I'd agree it's straight forwards to upgrade
| macOS. However there is a large range of very expensive
| professional apps that are pretty much guaranteed not to
| work on major version updates before the vendor also
| releases an upgrade, if they ever do. Avid for example.
| Or Ableton. There's a _huge_ library of 32-bit x86 VST
| plugins that are now locked away from newer macOS
| versions due to it dropping 32-bit support.
|
| 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.
| lokar wrote:
| I'm not sure it's fair to cite breaks due to hardware
| arch changes as evidence that the OS is bad at backwards
| compatibility. If anything apple has been better then
| average for compatibility across hw platforms, offering
| translation
| fragmede wrote:
| The breaks I mentioned are just whilst on Intel though.
| The change to Apple Silicon assuredly broke an ton of
| stuff but I'm not even counting those.
| my123 wrote:
| For 32-bit, interestingly Apple still maintains a very
| bare minimum (_not_ covering Mac GUI apps).
|
| 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.
| kitsunesoba wrote:
| Windows is better than average but still has considerable
| holes in backwards compatibility that are particularly
| visible in games (and ironically, some of the worst are
| Microsoft's own games under the "Games for Windows"
| banner e.g. Fable 3), but I've seen a number of other
| random things break or stop working totally as expected
| when new versions of Windows come out.
| NelsonMinar wrote:
| The book this is based on is quite good. Stephen Smith's
| "Programming with 64-Bit ARM Assembly Language".
| https://www.goodreads.com/en/book/show/53671067
___________________________________________________________________
(page generated 2022-12-25 23:00 UTC)