6 ms·

I'm quite concerned about x86 future, but the article has a point if you read it past the title. It says that x86 is highly standardised - even with different

by mifydev 7mo ago

I'm quite concerned about x86 future, but the article has a point if you read it past the title. It says that x86 is highly standardised - even with different combinations of chips, peripherals and motherboards you know it will work just fine. It's not the case for ARM systems - can you even have something similar to IBM PC with ARM? I personally know that adding support for ARM devices on Linux is a huge and manual task - e.g. look at devicetree, it's a mess. There is no standard like ACPI for ARM devices, so even powering off the computer is a problem, everything is proprietary and custom. I don't agree with the article though, x86 is dying and my worry is that ARM devices will bring an end to such an open platform like modern PCs are.

davidkwast 7mo ago
RISC-V can be essential for this open future
- cardanome 7mo ago
  As far as I understand RISC-V has the same lack of standardization that ARM has, no?
  - mjg59 7mo ago
    If anything, worse - there's much wider variety in the set of CPU extensions available.
  - bee_rider 7mo ago
    RISV-V is messy but for good reason, with real standards, although lots of them, which can be hard to keep track of. X86 is de-facto standardized by vendor fiat. ARM is in an unfortunate middle ground.
- adrian_b 7mo ago
  RISC-V has a beautiful license, but it is one of the ugliest and least efficient computer ISAs ever designed. Any competent computer engineer can design a much better ISA than RISC-V. The problem is that designing a CPU ISA is easy and it can be done in a few weeks at most. On the other hand, writing all the software tools that you need to be able to use an ISA, e.g. assemblers, linkers, debuggers, profilers, compilers for various programming languages etc. requires a huge amount of work, of many man-years. The reason why everybody who uses neither x86 nor Arm tends to use RISC-V is in order to reuse the existing software toolchains, and not because the RISC-V ISA would be any good. The advantage of being able to use already existing software toolchains is so great that it ensures the use of RISC-V regardless how bad it is in comparison with something like Aarch64. The Intel ISA, especially its earlier versions, has also been one of the ugliest ISAs, even if it seems polished when compared to RISC-V. It would be sad if after so many decades during which the Intel/AMD ISA has displaced other better ISAs, it would eventually be replaced by something even worse. As one of the main examples of why RISC-V sucks, I think that any ISA designer who believes that omitting from the ISA the means for detecting integer overflow is a good idea deserves the death penalty, unless the ISA is clearly declared as being a toy ISA, unsuitable for practical applications.
  - fragmede 7mo ago
    What does that mean in a world where writing software just got a few orders of magnitude cheaper? An Andrew Huang could create a new ISA replete with everything and get it done.
    - kode-targz 7mo ago
      It didn't though. Not good software at least. AI (which is what I'm guessing you're referring to here) is simply incapable of writing such mission -critical low-level code, especially for a niche and/or brand new ISA. It simply can't. It has nothing to plagiarize from, contrary to the billions of lines of JavaScript and python it has access to. This kind of work can most definitely be AI-assisted, but my estimate is that the time gained would be minimal. An LLM is able to write some functional arduino code, maybe even some semi-functional bare-metal esp32 code, but nothing deeper than that.
  - pseudohadamard 7mo ago
    I think that any ISA designer who believes that omitting from the ISA the means for detecting integer overflow is a good idea deserves the death penalty Given that the C standard (C99 §3.4.3/1) declares integer overflow to be UB which means the compiler can and often will do anything it damn well pleases with your code, I can understand why the RISC-V designers, under the influence of the stupidity of the C standard, could leave out overflow detection. I'm not saying it's a good idea, in fact it's complete and utter braindamage, but I can see where they got it from.
    - snvzz 7mo ago
      The premise that the ISA has no means for detecting integer overflow is false. This is explicitly documented in the spec, even. e.g. add t2, t0, t1 bltu t2, t0, overflow The implication that the ISA is not designed by competent engineers does not pass basic scrutiny, either.
      - rep_lodsb 7mo ago
- pseudohadamard 7mo ago
  RISC-V is the ARM mess taken to extremes. From TFA: It’s a crapshoot. That’s why whenever anyone recommends a certain cool Arm motherboard or mini PC, the first thing you have to figure out is what its software support situation is like. Does the OEM provide blessed Linux images? If so, do they offer more than an outdated Ubuntu build? Have they made any update promises? Almost every ARM board I've got is running ancient kernel images that were out of date even when they were released and haven't got any newer since then, but that's positively great compared to the RISC-V situation where you feel like you're taking your life into your hands every time you try and update it. The last update I did, to a popular widely-used board, took close to a full day to progressively reflash different levels of boot loaders and kernel images and whatnot, repartition the MTD for each reflash, hack around hardware and boot params via the serial interface through trial-and-error, and slowly work my way up to a current already out-of-date firmware and kernel config. I really hate to like x86 but I know that when I set up an embedded x86 device it's flash, apt-get update/upgrade, and I've got the latest stuff running and supported.
