Why does Linux run so well on ARM

I don't believe it.

You mean to tell me that Microsoft is doing a bad job with thier OS???

Preposterous. These 100 or so processes that its running to track my every breath are incredibly important to make sure im given the best ad experience.

Stephen's dad, is that you?

It’s mainly due to PA Semi acquisition. These guys were the ones responsible of making excellent PowerPC processors, which were similar to what ARM has now.

These guys are probably happier now that they have more resources, target devices and tightly coupled software.

NeXT computers were based on Motorola 680x0 processors that were actually CISC ( not RISC ). Steve Jobs did run MacOS on RISC in the 90s though as that is what PowerPC was.

Modern Apple silicon is of course ARM64 so not the same architecture as PowerPC at all.

Those CGI Spark machines also ran on powerpc

Yeah. Linux is also optimized to run well. Has a capable community and a few good design choices. Many people use it to run it on servers so I wouldn't be surprised if it performed well well on servers.

Also there is a well known fork that is used on millions/billions(?) of ARM phones. So it'd better be a good choice for that use case.

Microsoft absolutely could have made something comparable to Rosetta 2 for userspace if they were competent.

Rosetta 2 isn't an emulator, but a binary recompiler. It takes amd64 instructions, decodes them, and generates equivalent aarch64 instructions. The aarch64 instructions are then executed directly by the processor, performing the same tasks that the original binary would do on an Intel processor.

It's extremely difficult to do properly, but it's nothing inherently special to MacOS or Apple's ARM chips. ARMv8 has an attribute to enable strongly-ordered memory accesses, and it also supports native 4 KiB page sizes. Beyond those two solved concerns, there isn't any actual hardware barrier preventing binary translation. Individual amd64 instructions can be translated into one or more equivalent aarach64 instructions, and complex instructions or those using large registers like those in AVX-512 can be shimmed and implemented in software. An offset table can be used to deal with indirect jumps, and direct jumps can just be rewritten in the generated code. And as Apple has proven, it's even possible to support JIT-compiled code by intercepting jumps into executable pages and recompiling them before executing.

It's expensive in terms of time and engineering skills, but Microsoft had more than enough control over their own proprietary kernel to build something similar into Windows back when they first released it for ARM.

Also yes Windows on ARM is a steaming pile of garbage

Not just on ARM. Windows is and will always be a proprietary steaming pile of shit, no matter what architecture. That will be the case as long as Microsoft develops it.

Windows on ARM is a steaming pile of garbage

Apple hit a sweet spot with this. x86_64 applications run at acceptable speed (making the transition easy for people who buy the hardware) while not being SO good that there's zero reason for developers to start porting their software.

Small correction: the flag setting modes aren't undocumented. They're standardized extensions. ARMv8.4 added FEAT_FlagM, and ARMv8.5 added FEAT_FlagM2.

https://developer.arm.com/downloads/-/exploration-tools/feature-names-for-a-profile

IIRC, the only nonstandard ARM extension used by Rosetta 2 in Apple's processors is TSO, and that's also implemented by other manufacturers. It's also not a hard requirement to run amd64 under ARM. You can emulate it very slowly or restrict the application to a single core.

Apologies for the tangent, but I needed to make sure nobody could defend Microsoft's prior failings by saying "but Apple has secret hardware sauce".

Windows 10 and 11 both have ARM versions. 11's ARM version has had some major updates recently.

Nothing you wrote is correct.

I dunno, overall Rosetta 2 seems to be incredibly successful. It seems like most people were able to transition without worrying too much about whether their software would work at all or not, which I think is undoubtedly the smoothest an architecture transition like this has ever been.

Permanently Deleted

I know the cool thing is to hate on Apple for being Apple, but they have actually done a solid job with their transitions between instruction set architectures.

Ultimately, software developers and end users are forced to use the newer architecture, yes. But credit where credit is due, Apple chose to take the path of providing both hardware and software level facilities to make the transitions as seamless as possible over years-long timespans. They could have simply refused to support older architectures to force a migration down our throats, and indoctrinated fanboys would have opened their wallets anyway.

What they actually did was create compatibility layers, a multi-architecture executable file format, and binary translation frameworks built into the operating system. I fucking despise them for creating a walled-garden ecosystem and cult around their products, but I genuinely have to respect them for Rosetta and Rosetta 2. Developing a binary translation layer is a whole different beast than high-level emulation, and it's significantly more difficult to pull off correctly. The fact that they managed to do it twice, and do it damn-near seamlessly is impressive. Rosetta 2 even supports translating just-in-time compiled code, which is a huge pain point for that kind of thing.

If you follow the history of the Mac, it went through a number of major architecture transitions from 680x0 -> PowerPC -> Intel -> ARM. Each time, Apple supplied a decent emulator to support applications during the transition.

From a developer perspective, these were huge upheavals that came with a lot of drama but also offered some opportunities. The latter came from the fact that the bar was in some way set higher on the new platform and you could count on any code you compiled for it supporting certain base features. Every PowerPC, for example, had hardware floating-point. Before that, some CPUs did, some didn't. The Intel transition happened at the time when dual core had become standard and SIMD had become serviceable (with SSE2). The ARM transition has set the bar at 64-bit architecture for every CPU (since Apple had earlier dumped 32-bit on the iPhone side).

