This and exactly this. If there is anything I learned in the past 15 to 20 years, I doubt it will be any different. The mentality of development is just different.
I want the iteration of the product that is in its 2nd or 3rd official iteration. Where you have a lot of learning done and battle tested. Preferably without the backward compatibility to create something truly beautiful. Would it be perfect? Of course not. But it will be Great.
I so wish ARM had some counter offering. They might as well give away their their low end design for free.
Considering just how many of the problems seem to come from RISC-V being a clean-sheet design, I suspect we would be better off not doing another.
What I am interested in is the idea doing an AArch64 style revamp of the ISA, were much of the non-encoding semantic stuff is kept, but the entire instruction encoding (plus all the CSRs, and other things) are reworked to be sane.
You might even do two reworkings in parallel, with one variable-width encoding optimised for microcontrollers, thumb-style; And the other being a fixed-width encoding optimised for wide out-of-order cores.
And at the same time, you make a bunch of extensions mandatory, and unify others into bigger chunks; Code compiled to one of these two encodings would know it had access to a much wider range of instructions.
The idea would be that any C code targeting RISC-V can be compiled to this encoding with close to zero changes, and that mechanical translation of exiting RISC-V binary code should be "possible", as none of the underlying semantics have changed. And the same would help any core wanting to natively support both (or all three) encodings, you would only need a front-end translator.
I feel like that's largely mitigated by profiles. RVA23 is really looking like it'll be the modern base target used for high performance application processors and it makes mandatory pretty much everything you'd want for those use cases, and other comments by people familiar with designing RISC-V CPUs mention that the variable length encoding can be dealt with in a very simple manner that doesn't even add another pipeline stage so it doesn't seem like it's all that big of a deal while also bringing in benefits in code size reduction. Not everyone is adopting it, but several major players have set the stage by mandating it.
This and exactly this. If there is anything I learned in the past 15 to 20 years, I doubt it will be any different. The mentality of development is just different.
I want the iteration of the product that is in its 2nd or 3rd official iteration. Where you have a lot of learning done and battle tested. Preferably without the backward compatibility to create something truly beautiful. Would it be perfect? Of course not. But it will be Great.
I so wish ARM had some counter offering. They might as well give away their their low end design for free.
Considering just how many of the problems seem to come from RISC-V being a clean-sheet design, I suspect we would be better off not doing another.
What I am interested in is the idea doing an AArch64 style revamp of the ISA, were much of the non-encoding semantic stuff is kept, but the entire instruction encoding (plus all the CSRs, and other things) are reworked to be sane.
You might even do two reworkings in parallel, with one variable-width encoding optimised for microcontrollers, thumb-style; And the other being a fixed-width encoding optimised for wide out-of-order cores.
And at the same time, you make a bunch of extensions mandatory, and unify others into bigger chunks; Code compiled to one of these two encodings would know it had access to a much wider range of instructions.
The idea would be that any C code targeting RISC-V can be compiled to this encoding with close to zero changes, and that mechanical translation of exiting RISC-V binary code should be "possible", as none of the underlying semantics have changed. And the same would help any core wanting to natively support both (or all three) encodings, you would only need a front-end translator.
I feel like that's largely mitigated by profiles. RVA23 is really looking like it'll be the modern base target used for high performance application processors and it makes mandatory pretty much everything you'd want for those use cases, and other comments by people familiar with designing RISC-V CPUs mention that the variable length encoding can be dealt with in a very simple manner that doesn't even add another pipeline stage so it doesn't seem like it's all that big of a deal while also bringing in benefits in code size reduction. Not everyone is adopting it, but several major players have set the stage by mandating it.
Well, the revamp I’m suggesting would essentially be implemented as a RISC-V new profile, just with a different instruction encoding.