5 ms·

The ARM platform is currently massively held back IMO by its lack for standardization. I think there is tremendous value hidden behind a company that achieves a

by est31 6y ago

The ARM platform is currently massively held back IMO by its lack for standardization. I think there is tremendous value hidden behind a company that achieves a push for consistency. Microsoft has invested tens if not hundreds of thousands of man years in this, so who would be better qualified for this than them. RISC-V is kinda in a similar situation as ARM. If I were Microsoft, I'd be investing hard into the RISC-V platform as it still has tremendous growth left.

gsnedders 6y ago
> The ARM platform is currently massively held back IMO by its lack for standardization. Note there is progress there with things like ARM's ServerReady which standardises a lot. The Windows-on-ARM requirements also push a lot to be far more standardised (it effectively requires a subset of the ServerReady requirements AIUI).
kzrdude 6y ago
Isn't there more standardization in ARMv8?
adrian_b 6y ago
It would be very nice if an open CPU ISA, which can be implemented by everyone, like RISC-V, would be more widespread. Sadly, RISC-V is not a good candidate for that. It is an excellent ISA for student implementation projects, but not for real work. RISC-V is praised only by people who have very little or no experience with different CPU ISAs and with the history of their evolution. RISC-V sucks more than even the ugliest ISA, x86. At least from the huge x86 ISA it is possible to extract a subset composed mostly of more recently introduced instructions, which can be considered as a decent ISA, except for the weird encoding, with many prefix bytes, which is needed for backward compatibility. The 64-bit ARMv8 ISA is an example of a good ISA, but its future is clouded by the NVIDIA acquisition.
- yjftsjthsd-h 6y ago
  > RISC-V is praised only by people who have very little or no experience with different CPU ISAs and with the history of their evolution. I'm having trouble actually digging up the reference right now, but I've been told that it was specifically built out of decades of industry experience in what works in building processors/ISAs. > RISC-V sucks more than even the ugliest ISA, x86. How so? > At least from the huge x86 ISA it is possible to extract a subset composed mostly of more recently introduced instructions, which can be considered as a decent ISA, except for the weird encoding, with many prefix bytes, which is needed for backward compatibility. So, exactly like RISC-V base + extensions?
swiley 6y ago
What do you mean by "standardization?" Do you mean device probing? There's a standard API implemented by Linux for the firmware to communicate this to the kernel, also PCI works on ARM just like x86. No one bothers with this because all of the popular ARM SoCs tend to come from organizations that are extremely hostile to their users though. Do you mean user space ABI? GlibC on arm7 and aarch64 has had a pretty stable ABI for a while now, I can personally share binaries between all my arm machines that share an architecture (not that flinging binaries around is a good thing.)
- est31 6y ago
  > There's a standard API implemented by Linux for the firmware to communicate this to the kernel, also PCI works on ARM just like x86. No one bothers with this because all of the popular ARM SoCs tend to come from organizations that are extremely hostile to their users though. That's the problem. Most SoC vendors just don't care and implement drivers in or around forks of the kernel, and also specify the hardware via device trees. IIRC having the firmware give the device tree to the kernel instead of it being baked into the kernel is a new development. If MS came and said: we want stable interfaces, the vendors would buckle and MS would be able to ship one OS image to all devices, instead of having hw custom images.

by est31 6y ago

gsnedders 6y ago

> The ARM platform is currently massively held back IMO by its lack for standardization. Note there is progress there with things like ARM's ServerReady which standardises a lot. The Windows-on-ARM requirements also push a lot to be far more standardised (it effectively requires a subset of the ServerReady requirements AIUI).

kzrdude 6y ago

Isn't there more standardization in ARMv8?

adrian_b 6y ago

It would be very nice if an open CPU ISA, which can be implemented by everyone, like RISC-V, would be more widespread. Sadly, RISC-V is not a good candidate for that. It is an excellent ISA for student implementation projects, but not for real work. RISC-V is praised only by people who have very little or no experience with different CPU ISAs and with the history of their evolution. RISC-V sucks more than even the ugliest ISA, x86. At least from the huge x86 ISA it is possible to extract a subset composed mostly of more recently introduced instructions, which can be considered as a decent ISA, except for the weird encoding, with many prefix bytes, which is needed for backward compatibility. The 64-bit ARMv8 ISA is an example of a good ISA, but its future is clouded by the NVIDIA acquisition.

yjftsjthsd-h 6y ago
> RISC-V is praised only by people who have very little or no experience with different CPU ISAs and with the history of their evolution. I'm having trouble actually digging up the reference right now, but I've been told that it was specifically built out of decades of industry experience in what works in building processors/ISAs. > RISC-V sucks more than even the ugliest ISA, x86. How so? > At least from the huge x86 ISA it is possible to extract a subset composed mostly of more recently introduced instructions, which can be considered as a decent ISA, except for the weird encoding, with many prefix bytes, which is needed for backward compatibility. So, exactly like RISC-V base + extensions?

swiley 6y ago

What do you mean by "standardization?" Do you mean device probing? There's a standard API implemented by Linux for the firmware to communicate this to the kernel, also PCI works on ARM just like x86. No one bothers with this because all of the popular ARM SoCs tend to come from organizations that are extremely hostile to their users though. Do you mean user space ABI? GlibC on arm7 and aarch64 has had a pretty stable ABI for a while now, I can personally share binaries between all my arm machines that share an architecture (not that flinging binaries around is a good thing.)

est31 6y ago
> There's a standard API implemented by Linux for the firmware to communicate this to the kernel, also PCI works on ARM just like x86. No one bothers with this because all of the popular ARM SoCs tend to come from organizations that are extremely hostile to their users though. That's the problem. Most SoC vendors just don't care and implement drivers in or around forks of the kernel, and also specify the hardware via device trees. IIRC having the firmware give the device tree to the kernel instead of it being baked into the kernel is a new development. If MS came and said: we want stable interfaces, the vendors would buckle and MS would be able to ship one OS image to all devices, instead of having hw custom images.