3 ms·

Unpopular opinion: it will be much worse. RISC-V is meant to be flexible and you can create CPUs that look very very different. Furthermore, some early chips u

by zibzab 5y ago

Unpopular opinion: it will be much worse. RISC-V is meant to be flexible and you can create CPUs that look very very different. Furthermore, some early chips used own solutions in some areas as a standard way of doing things was yet not available (e.g. memory protection). So we have a hardware landscape with extreme fragmentation. If people cannot agree on the hardware, I have hard time seeing them agreeing on the firmware.

IshKebab 5y ago
I don't think that's an unpopular opinion. It's more of an unfortunate truth.
hakfoo 5y ago
I'm not worried about the "early designs used their own solutions." Expecting standards compliance before the existence of standards requires the Time Travel extensions to the architecture. :) The problem is that you need a moment where the market switches from "hardware drives software advancement" to "software drives hardware standardization." Think of the x86 architecture-- in 1979, if you were designing a new 8086 computer, you'd want to design the best disc controller, memory map, and graphics modes you could, and build software to show them off. By 1986, you wanted to design ones that looked exactly like an IBM 5150 so that Lotus 1-2-3 and Flight Simulator would run out of the box. What specifically would be the comparable trigger for ARM or RISC-V? You need killer apps that sit close to the hardware, and are closed-source. It can't just be something that runs on top of Linux/BSD/Android/etc. because then vendors will cheat by building an unsupportable hairball of custom bootcode and drivers to get you to an ABI-compatible OS and say "that's compatible enough." It can't be open-source because vendors will cheat by hacking it to fit into their custom hardware and firmware designs. I'm not sure it's feasible today. Today's killer apps are not built with the 70s/80s mindset of writing directly to device registers for 1% more speed.

by zibzab 5y ago

IshKebab 5y ago

I don't think that's an unpopular opinion. It's more of an unfortunate truth.

hakfoo 5y ago

I'm not worried about the "early designs used their own solutions." Expecting standards compliance before the existence of standards requires the Time Travel extensions to the architecture. :) The problem is that you need a moment where the market switches from "hardware drives software advancement" to "software drives hardware standardization." Think of the x86 architecture-- in 1979, if you were designing a new 8086 computer, you'd want to design the best disc controller, memory map, and graphics modes you could, and build software to show them off. By 1986, you wanted to design ones that looked exactly like an IBM 5150 so that Lotus 1-2-3 and Flight Simulator would run out of the box. What specifically would be the comparable trigger for ARM or RISC-V? You need killer apps that sit close to the hardware, and are closed-source. It can't just be something that runs on top of Linux/BSD/Android/etc. because then vendors will cheat by building an unsupportable hairball of custom bootcode and drivers to get you to an ABI-compatible OS and say "that's compatible enough." It can't be open-source because vendors will cheat by hacking it to fit into their custom hardware and firmware designs. I'm not sure it's feasible today. Today's killer apps are not built with the 70s/80s mindset of writing directly to device registers for 1% more speed.