Hacker News Reader

Comment by Nevermark | Hacker News Reader

I am curious how AMD sees themselves staying relevant in the value chain as compute is increasingly about cpu cores working with npu cores.

Not all ARM use cases need that, but it would be a huge mistake to not develop integrated options.

And also an opportunity to make adjustments to their business model.

View on HN

ARM is an incompatible pile of mess. On an (X86) PC you can tranfer your disk, as it is, to a new X86 architecture and it will run.

On ARM, every processor has its own bootloader, blobs needed for initialisation. Even the systems have different architecture. In the end, you need a special software setup, which is not supported more than a few years. See phones, Raspberry PIs and derivatives, Chromebooks.

> On an (X86) PC you can tranfer your disk, as it is, to a new X86 architecture and it will run.

This is because of a supporting set of standards (BIOS/UEFI/ACPI) that are well-supported on x86 systems, but technically independent of the x86 ISA. BIOS, and the general compatibility you're talking about, is a historical artefact of the IBM PC being so dominant in the market that other companies created compatible computers. UEFI and ACPI actually exist in the ARM ecosystem now. If ARM continues to grow outside of mobile devices, you could eventually see the kind of broad compatibility you're talking about. It's not super likely though. All signs point to the consumer computing ecosystem becoming more closed, rather than more open.

Then ARM should create and promote similar standards.

They have the ServerReady compliance program for servers[0], but not for the plethora of SoC boards out there.

[0] https://developer.arm.com/community/arm-community-blogs/b/ar...

I always wondered how ARM lost the plot there.

Considering the original ARM use case was a desktop-computer shaped thing with some degree of expandability, they had to solve the same problems that the PC did in bringup/enumeration/device abstraction. These should be solved problems.

At some point between Archimedes and iPhone, they lost this functionality. I assume there was a moment where they assumed that they were only doing SoCs with fixed peripherals and jettisoned all their knowledge and tooling in the space.

> ...lost the plot...

> ...jettisoned all their knowledge and tooling in the space.

ARM made a smart decision not to compete against Intel/AMD at the cutting edge, and instead completely dominated the low-power CPU market.

> These should be solved problems.

They are. The solutions have nothing to do with the ISA. The device discovery functionality you're talking about (ACPI/BIOS/etc) is provided by the motherboard, and (in the case of ACPI) made available to the OS by the bootloader. SoC's don't need sophisticated device discovery.

I think this comment finally explains to me why we find issues with rooting/flashing other isos on Android phones each having seperate methods which I always used to wonder. So thanks!

Quick question but How does Risc-V compare to this?

What we have of RISC-V mostly goes ARM route. The problem isn't ISA itself, it's the peripherals. Most x86 motherboards comes with ACPI that (while being an unholy mess of a specification) allows vendors to provide bytecode drivers for simple stuff like power regulators and fan controls. In theory ACPI and UEFI are cross-platform, but no SoC or platform vendor seems to bother. RISC-V embraced opensource which means you get a declarative devicetree specification, but no runnable drivers to go with it. So all peripheral drivers must be upstream to be usable. That's of course not realistic because SoC vendors don't give a shit about your problems (and because Linux isn't the one and only OS!). Interestingly, devicetree, originally conceived as a part of OpenFirmware, was supposed to go with a Forth virtual machine exactly for this reason, but that part never made it to RISC-V.

Paradoxically, Linux core maintainers prefer the ARM situation (as do RMS-grade FOSS fans). For them going x86 route means constantly getting blame for crappy code they didn't wrote. Not that I'm unsympathetic, but it really goes against users' interests. And again, BSDs and smaller OSes often simply doesn't have resources to support the myriads of platform hardware.

This is a result of the market and its demands, not something specific to the architecture. In desktop and server, customers demand that they can buy a new machine and install a previously released stable OS on it. That means the vendors will implement the necessary standards and cross compatibility to make that happen. In the embedded market, customers don't demand that, and so vendors have no incentive to provide it. Instead what you get is that the specific combined hardware-and-software product works and is shipped with whatever expedient set of hacks gets it out of the door. Having a new cool hardware feature that works somehow or other is more important for sales than whether that driver is upstream or there's a way to describe it in ACPI.

Where Arm is in markets that do demand compatibility (i.e. server) the standards like UEFI and ACPI are there and work. Where it's in markets like embedded, you still see the embedded profusion of different random stuff. Where other architectures are in the embedded market, you also see a wide range of different not very compatible hardware: look at riscv for an example.

AMD has CPU, GPU, NPU, FPGA, NIC, DPU... They seem well positioned. The Arm ecosystem has everything you could want but Arm themselves are taking some time to create their in-house CPU and TPU.

That's good news. A system for customers (and themselves) to conveniently tightly mix and match all those computing modes is a great competitive/value move.

Reply on news.ycombinator.com