The rationale behind the RISC-V instruction set: >>"There are no predicated or masked instructions" This is to simplify Out-Of-Order & superscalar designs:
This is why there aren't even condition codes; branches make their own comparison. (BLT src1,src2, dst etc) The dependancies in the instruction are all expressed directly in fixed locations (registers) allowing these to be reasoned about very early in the pipeline, and without having to track additional state in the reorder buffer. Predication/CMOV etc introduce additional dependancies. (I was disappointed there's no 'Select' but given everything else, it's ok, the proposed vector handle the case where you'd want it) >>"Arithmetic instructions cannot have memory source operands?"
>>"Immediate constants have odd sizes. It is not possible to include floating point immediates, which I argue would be more efficient than loading floating point constants from data memory"
>>"128-bit integers are not supported, except as pointers in 128-bit address mode" This is all a consequence of the simple RISC predominantly load-store, fixed-length 32bit instruction idea, which simplifies pipelining: the instruction decoder is trivial.
(there is a compressed 16bit instruction capability, but it's optional) classic RISC design makes it possible to produce a very simple implementation. RISC-V is designed to scale from (i)very small embedded cores to (ii)large high performance cores, or (iii)high throughput (manycore) accelerators (the latter 2 being different cases). The RISC instruction set principles have proven to work in all contexts. The choice for a pure RISC is justified as follows: In the past few decades CISC has only ever been pursued for backwards compatability with x86. Most attempts to produce something else from a clean slate adopted RISC ideals, and the only other processors that became popular were RISCs.
going all the way back to the simple case, I recall ARM first implementation was a 28000 transistor pipelined 32bit implementation whilst the contemporary 68000 was literally 68000 transistors for a non-pipelined, 16bit version; it's proven RISC can scale all the way down (even today with huge transistor counts, there is the possibility of building a manycore dataflow processor; adapteva are probably pursuing this, given their previous product and their stated intention to use RISC-V next.. the idea is to cram as many cores as possible with local memories onto a die). Another important use case is as the basis for accelerators: you just need *something* simple&complete to handle basic computation as a basis for some custom unit revolving around some extention. >>"Support for vectors is not well developed. Vector size is limited to 1024 bits"
>>"Software has to be recompiled each time a different processor with different maximum vector size becomes available
"
>>"There is no support for integer vectors, Boolean vectors, masked vector operations, broadcast, etc." take a look at the hwacha vector unit: it definitely decouples vector size from ISA, and does have prediction and so on. but it's deliberately not part of the basic standard, I think they are still finalising it? a high throughput accelerator can always be built by going manycore with attached vector units. I don't think broadcast suits them because it's designed for the vector 'lanes' to be completely independent for hiding latencies: it's more comparable to GPGPU (and the old cray vector machines) rather than x86 style SIMD. Still , after all that, mayebe someone else will eventually make a contrasting 'classic' 4-element SIMD unit extention that might suit 3d maths better (with permutes for accessing x/y/z/w, a dot-product across the lanes etc.). But from what I can gather the hwacha unit is easier to compile general purpose code for. >>"long int can be 32 or 64 bits. There is no standardized way of specifying 64-bit and 128-bit integers. This inconsistency is causing annoying compatibility problems today which need to be fixed in any new ABI.
"
I think they have an unusual intention to scale to 128bit for future data centres, although I don't know what they'd do about that. All in all I'm a fan of the RISC-V decisions. The whole thing reminds me of MIPS which was a great ISA. I do like the idea of a unified register file, however at some point for creating a standard you have to draw a line. the advantages of separate files are in instruction length, they only need 5bits rather than 6, and of course implementations could physically move those register files closer to their units respective execution units |