Thanks for this. One thing you didn't touch on is how consumer demand affects creating a new ISA. Case in point, the transition from x86 to HP and Intel's EPIC/IA-64/Itanium ("Itanic") would mean consumers losing much software investment (previous investment trap?) or having that investment relegated to an x86 compatibility mode on the Itanium chip. Customers did not want that. AMD64 was released and widely (wildly?) adopted instead of Itanium because of its backward compatibility which allowed customers to avoid losing existing software. Sales of Itanium were meager at best. It is an ISA that flopped hard. The last systems with it were released in 2017 and vendor support ended in 2021. The last Oracle SPARC systems were also released in 2017 although support for existing SPARC systems is projected to be until 2034.
Great comment! Absolutely agree. Over time we're accumulating more and more software for the mainstream architectures -most especially x86 / AMD64 - so that means it gets harder and harder to abandon these architectures.
In that context I'm really intrigued by what Apple has done with Rosetta 2 with its AOT compilation of x86 to AArch64. It seems like such a good product - even dealing with JIT for example - so it now seems like an obvious answer to the challenge of moving on from x86.
Loved your thoughts! What do you think about the Mill computing architecture? I'm sure they plan on licensing it, so it would be very difficult for them to get a foothold in the market, but it certainly has some unique design ideas.
Thanks so much. I think the Mill is interesting - it's on my (very long!) list of architectures to write about (possibly 2026!?). I do think RISC-V will make it harder and harder for new architectures to get traction - a bit like Linux and operating systems - unless they give demonstrably better performance in a new area like machine learning (like the TPU etc).
That makes a lot of sense, as I guess most of the benefits of an architecture are that it's widely used and supported—not that it's technically superior.
I don't think it would only find success in new areas, because if it's significantly faster it would be great for HPC (where they already don't use standard ISAs), but I could also see it in an ML chip like you mentioned.
> My best guess then is that RISC-V isn’t the last ISA. But it will be the ancestor of all future ISAs.
Very late comment :-)
Whatever instructions you add, as long as the machine can run RV32I/RV64I User mode code (or perhaps E rather than I) then it *is* RISC-V. All other extensions are strictly optional, the standard privileged architecture is explicitly just one of many possible privileged architectures.
So the question is more whether someone else's profile (set of extensions) becomes popular instead of the official profiles (RVA23 etc).
Not that RV32I/RV64I is perfect. I have several things I'd change if it could be done over.
One is that I think `slt{u}{i}` should produce an all-0s or all-1s result, not 0 or 1 like the C '<' operator. Most uses are consumed locally by code that only cares whether the result is 0 or not, wanting a mask is the 2nd most common use, and needing to store an actual 0 or 1 in RAM or as a function result is quite rare. Converting between the two forms is only one instruction (subtract from the ZERO register) but the case where you're doing it in a hot loop is usually the masking use.
Obviously this is not worth forking the world over.
I also think most of the OP-IMM instructions don't earn their keep in terms of opcode space used -- each one uses 4M code points, 1/256th of the 4 byte opcode space. Only `addi` is really needed, `slti`, `sltiu`, `andi`, `ori`, `xori` are used very rarely, much less than one instruction in 256, and can easily be replaced by a two instruction sequence using a temporary register. Only `sltiu rd, rs, 1` is used fairly frequently to implement `seqz rd, rs`, the other 4095 immediate values are rare. Providing `seq rd,rs1,rs2` and `sne rd,rs1,rs2` would make more sense, operations that currently need a two instruction `sub;s{eq,ne}z`. Also relatively common is `andi` with a small value, especially 1, which is covered by `c.andi`, or `xori` with -1, which is now covered by Zbb's `orn` or `xnor` with the Zero register as the non-inverted input.
The shifts `slli`, `srli`, `srai` are used much more often and also use only 32k (RV32) or 64k (RV64) code points each. But even then almost all uses have either `rd = rs1`, so the C extension instruction can be used, or else if there is a different `rd` fall under the Zba extension's `sh1add`, `sh2add`, `sh3add`.
So, yeah, with hindsight 5*4M + 3*64k = 21,168,128 code points (1.97% of the opcode space) could be painlessly removed from RV64I and replaced with 2*32k code points for `seq` and `sne` register-to-register instructions.
For reference, that is 40% of the opcode space used by the largest ISA extension there has been to date -- or probably will ever be -- the Vector extension, which had to make some encoding sacrifices to shoehorn it into an acceptable number of code points.
Most extensions add only a handful of register-to-register instructions at 32k code points each. Not having `slti`, `sltiu`, `andi`, `ori`, `xori` would give room for 640 such new instructions.
A bit more frugality in RV64I could have made finding opcode space for future extensions considerably easier.
But, again, not worth forking the world over at this point.
Interesting article, however... by paragraph eight I was practically screaming in my head "Have you never heard of quantum computing?!"
Talk about a radically new future computing paradigm that's guaranteed to be the Genesis of a raft of new ISA's.
In fact I'm thinking this will start the cycle all over again with each player creating a new ISA that will fight it out in the marketplace with the others until they're whittled down to less than a handful.
Who knows. By then we may be working on the next thing beyond that and starting the cycle all over again.
Hi, You're right but I had quantum in the category of accelerators like GPUs. Is it really a replacement for the general purpose von-Neumann CPU? Interested to hear your thoughts!
Not right now, no. But in the future who knows? I'd be surprised if quantum computer development doesn't continually push quantum computing into more and more areas of traditional computing.
I'm not sure I'd eliminate GPU's either since they are full fledged CPU's in their own right, albeit with a design skewed towards floating point and vector math performance.
Your overall idea is interesting, but I don't think we're there yet, or that RISC-V will be that final ISA. don't get me wrong, I'm a huge fan of RISC-V, I just don't see it as the final ISA. I think we're more likely to see a future with an open standard that software can be written to and each CPU architecture translates or recompiles to native. Think POSIX meets OpenCL, meets Java bytecode, meets transmeta, meets JIT.
Thanks for this. One thing you didn't touch on is how consumer demand affects creating a new ISA. Case in point, the transition from x86 to HP and Intel's EPIC/IA-64/Itanium ("Itanic") would mean consumers losing much software investment (previous investment trap?) or having that investment relegated to an x86 compatibility mode on the Itanium chip. Customers did not want that. AMD64 was released and widely (wildly?) adopted instead of Itanium because of its backward compatibility which allowed customers to avoid losing existing software. Sales of Itanium were meager at best. It is an ISA that flopped hard. The last systems with it were released in 2017 and vendor support ended in 2021. The last Oracle SPARC systems were also released in 2017 although support for existing SPARC systems is projected to be until 2034.
Great comment! Absolutely agree. Over time we're accumulating more and more software for the mainstream architectures -most especially x86 / AMD64 - so that means it gets harder and harder to abandon these architectures.
In that context I'm really intrigued by what Apple has done with Rosetta 2 with its AOT compilation of x86 to AArch64. It seems like such a good product - even dealing with JIT for example - so it now seems like an obvious answer to the challenge of moving on from x86.
Loved your thoughts! What do you think about the Mill computing architecture? I'm sure they plan on licensing it, so it would be very difficult for them to get a foothold in the market, but it certainly has some unique design ideas.
Thanks so much. I think the Mill is interesting - it's on my (very long!) list of architectures to write about (possibly 2026!?). I do think RISC-V will make it harder and harder for new architectures to get traction - a bit like Linux and operating systems - unless they give demonstrably better performance in a new area like machine learning (like the TPU etc).
That makes a lot of sense, as I guess most of the benefits of an architecture are that it's widely used and supported—not that it's technically superior.
I don't think it would only find success in new areas, because if it's significantly faster it would be great for HPC (where they already don't use standard ISAs), but I could also see it in an ML chip like you mentioned.
> My best guess then is that RISC-V isn’t the last ISA. But it will be the ancestor of all future ISAs.
Very late comment :-)
Whatever instructions you add, as long as the machine can run RV32I/RV64I User mode code (or perhaps E rather than I) then it *is* RISC-V. All other extensions are strictly optional, the standard privileged architecture is explicitly just one of many possible privileged architectures.
So the question is more whether someone else's profile (set of extensions) becomes popular instead of the official profiles (RVA23 etc).
Not that RV32I/RV64I is perfect. I have several things I'd change if it could be done over.
One is that I think `slt{u}{i}` should produce an all-0s or all-1s result, not 0 or 1 like the C '<' operator. Most uses are consumed locally by code that only cares whether the result is 0 or not, wanting a mask is the 2nd most common use, and needing to store an actual 0 or 1 in RAM or as a function result is quite rare. Converting between the two forms is only one instruction (subtract from the ZERO register) but the case where you're doing it in a hot loop is usually the masking use.
Obviously this is not worth forking the world over.
I also think most of the OP-IMM instructions don't earn their keep in terms of opcode space used -- each one uses 4M code points, 1/256th of the 4 byte opcode space. Only `addi` is really needed, `slti`, `sltiu`, `andi`, `ori`, `xori` are used very rarely, much less than one instruction in 256, and can easily be replaced by a two instruction sequence using a temporary register. Only `sltiu rd, rs, 1` is used fairly frequently to implement `seqz rd, rs`, the other 4095 immediate values are rare. Providing `seq rd,rs1,rs2` and `sne rd,rs1,rs2` would make more sense, operations that currently need a two instruction `sub;s{eq,ne}z`. Also relatively common is `andi` with a small value, especially 1, which is covered by `c.andi`, or `xori` with -1, which is now covered by Zbb's `orn` or `xnor` with the Zero register as the non-inverted input.
The shifts `slli`, `srli`, `srai` are used much more often and also use only 32k (RV32) or 64k (RV64) code points each. But even then almost all uses have either `rd = rs1`, so the C extension instruction can be used, or else if there is a different `rd` fall under the Zba extension's `sh1add`, `sh2add`, `sh3add`.
So, yeah, with hindsight 5*4M + 3*64k = 21,168,128 code points (1.97% of the opcode space) could be painlessly removed from RV64I and replaced with 2*32k code points for `seq` and `sne` register-to-register instructions.
For reference, that is 40% of the opcode space used by the largest ISA extension there has been to date -- or probably will ever be -- the Vector extension, which had to make some encoding sacrifices to shoehorn it into an acceptable number of code points.
Most extensions add only a handful of register-to-register instructions at 32k code points each. Not having `slti`, `sltiu`, `andi`, `ori`, `xori` would give room for 640 such new instructions.
A bit more frugality in RV64I could have made finding opcode space for future extensions considerably easier.
But, again, not worth forking the world over at this point.
Interesting article, however... by paragraph eight I was practically screaming in my head "Have you never heard of quantum computing?!"
Talk about a radically new future computing paradigm that's guaranteed to be the Genesis of a raft of new ISA's.
In fact I'm thinking this will start the cycle all over again with each player creating a new ISA that will fight it out in the marketplace with the others until they're whittled down to less than a handful.
Who knows. By then we may be working on the next thing beyond that and starting the cycle all over again.
Hi, You're right but I had quantum in the category of accelerators like GPUs. Is it really a replacement for the general purpose von-Neumann CPU? Interested to hear your thoughts!
Not right now, no. But in the future who knows? I'd be surprised if quantum computer development doesn't continually push quantum computing into more and more areas of traditional computing.
I'm not sure I'd eliminate GPU's either since they are full fledged CPU's in their own right, albeit with a design skewed towards floating point and vector math performance.
Your overall idea is interesting, but I don't think we're there yet, or that RISC-V will be that final ISA. don't get me wrong, I'm a huge fan of RISC-V, I just don't see it as the final ISA. I think we're more likely to see a future with an open standard that software can be written to and each CPU architecture translates or recompiles to native. Think POSIX meets OpenCL, meets Java bytecode, meets transmeta, meets JIT.