3 ms·
Any bets on when we we’ll see RISC-VI? And which aspects of RISC-V it will change, correcting mistakes or designs that didn’t scale to unanticipated computing e
by cpeterso 3y ago
Any bets on when we we’ll see RISC-VI? And which aspects of RISC-V it will change, correcting mistakes or designs that didn’t scale to unanticipated computing environments or requirements?
- brucehoult 3y ago2100. Or never. IBM System/360 is still going strong after 60 years, with extensions not replacement. Only the 24 bit memory addresses were short-sighted. Motorola 68000 and ARM made the same mistake, 15 and 20 years later. Let's not even mention x86 memory addressing. RISC-V has that covered with 64 bit from the outset, and 128 bit addressing included in the planning. The basic RISC idea of separating load/store from arithmetic has stood the test of time for 60 years too, since 1964's CDC6600, the first supercomputer, and the fastest one for the rest of that decade. The Cray 1 in 1975 is also very much a RISC computer on the scalar side (plus vectors very similar to modern RISC-V V extension). Both of those machines had two instruction lengths just like current RISC-V: 15 and 30 bits on the CDC6600 and 16 and 32 bits on the Cray 1. RISC-V has had plans for future longer instructions, if necessary, from the outset. IBM 360 is actually very similar, with the same 2 bits in every instruction specifying whether the instruction is 16, 32, or 48 bits long. This makes very wide instruction decode simple -- 8 wide, 16 wide, even 32 wide if that is ever practical. Not quite as simple as doing the same thing on a completely fixed length ISA such as Aarch, but simple enough to not be a problem. Unlike x86. What else might want to change? More registers? That is easily handled with the planned-for 48 bit or 64 bit instruction formats. The long instructions can address all 64 or 256 or 1024 registers, while the 32 bit instructions can use only 32 of them, and the 16 bit instruction can use (mostly) only 8 of them. Or x86-style REX prefixes could be used. That works, but is worse for wide instruction decode unless the prefix itself indicates the full instruction length.
- cpeterso 3y agoThanks. It's interesting to see the commonality (path dependence?) of these ISAs and RISC-V's extensible design. I'm reminded of "How DEC Developed Alpha" (1992), an article describing how DEC designed the Alpha architecture to scale to handle a 1000-fold performance increase they anticipated over the next 25 years: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=144508 https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=144...
- brucehoult 3y agoIt would have worked too, if Alpha hadn't gone down along with the mismanaged company that owned it. That's perhaps the biggest thing about RISC-V: no one company can kill it by going out of business (DEC), by getting bored with it (Oracle with SPARC), or by deciding to replace it with something else (Intel with Itanium). If the company you were buying RISC-V disappears, you can choose from ten others -- maybe 100 or 1000 others one day. Or, if you have the skills, you can design your own ... maybe in an FPGA if technology has moved along and you were using an old design. Or if another ISA takes over, you can run a RISC-V emulator on whatever the new ISA is. All of this without any questions or worries about legality, licenses, patents.
- pjmlp 3y agoYeah, only a breaking change like quantum computing going mainstream, would change the current course. FPGAs and special purpose CPUs don't change much, as they have also been around for decades.