[0xTJ]

I think that's the wrong question to ask. Aside from those writing kernels, compilers, JITs, etc., developers don't need to care, that's the point of programming languages and compilers. Throw a toolchain at a developer and tell them to do it and they can do it.

Comparing RISC-V to OpenSPARC is comparing apples to oranges. One is an ISA, the other is a hardware project.

What do you mean by "We barely have a decent ARM ecosystem". Are you talking about the tools to build for those processors? Or the tools to build new ones of those processors? Or the actual chips that are available?

I'm basically always within 10m of at least a half dozen ARM processors, and a handful of 8051s. At worst, RISC-V could be equivalent to ARM, without many of the parts that suck about it.

[fierarul]

Are we talking about RISC-V as an abstract idea, the same way we would talk about the benefits of functional or object oriented programming here?

Or is the end goal to have hardware in stores that people can buy?

Wasn't SPARC a RISC architecture? (Wikipedia says so, but I'm no expert).

> What do you mean by "We barely have a decent ARM ecosystem". Are you talking about the tools to build for those processors? Or the tools to build new ones of those processors? Or the actual chips that are available?

I remember the early OpenWRT / RPi days when many packages weren't even compiling for ARM. Now I think we are in a much better shape. The chips were available, but the software ecosystem was way behind.

> At worst, RISC-V could be equivalent to ARM, without many of the parts that suck about it.

What I do know about ARM sucking is that the whole board design makes each product need a customer kernel more or less. Which is why we still don't have a "Linux for your phones". What I've read about RISC is that it's going to be roughly the same: encourage a lot of co-processors which mean custom boards to me and probably custom kernels.

[jabl]

> What I do know about ARM sucking is that the whole board design makes each product need a customer kernel more or less. Which is why we still don't have a "Linux for your phones". What I've read about RISC is that it's going to be roughly the same: encourage a lot of co-processors which mean custom boards to me and probably custom kernels.

FWIW, this has nothing to do with the ISA per se, and particularly absolutely nothing to do with whether the ISA is RISC, CISC, or something else.

The problem is that like so many other embedded systems, ARM systems don't have peripherals which are discoverable at boot, hence all that has to be hardcoded (or specified at boot via devicetree) into the kernel (e.g. the interrupt controller is model XYZZY and is accessible at address 0xBEEF). So you end up with a kernel binary that works only on a specific board.

The "server-class" ARM systems adhere to something called SBSA which is a specification incorporating things like UEFI, ACPI, PCIe etc. The end result being that SBSA systems can use a common distro kernel just like x86 systems can.

[fierarul]

I learned something, thank you! Considering how performant modern phones are I hope all adhere to SBSA or similar so I can install any OS on my phone just like I could on my 100Mhz PC way back.