> 2. What type of applications would benefit consumers and general computing at scale?
I'm not a expert, but this will make "SIMD" nearly everything.
In special, will allow data to be encoded as vectors and processed in batches ie: make it more than is now, and as emergent realization of the data, not as an "extra" to be added, sometimes, like actual SIMD instructions today.
This already is a thing in some rdbms/pipeline, where combine per-"row" and columnar processing is optimal.
So more in line with GPUs purpose for parallel processing? But extending the applications available for processing or utilization, currently reserved for 'ML' and 'AI' typical means as we know them today?
Sounds like a merging os CPU and GPU .. I understand the simplistic nature of that conclusion. But, only can guess at realword results.
I don't think this is correct. 128-bit RISC-V has nothing to do with SIMD, at all. It was created to future-proof RISC-V wrt. exascale distributed computing, where even a full 64-bit address space might be insufficient.
Maybe. The point is that you can encode more per unit, so you can batch more things in one go. Is not exactly SIMD as is today, but is also the same idea.
And here I was thinking 48 bits would be optimal for a lot of things. From address space to posits and instruction lengths (actually 24 is probably better there).
If there's not, it would be less than a day's work to change a few constants in a 64 bit core and add the corresponding equivalents of the same 10 instructions that were added to go from RV32I to RV64I.
Fabrice Bellard has had rv128 support in TinyEmu for some years already.
If it hadn't been done then it's not because it's in any way difficult (in emulator, FPGA, or SoC) but only that no one has needed it yet.
Well, I have a doubt that simply increasing bus size to 64 bits you can get working bitstream for FPGAs, even for top notch ones. Something tells me that synthesising/placing/routing such soft-core will face timing and resource limitations.
Studying recent ARM based SoCs I usually find that they often use reduced AXI4 buses to 48 or even less bits, making all internal I/O transactions block-wise.
A "standard" (e.g. 5 stage pipe in-order) 64 bit RISC-V core takes a very small proportion of even a fairly small FPGA such as an Arty 100T. You can even do multiple cores. 128 bit would fit no problem at all.
You'd probably have slightly lower Fmax but there's no question about working and if you actually need 128 bit arithmetic then it will be faster than using multiple instructions on a 64 bit CPU (e.g. 4 instructions for a 128 bit add).
It opens up some very interesting possibilities and optimization options that you wouldn't normally ever consider. In any case, I think programmers of most languages wouldn't even need to care as all optimizations would be done by the teams working on the compilers/interpreters/VMs.
Note that it's not just about integers, floating point would also benefit from this.
