An Introduction to ARM64 Assembly on Apple Silicon Macs
github.com
github.com
(the original comment does not mention but, to be specific, this is about this document: https://developer.apple.com/download/apple-silicon-cpu-optim...)
Should you want to play with SIMD but are a little intimidated - Swift and C# and offer convenient "platform-agnostic" SIMD abstractions, and C# also has NEON/AdvSimd intrinsics in the form of "plain" API calls e.g. `AdvSimd.AddPairwiseWidening` for more direct control (I'm biased on this subject as, while I like Swift, using Xcode and surrounding tooling is sad and less convenient, and the support for Linux/Windows is not there yet).
The original post's point was that by being more open they would encourage more software to be built for their platform. That would create more demand for their products from consumers.
These peripherals are accessed with memory-mapped IO using the same instructions any other program uses.
Documentation about ARM64 assembly shouldn't and doesn't contain specific peripheral access info. ISA docs contain info common to all CPUs implementing the spec.
AMD: https://gpuopen.com/amd-gpu-architecture-programming-documen...
Intel: https://www.intel.com/content/www/us/en/docs/graphics-for-li...
This is the same mechanism by which Microsoft has eliminated the competition for Microsoft Office, which used undocumented Windows APIs so that the products of any other vendor could not keep up with it, especially after the launch of any new Windows version.
Now one can find some more complete documentation for the Apple CPUs as the result of reverse engineering work done by various people, but after each introduction of a new Apple CPU model the reverse engineering work may need to be done again.
Examples:
I'm not here to defend other anti-competitive practices by Apple but as far as just their CPUs go, there are none in that area.
They clearly are helping. Perhaps you've not noticed?
In contrast, AMD and Intel publish GPU documentation.
% gcc --version
Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: arm64-apple-darwin23.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/binhttps://learn.microsoft.com/en-us/cpp/build/arm64-windows-ab...
You learn arm64, then you can worry about if you need to deal with implementation specific ISA quirks.
In fact the only reasons I’m on a Mac rather than Linux are because 1) they make the best consumer laptops by far and 2) I’m stuck in the ecosystem.
Very debatable. That's just your opinion.
And for some, things that Apple do are a no go. Like glued parts, limited Linux support, no OLED screens, no post buy upgradability, overpriced RAM upgrades, limited and finicky multimonitor support for most models.
So clearly it is debatable and depends on who you ask.
I’ve never had an issue, and I regularly plug in one or two at a time. Even two that lie and say they are the same monitor with same serial and it still just works. Although, only after m1 and beyond.
I threw them all together in my mind and didn't check the display capabilities of the max MB.
The company was Apple.
Their hardware has got a whole lot better in the past 12 years.
My guess is that they learned important quality lessons from that class action lawsuit too.
Because the reason Apple really dislikes nvidia was because nvidia sort of lied about the thermal spec (much like intel does, except intel could downclock); and it caused a lot of GPUs to kill their motherboards: https://blog.greggant.com/posts/2021/10/13/apple-vs-nvidia-w...
I will concede that some aspects of the laptop are pretty bad. For instance, the keyboard is subpar compared to even the cheapest mechanical keyboards. The trackpad seems overrated. On desktops, I always use an ergonomic trackball mouse, so trackpads and even "regular" mice put my hand in relatively awkward position and I can't keep it stationary. Something that isn't mentioned often is that the mini-LED displays have considerable bloom, especially compared to the previous generation of MacBooks that used IPS displays.
Personally speaking, the pros of this machine vastly outweight the cons I've just listed.
As good a trackpad, As good a battery, As good speakers.
Just to mention a few. Lots of other stupidities like their RAM pricing, OS magick etc, but other companies have rarely come close to the hardware.
> Very debatable. That's just your opinion.
Sorry, no, I'm not handholding PC manufacturers anymore. When Macbooks were Intel based there were trade-offs, you were buying a laptop that would overheat and underpeform for the spec. The keyboards were iffy to the point where they removed essential keys etc;.
Now, there isn't a better laptop that's an all-rounder for 95% of people. They are fast, cool, do not compromise on display quality or audio quality, afaik they're the only laptop manufacturer giving you full 40GB/s out of each and every USB4 port and they optically seal them (and always have) making USB-Killers ineffective.
They are stupid expensive for upgrades, this is true, however the comparable systems (XPS/Precision, Elitebook, Thinkpad X) are all within spitting distance of the price and still have significant compromises.
PC manufacturers need to do better.
https://github.com/apple-oss-distributions/distribution-macO...
This makes zero sense, frankly. Do you also feel this way about an x86 laptop, that x86 isn't worth learning anything about? Because it might run macOS? It's pointless. The main thing tied to the OS is the userspace ABI (e.g. callee/caller saved registers, parameter passing), but this is generally only one important-but-small part of actually using the CPU, or doing low-level optimization, and every major operating system (including macOS!) tends to have quite detailed ABI documentation for all the supported architectures. Actual fundamentals of the ISA, the supported instructions, etc all translate between operating systems cleanly, and for a given microarchitecture the performance characteristics will also broadly translate between operating systems. But I sort of doubt you're talking about low-level Apple Silicon-specific uarch optimizations, because that's not what the original guide is talking about.
Like, if you don't already know how to write ARMv8 assembly, macOS is not what's stopping you. You can take most of this knowledge, which is fundamentally generic, and just as easily apply it to an RPi for example, or the new Snapdragon X Elite, etc. macOS is mostly a non-issue in this regard, it just happens to be the operating system "of choice" for some of the best client-oriented ARM processors you can buy right now.
At least with Apple, its going to stick. They have marketing mind control that will keep people around rain or shine.
>several class leading products
See.
I mean, 'class leading', like Nintendo leads, pick something no one cares about and peer pressure people into caring.