Windows/Intel has developed in a more evolutionary than revolutionary manner, which is easy to see if you look, for example, at all the legacy cruft in the Intel ISA. It's a sad sight. Supporting all that makes instruction decoding a nightmare. In theory, Intel/AMD could reinvent a new sleeker ISA if they could get Microsoft to commit to supplying a performant emulator for the old one? But I'm not holding my breath.

NT is not the majority of windows code though; for windows to be multi architecture, all of windows needs to work with the new architecture; NT, drivers & userspace.

For Linux, if an existing userspace application doesn't work in aarch64, somebody somewhere will build a port. For windows, so much of their stuff is proprietary that Microsoft are the only ones able to build that port.

Not because "windows bad", just a consequence of such a locked down system which doesn't have anything open source to inherit.

Yes, and DEC Alpha too. But all of that ceased with windows 2000. The only porting since then was from x86 32bit to 64bit. I'm willing to bet money I don't have that Microsoft really only expected a port to 128bit x86 until ARM started gaining steam.

Not my area, but since OSs are really low-level (obviously), they can be affected by details of the host architecture that we don't often think about. Endianness, for instance.

I opened up the source package for the kernel I'm currently running (6.1.42) and looked at it. The smallest set of architecture-specific code is the ~2MB for sh (I assume that's SuperH, a 32-bit RISC architecture from the early 1990s). 32-bit ARM takes up 27MB, although if you check the individual files, a fair amount of that is device trees and the like. So we're talking about less than 50MB of arch-specific source code for most platforms, and probably less than 10 in many cases, but it depends on the design of the architecture and how many times it's been extended.

Looking at individual file names, topics addressed in the kernel's arch-specific code files appear to include booting, low-level memory access, how to idle the CPU, crypto primitives, interrupts, suspending/hibernating the system and other power management, virtualization facilities if the CPU provides them, crash dumps and stack traces, and, yes, endianness.

You may also need additional drivers for odd bits of hardware not used by other systems. Or not, but it's a common sticking point with ARM SOCs and other small-format machines.

That's just the kernel. You'll also need to establish a working cross-compiler before you can get your kernel onto the system. At that point, you can probably bootstrap much of the rest by running make and get to a working command-line system (GUI is going to be more of a crapshoot, requiring additional work on video acceleration and such in order to run well). And there may be odd warts in other pieces of software, each requiring a few lines of code that add up over time.

Because it's open source and most of the applications for it are open source. That means you can compile it and the applications specifically for the hardware you have.

Windows does kind of support ARM on its specific hardware, but it can't be adjusted for other hardware and they have to translate most applications to work. Apple has done much of that work for their hardware to work well, as well as very good translation for x86, and because they leaned hard into the transition, developers were mostly forced to compile for ARM going forward. Microsoft hasn't done the same, and ARM is a tiny target, so it doesn't happen with any regularity there.

Because people have been doing so for a long time and have ironed out most of the quirks. The software is also generally quite simple, meaning there are just fewer quirks that need to be ironed out. And the ecosystem is largely open source, meaning everything can be recompiled to target the relevant architecture, so while translation layers are still useful, they're not the essential tool they are in proprietary ecosystems. The main headaches that plague windows on arm mostly just don't exist on the Linux side.

Because it's not developed by some corporate fuckers whose only goal it is to make as much money as possible, it's developed by individual skilled people in their free time, because they're passionate. They don't want to sell some garbage, they genuinely want to make a good operating system for themselves and everyone else to freely use without any restrictions. FOSS is not about the money, it's about actually creating something good.

Permanently Deleted

Because you can try compile it on arm, and if something doesn't work you can report it or fix it yourself. That said windows worked fine on arm years ago. Many gps, medical, and such devices used to use windows ce on arm, mips. (Windows phone too, arm)

ARM the company as well as industry partners contribute code & resources to the linux kernel...so that would be one reason why linux on ARM runs well.

Unsure how we are tracking Microsoft ARM as worse than Linux arm, what benchmarks did we see?

I don’t know what distros are available, but the big project everyone is talking about when talking about Linux on apple silicon is Asahi Linux

Ooops! I meant to type 'Macbook Air'. I'll leave the goof up to give your comment context, but I don't have a MBP these days. I used the initial Asahi release and I've been upgrading it in place for a year or so.

You still need a way to know which memory addresses your I²C or SPI interface has. While DeviceTree is better than nothing, it's way worse than the "It just works" of ACPI

[This comment has been deleted by an automated system]

Theese devices support linux out of the box. Try installing a proper linux distro on your phone and good luck finding a graphics driver that is not sotware rendering

A key factor is LINUX has been available for ARM since nearly "the beginning". Unlike Windows, which was basically Intel only for well over a decade, LINUX has had strong support for multiple architectures throughout its lifecycle. As a result, software that grew up within that ecosystem tended to be more agnostic in design which helps porting efforts.