For context: Apple provides Rosetta for Linux to allow native x86 binaries to run inside Linux guests on Apple silicon hosts as discussed yesterday [0]. This article explores what other uses can be had for Rosetta on Linux.
Thanks to the ARM version of the Microsoft Surface, there's an ARM port of Windows 10 via Insider Preview Builds. What this means though, is that I can run x86 Windows binaries on my M1 Mac though Parallels Desktop (haven't tried other VM programs such as virtualbox).
Unsurprisingly CPUz has a bit of trouble running and is unable to give much information, saying the CPU name is Apple Silicon, the spec is ARMv8, and the clock speed of 3.0 Ghz, but most everything is blank.
> For context: Apple provides Rosetta for Linux to allow native x86 binaries to run inside Linux guests on Apple silicon hosts .... Thanks to the ARM version of the Microsoft Surface, there's an ARM port of Windows 10 via Insider Preview Builds. What this means though, is that I can run x86 Windows binaries on my M1 Mac though Parallels Desktop (haven't tried other VM programs such as virtualbox).
What a time to be alive! Imagine reading this in 2015 :D
I ended up having to buy a cheap Windows laptop anyway because while I could get the x86 app on this page to run under ARM Windows, I wasn't clever enough to get the Silabs driver to work:
What really boggles my mind about Rosetta is that it correctly handles x86_64 instructions produced at run-time. So, for example, the Clozure Common Lisp compiler for the x86 works under Rosetta. Even the IDE works, which really blows my mind.
There is one thing that doesn't work, and that is code that relies on floating point exceptions, which Rosetta does not correctly emulate. It's a curious oversight for a system that is otherwise beyond impressive.
I'm really giddy to see this being made use of by Docker / podman as the currently used QEMU based solution is slow as molasses.
In our case, the moment the M1 Macs came out, I have re-built our development images on ARM, but there are a few dependencies to proprietary software which is only provided for x64 and which I can't really support on ARM Macs ATM because running affected services through QEMU is no fun, especially as those are mostly about handling bulk data living in proprietary databases.
But if this comes close to what Rosetta can do on macOS, using it for those cases becomes feasible.
Is there a good article explaining what is shared between ARM processors (ie. M1 / Graviton), what makes them "compatible" ? and how they can add specific features still keeping them compatible ?
ARM defines the Instruction Set Architecture for ARM-compatible CPUs.
It has major versions, like Armv8-A and Armv9-A.
The major versions have minor subversions, like Armv8.2-A and Armv8.5-A.
The versions and subversions have mandatory features, which must be implemented by everybody who claims to make an ARM CPU, and optional features.
Like on x86, where there is the CPUID instruction, on an ARM CPU it is possible to determine what version and subversion of the ISA is implemented, and which optional features are implemented, by reading some special registers.
It is possible to make a program that on newer CPUs will take advantage of some features, but on older CPUs it will have a fall-back code path of lower performance.
Because Apple writes software only for their CPUs, they do not bother to write programs that will also run on CPUs made by others, which may lack some of the features implemented on Apple CPUs.
As mentioned in the parent article, Rosetta needs FEAT_FlagM, which is implemented only on ISA versions of Armv8.4-A or newer.
All the ARM cores licensed from the ARM company with the exception of those introduced in 2021 (and also NVIDIA Carmel and the last cores designed by Samsung before giving up), support only Armv8.2-A, and those older than Cortex-A55 (e.g. Cortex-A73, Cortex-A72, NVIDIA Denver) support only Armv8.0-A.
This leaves very few non-Apple CPUs which can execute Rosetta, i.e. only the latest smartphones of 2022 with Armv9.0-A CPUs (Cortex-X2, Cortex-A710, Cortex-A510) and the Graviton 3 servers with Armv8.4-A CPUs (Neoverse V1).
Besides the ISA level compatibility, there is also the problem with the standard peripherals, e.g. timers, which also may differ between ARM CPU implementations.
As explained in the parent article, Rosetta is not written to work with any timer frequency, but accepts only a few values, so it had to be tricked to work on Graviton 3.
Because on any ARM system it is possible to determine the frequency of the timers, it would have been possible to write Rosetta to work with any frequency, but again, there was no reason for Apple to make it more flexible, when they want it to run only on their hardware.
Sort of? You'd also need a way of guaranteeing total store order semantics for memory otherwise you may get random errors. I guess restricting the app to a single core might reduce that error frequency a bit
> I guess restricting the app to a single core might reduce that error frequency a bit
Shouldn't it eliminate it entirely? I'm pretty sure ARM guarantees sequential consistency on a single core, so if the app is limited to a single CPU (e.g. using taskset), there should be no issue.
The real problem is, performance will be degraded.
I'm skeptical, but optimistic. qemu user emulation with TCG is also a JIT compiler, is pretty decent, and doesn't have the "needs to be limited to a single core" when ran outside macos hardware, though it certainly has a lot of room for optimizations. I'm waiting for some benchmarks comparing the two.
You can already do x86 emulation on linux ARM devices via other means[0] including on the Raspberry Pi. Keep in mind performance will be greatly degraded, but its possible.
You’re probably thinking of having a Total Store Ordering mode that can be switched on and off on demand. Most ARM CPUs don’t have this feature since it isn’t necessary, but it’s the normal way that x86 CPUs work. Without doing it in hardware An x86 emulator/translator needs to use a ton of memory fence instructions to emulate TSO.
>To me this all sounds like Apple is ready to license their CPU
Not at all. Apple only makes HW for the Apple ecosystem an that's it. Just look at everything they sell from monitors to earphones. Their functionality is crippled when not used with Apple HW because they're dependent on the Apple ecosystem to run at their full feature set.
What makes you think they would suddenly reverse that? They're just not in the business of building and supporting non-Apple ecosystems.
Except when there's additional money to be made. Apple Music is available on Android because that makes Apple money. But iMessage isn't because that would prevent some tiny bit of iPhone sales.
I suspect Apple Music is on Android for the benefit of Apple Music users who have multiple devices, some Apple some not, and want a music service that works across all of them.
I use a Mac but an Android phone. I'd really like if things like AirDrop or FaceTime or other macOS/iOS integrations worked with Android the way they do with iPhones. I had to reverse engineer Google's Nearby Share protocol and build a (barebones and buggy and incomplete) file receiver for macOS to put an end to my misery of transferring things, primarily pictures, from my phone to my computer. But obviously Apple isn't interested in any of this; they'd rather tell me to just use an iPhone, since that would get me more hooked into their proprietary ecosystem.
I guess it's a matter of weighing the potential upside of selling you on more Apple products versus the downside of making Macs and iPhones less functional (w.r.t. interoperability with other devices).
It absolutely would not surprise me if Apple were running a custom Linux distribution on a range of not publicly available ARM server platforms as part of their development chain. I suspect this is as much for their own benefit as it is for everyone else.
Somewhere I read that Apple use Linux (there own internal version) as the first target when developing their silicone, before then targeting macOS once development has progressed to a certain point. I can't find the article now though, surprising hard to google for.
I’m sure this is correct. I’ve seen comments on HN multiple times about what they use Linux for in house. You can tell to some extent just from job postings too.
[0]: https://news.ycombinator.com/item?id=31644990