Perhaps the biggest was that the comparison instruction should have had the condition being looked for in the instruction, and put the result in register 0 as a 0 or ~0 (= -1). Register renaming can then carry it through pipelines. Subsequent instructions may AND register 0 with other values, or subtract it from them, avoiding frequently mispredicted branches.
The "optional extensions" have all the useful instructions in them, but typically just a couple of the instructions in each extension would provide most of its value.
So, I don't get popcount because it's in the bitmanip extension along with 10M transistors' worth of clever stuff I don't need. Similarly, each of the other extension sets.
It would be much more useful to define slices through all the defined ones, so you get either the absolute minimum core instructions, or add just the coremost of each extension set, or a more comfortable subset of each, or half of each, spiraling outward as transistor budget grows.
The current system of fairly granular extensions, a useful base architecture, and profiles defining what extensions are guaranteed for particular application classes (eg "Unix server") is a nice compromise between extensibility and software/distro complexity.
If it is supposed to be simple, then great! Actually make it simple, instead of copying old complexities.
It isn't architecturally innovative, isn't meant to be, and isn't a good place to start if you're thinking about doing architectural innovation. A lot of people are talking up RISC-V like it'll solve every problem but there are many problems in both academia and the real world where it represents a solution.
Are you saying that instead of (or in addition to) "branch if equal", "branch if less than", etc there should be a "set if equal", "set if less than", etc? In case you are, there is a "set if less than" instruction. The floating point extension does have a "set if equal" instruction despite there not being an integer equivalent.
Alternatively if you are complaining about 1 representing True rather than ~0, I don't think that matters much from a technical POV.
The extra step to get a comparison result into a register, and another to extend it to the whole register, is an inefficiency I would prefer to leave behind.
RISC-V was designed to be a good target for a C compiler, given that's what people almost always need. Compilers frequently see code line `int x = (a > b)` and SLT is perfect for that. Compilers don't do clever masking tricks to avoid branches, in general (there are a few hard-coded tricks like divide by signed constant).
They actually do a lot of such tricks. Check out the GCC sources, for example tree-ssa-phiopt.c[1] and ifcvt.c[2]
[1] https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-ssa-p...
[2] https://github.com/gcc-mirror/gcc/blob/master/gcc/ifcvt.c
a = (b&m)|(c&~m)
That compilers fail to do clever masking tricks to avoid branches frequently results in 2x slower programs.
And your proposal - using the zero register as a flag register - breaks way more micro-optimizations (like the simple ones described in "The RISC-V Reader" book) than it allows
RISC-V doesn't have condition codes.
> The extra step to get a comparison result into a register, and another to extend it to the whole register, is an inefficiency I would prefer to leave behind.
Can you provide RISC-V assembly that demonstrates this problem? Common branching patterns in RISC-V are all a single instruction.
The core branching comparison instructions:
`a >= b` maps to `bge a, b, label`
`a = b` maps to `beq a, b, label`
`a != b` maps to `bne a, b, label`
`a < b` maps to `blt a, b, label`
Comparisons with 0 just use the x0 register and for <= and > just flip the order of the operands.
I boggle.
If I was going to change anything I'd add compare eq/ne with an immediate
Cmp rx ry rz # compare rx ry, write result to rz
Jmple rz, ra, imm # jump +- ra+imm if rz < 0
Which would avoid the use of a implicit condition register, as well as the short offsets that a combined compare+jump suffers from?
r31 = (rx<=ry)? ~0:0
pc = r31? pc + n : pc
rx &= r31
rx -= r31
I.e., actually reduced, but more powerful. (Implicit destination followed by mov is free, because of register renaming.)
Decoding the RISC-V compare-and-branch instruction is a whole project.
There is no need for an implicit destination register, just do it explicitly and you get the same result but without any magic and with more control. Register renaming can do the same job with an implicit or explicit register destination, there is no incidence on register dependencies.
> r31 = (rx<=ry)? ~0:0
Reading your first post I know that you want to use 0 and ~0 instead of the traditional 0 and 1 as the result of condition statements. I don't think that's a particularly great idea because: - there are so many places where you need 1 instead of ~0; - translating 1 into ~0 only costs one "SUB" instruction. If this feature is required for a specific domain, it's sufficient to add an extension with this feature or - more drastically - to add a macro-operation fusion step to detect this pattern.
> Decoding the RISC-V compare-and-branch instruction is a whole project.
RISC-V encoding is made to keep decoding as simple as possible. Have you ever checked the RISC-V encoding? It looks a bit confusing at the beginning to a human but if you think about the implementation, it immediately becomes clear.
In RISC-V ISA, we can criticize: the absence of a standard SIMD extension (with a big abstract vector extension instead) or the fact that some extensions require 3 read ports on the register bank instead of 2, which can make the implementation more complex. But it's trade-offs
If the cost of negating before storing got to seem excessive, a single negate-and-store-word instruction could translate, but it would be used a very great deal less than negating the 1 to make a mask.
However simple it looks to decode the thicket of compare-and-branch instructions, decoding and executing exactly one conditional branch instruction that just checks for zero will be simpler and faster.
You still have the SET family to decode, but you need them anyway.