craftkiller 7mo ago
> can you even have something similar to IBM PC with ARM Yes, it's called SBBR which requires UEFI and ACPI. It is more common on server hardware than on consumer-grade embedded devices. The fact that it is not ubiquitous is really holding back ARM.
- M95D 7mo ago
  Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it? Device tree does the same thing and it's open source. Even if you only extract it in binary form a proprietary kernel or uboot, you can decompile it very easily.
  - craftkiller 7mo ago
    The person I was replying to was specifically asking for ACPI for ARM and they specifically stated their negative opinion of device tree.
  - yjftsjthsd-h 7mo ago
    > Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it? Well, no, UEFI can have proprietary implementations, but nothing prevents just shipping edk2. Conversely, there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring 0. You're kinda pointing out a real problem, but confusing it with a different part of the stack.
    - M95D 7mo ago
      > there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring 0 It's not the same! A bootloader, once it loads the kernel and executes it, is overwritten in memory. No trace of it remains while the sistem is running - until the next boot. UEFI / ACPI / SMM continue to execute on the CPU after it finished booting, "under" the kernel, preempting it as they please.
mjg59 7mo ago
There's a standard like ACPI for Arm devices - it's called ACPI, and it's a requirement for the non-Devicetree SystemReady spec (https://www.arm.com/architecture/system-architectures/systemready-compliance-program/systemready-band https://www.arm.com/architecture/system-architectures/system...). But it doesn't describe the huge range of weirdness that exists in the more embedded end of the Arm world, and it's functionally impossible for it to do so while Arm vendors see devices as an integrated whole rather than a general purpose device that can have commodity operating systems installed on them.
M95D 7mo ago
> my worry is that ARM devices will bring an end to such an open platform like modern PCs are. Modern PCs are NOT open platform anymore. Not since signed bootloaders, UEFI, secure boot. ARM on the other hand, as long as they don't require signed bootloaders (like phones) or a closed source driver for GPU or something, are in fact open.
- fragmede 7mo ago
  You can still boot Linux on PCs though. ARM devices, you're SOL in most cases. Device tree is a total shit show. For random ARM device, better hope randomInternetHero42 on a random forum has it for your device. Just asking the device itself what exists would be stupid question in ARM world.
  - M95D 7mo ago
    I don't know what you're talking about. If the device boots, you find the device tree in /sys/firmware/fdt, or in unpacked human-readable form in /sys/firmware/devicetree/* .
    - mjg59 7mo ago
      And you're stuck with whatever fucked up kernel the vendor gave you, assuming they even followed their obligations and gave you access to the source. The vast majority of x86 systems run mainline kernels because there's a sufficient level of abstraction. The number of Arm devices that's true for is a tiny percentage of the Arm devices out there running Linux.
      - M95D 7mo ago
        True. But I'm voting with my wallet supporting those manufacturers that upstream to mainline kernel and don't require any signed firmware to boot.
- rep_lodsb 7mo ago
  Secure boot can be disabled even on modern PCs.
toast0 7mo ago
> can you even have something similar to IBM PC with ARM? AFAIK, ARM does not have port mapped i/o, so that makes it difficult to really match up with the PC. That said, an OS can require system firmware to provide certain things and you get closer to an IBM like world. Microsoft requires UEFI for desktop Windows (maybe WP8 and WM10 as well, but I believe those were effectively limited to specific qualcomm socs, whereas I feel like Desktop windows is supposed to be theoretically open to anything that hits the requirements). ACPI for ARM is a thing that exists, but not all ARM systems will have it. Technically, not all x86 systems have it either, but for the past several generations of Intel and AMD, all the hardware you need for ACPI is embedded in the CPU, so only old hardware or really weird firmware would be missing it. Also, PC i/o is so consistent, either by specification or by consensus, that it's easy to detect hardware anyway: PCI is at a specific i/o port by specificiation; cpu ID/MSR lets you locate on-chip memory mapped perhipherals that's aren't attached via PCI, and PCI has specificied ways to detect attached hardware. There's some legacy interfaces that aren't on PCI that you might want, and you need ACPI to find them properly, but you can also just poke them at their well known address and see if they respond. AFAIK, you don't get that on other systems... many perhipherals will be memory mapped directly, rather than attached via PCI; the PCI controller/root is not at a well known address, etc, every system is a little different because there's no obvious system to emulate. Mostly ACPI is about having hardware description tables in a convenient place for the OS to find it. Certainly standardized understanding of power states and the os-independent description of how to enter them is important too. There are/were other proposals, but if you want something like UEFI and ACPI, and you have clout, you can just require it for systems you support. The market problem is Apple doesn't let their OS run on anything non-Apple, and Android has minimal standards in this area; whereas the marketplace for software for the IBM PC relied heavily on the IBM BIOS, the marketplace of software for Android relies on features of the OS; SoC makers can build a custom kernel with the hardware description hardcoded and there's no need to provide an in firmware system of hardware description. Other OSes lose out because they too need custom builds for each SoC.

by mifydev 7mo ago

davidkwast 7mo ago

RISC-V can be essential for this open future

cardanome 7mo ago
As far as I understand RISC-V has the same lack of standardization that ARM has, no?
- mjg59 7mo ago
  If anything, worse - there's much wider variety in the set of CPU extensions available.
- bee_rider 7mo ago
  RISV-V is messy but for good reason, with real standards, although lots of them, which can be hard to keep track of. X86 is de-facto standardized by vendor fiat. ARM is in an unfortunate middle ground.
adrian_b 7mo ago
RISC-V has a beautiful license, but it is one of the ugliest and least efficient computer ISAs ever designed. Any competent computer engineer can design a much better ISA than RISC-V. The problem is that designing a CPU ISA is easy and it can be done in a few weeks at most. On the other hand, writing all the software tools that you need to be able to use an ISA, e.g. assemblers, linkers, debuggers, profilers, compilers for various programming languages etc. requires a huge amount of work, of many man-years. The reason why everybody who uses neither x86 nor Arm tends to use RISC-V is in order to reuse the existing software toolchains, and not because the RISC-V ISA would be any good. The advantage of being able to use already existing software toolchains is so great that it ensures the use of RISC-V regardless how bad it is in comparison with something like Aarch64. The Intel ISA, especially its earlier versions, has also been one of the ugliest ISAs, even if it seems polished when compared to RISC-V. It would be sad if after so many decades during which the Intel/AMD ISA has displaced other better ISAs, it would eventually be replaced by something even worse. As one of the main examples of why RISC-V sucks, I think that any ISA designer who believes that omitting from the ISA the means for detecting integer overflow is a good idea deserves the death penalty, unless the ISA is clearly declared as being a toy ISA, unsuitable for practical applications.
- fragmede 7mo ago
  What does that mean in a world where writing software just got a few orders of magnitude cheaper? An Andrew Huang could create a new ISA replete with everything and get it done.
  - kode-targz 7mo ago
    It didn't though. Not good software at least. AI (which is what I'm guessing you're referring to here) is simply incapable of writing such mission -critical low-level code, especially for a niche and/or brand new ISA. It simply can't. It has nothing to plagiarize from, contrary to the billions of lines of JavaScript and python it has access to. This kind of work can most definitely be AI-assisted, but my estimate is that the time gained would be minimal. An LLM is able to write some functional arduino code, maybe even some semi-functional bare-metal esp32 code, but nothing deeper than that.
- pseudohadamard 7mo ago
  I think that any ISA designer who believes that omitting from the ISA the means for detecting integer overflow is a good idea deserves the death penalty Given that the C standard (C99 §3.4.3/1) declares integer overflow to be UB which means the compiler can and often will do anything it damn well pleases with your code, I can understand why the RISC-V designers, under the influence of the stupidity of the C standard, could leave out overflow detection. I'm not saying it's a good idea, in fact it's complete and utter braindamage, but I can see where they got it from.
  - snvzz 7mo ago
    The premise that the ISA has no means for detecting integer overflow is false. This is explicitly documented in the spec, even. e.g. add t2, t0, t1 bltu t2, t0, overflow The implication that the ISA is not designed by competent engineers does not pass basic scrutiny, either.
    - rep_lodsb 7mo ago
pseudohadamard 7mo ago
RISC-V is the ARM mess taken to extremes. From TFA: It’s a crapshoot. That’s why whenever anyone recommends a certain cool Arm motherboard or mini PC, the first thing you have to figure out is what its software support situation is like. Does the OEM provide blessed Linux images? If so, do they offer more than an outdated Ubuntu build? Have they made any update promises? Almost every ARM board I've got is running ancient kernel images that were out of date even when they were released and haven't got any newer since then, but that's positively great compared to the RISC-V situation where you feel like you're taking your life into your hands every time you try and update it. The last update I did, to a popular widely-used board, took close to a full day to progressively reflash different levels of boot loaders and kernel images and whatnot, repartition the MTD for each reflash, hack around hardware and boot params via the serial interface through trial-and-error, and slowly work my way up to a current already out-of-date firmware and kernel config. I really hate to like x86 but I know that when I set up an embedded x86 device it's flash, apt-get update/upgrade, and I've got the latest stuff running and supported.

craftkiller 7mo ago

> can you even have something similar to IBM PC with ARM Yes, it's called SBBR which requires UEFI and ACPI. It is more common on server hardware than on consumer-grade embedded devices. The fact that it is not ubiquitous is really holding back ARM.

M95D 7mo ago
Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it? Device tree does the same thing and it's open source. Even if you only extract it in binary form a proprietary kernel or uboot, you can decompile it very easily.
- craftkiller 7mo ago
  The person I was replying to was specifically asking for ACPI for ARM and they specifically stated their negative opinion of device tree.
- yjftsjthsd-h 7mo ago
  > Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it? Well, no, UEFI can have proprietary implementations, but nothing prevents just shipping edk2. Conversely, there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring 0. You're kinda pointing out a real problem, but confusing it with a different part of the stack.
  - M95D 7mo ago
    > there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring 0 It's not the same! A bootloader, once it loads the kernel and executes it, is overwritten in memory. No trace of it remains while the sistem is running - until the next boot. UEFI / ACPI / SMM continue to execute on the CPU after it finished booting, "under" the kernel, preempting it as they please.

mjg59 7mo ago

There's a standard like ACPI for Arm devices - it's called ACPI, and it's a requirement for the non-Devicetree SystemReady spec (https://www.arm.com/architecture/system-architectures/systemready-compliance-program/systemready-band https://www.arm.com/architecture/system-architectures/system...). But it doesn't describe the huge range of weirdness that exists in the more embedded end of the Arm world, and it's functionally impossible for it to do so while Arm vendors see devices as an integrated whole rather than a general purpose device that can have commodity operating systems installed on them.

M95D 7mo ago

> my worry is that ARM devices will bring an end to such an open platform like modern PCs are. Modern PCs are NOT open platform anymore. Not since signed bootloaders, UEFI, secure boot. ARM on the other hand, as long as they don't require signed bootloaders (like phones) or a closed source driver for GPU or something, are in fact open.

fragmede 7mo ago
You can still boot Linux on PCs though. ARM devices, you're SOL in most cases. Device tree is a total shit show. For random ARM device, better hope randomInternetHero42 on a random forum has it for your device. Just asking the device itself what exists would be stupid question in ARM world.
- M95D 7mo ago
  I don't know what you're talking about. If the device boots, you find the device tree in /sys/firmware/fdt, or in unpacked human-readable form in /sys/firmware/devicetree/* .
  - mjg59 7mo ago
    And you're stuck with whatever fucked up kernel the vendor gave you, assuming they even followed their obligations and gave you access to the source. The vast majority of x86 systems run mainline kernels because there's a sufficient level of abstraction. The number of Arm devices that's true for is a tiny percentage of the Arm devices out there running Linux.
    - M95D 7mo ago
      True. But I'm voting with my wallet supporting those manufacturers that upstream to mainline kernel and don't require any signed firmware to boot.
rep_lodsb 7mo ago
Secure boot can be disabled even on modern PCs.

toast0 7mo ago

> can you even have something similar to IBM PC with ARM? AFAIK, ARM does not have port mapped i/o, so that makes it difficult to really match up with the PC. That said, an OS can require system firmware to provide certain things and you get closer to an IBM like world. Microsoft requires UEFI for desktop Windows (maybe WP8 and WM10 as well, but I believe those were effectively limited to specific qualcomm socs, whereas I feel like Desktop windows is supposed to be theoretically open to anything that hits the requirements). ACPI for ARM is a thing that exists, but not all ARM systems will have it. Technically, not all x86 systems have it either, but for the past several generations of Intel and AMD, all the hardware you need for ACPI is embedded in the CPU, so only old hardware or really weird firmware would be missing it. Also, PC i/o is so consistent, either by specification or by consensus, that it's easy to detect hardware anyway: PCI is at a specific i/o port by specificiation; cpu ID/MSR lets you locate on-chip memory mapped perhipherals that's aren't attached via PCI, and PCI has specificied ways to detect attached hardware. There's some legacy interfaces that aren't on PCI that you might want, and you need ACPI to find them properly, but you can also just poke them at their well known address and see if they respond. AFAIK, you don't get that on other systems... many perhipherals will be memory mapped directly, rather than attached via PCI; the PCI controller/root is not at a well known address, etc, every system is a little different because there's no obvious system to emulate. Mostly ACPI is about having hardware description tables in a convenient place for the OS to find it. Certainly standardized understanding of power states and the os-independent description of how to enter them is important too. There are/were other proposals, but if you want something like UEFI and ACPI, and you have clout, you can just require it for systems you support. The market problem is Apple doesn't let their OS run on anything non-Apple, and Android has minimal standards in this area; whereas the marketplace for software for the IBM PC relied heavily on the IBM BIOS, the marketplace of software for Android relies on features of the OS; SoC makers can build a custom kernel with the hardware description hardcoded and there's no need to provide an in firmware system of hardware description. Other OSes lose out because they too need custom builds for each SoC.