3 ms·
Things get locked in not by standards, but by usage. If your software depends on particular instructions being present you’re not going to buy a processor that
by wmanley 5y ago
Things get locked in not by standards, but by usage. If your software depends on particular instructions being present you’re not going to buy a processor that has superseded those instructions, even if the new instructions conform to a theoretically cleaner design.
Everything being an extension (and thus removable) is a strength in some specific circumstances, but is a weakness in most.
- socialdemocrat 5y agoThat doesn't make any sense. Because RISC-V has kept instructions to such a bare minimum, there will be very little you will be dependent on and which new designs have to take into account. What you describe is a problem for x86 and ARM not for RISC-V. You got it all in reverse. General-purpose CPUs for desktop computers and such will not be willy nilly adding extensions. They will standardize on something like RV64GC. However for specialized hardware which you only ever deal with through drivers, nobody will care whether extensions come and go. Are you worried that the processor in your keyboard or mouse isn't backwards compatible with the processor you used in your previous mouse or keyboard? Anyway code today can already check what extensions you have and generate different code paths. You can ship operating systems which have fallback code for most extensions so they can be be removed in the future. You also got traps so RISC-V can jump to a software implementation of unsupported instructions.
- wmanley 5y ago> Are you worried that the processor in your keyboard or mouse isn't backwards compatible with the processor you used in your previous mouse or keyboard? No, but the keyboard manufacturer might be, as might the people who are writing and optimising compilers targetting that CPU.