How close is RISC-V to RISC-I? (2017)

> Does COND mean the jump is conditional, like JMPR EQ?

Yes. The better generic description would have been Branch with register + offset but the RISC-I specific language uses "Jump" for everything.

To minimize the number of instructions for some finite set of nontrivial programs, you define the instruction set to have one instruction that performs each of the programs. Then each of those programs is one instruction long. (Other programs may or may not be possible to encode at all.)

If the set of nontrivial programs is infinite, the situation is more complex, because an instruction set as normally defined is finite. Also, you can't equally weight every program from an infinite set, so you need some kind of weighting function among the programs. Which instruction set is ideal for encoding this infinite set of programs depends almost entirely on what that weighting function is. In fact, you can usually derive the optimal instruction set directly from the weighting function. Which is to say, when you design the weighting function, you are more or less designing the instruction set.

As retrac points out, it comes down to a question of tradeoffs. There's no objectively optimal answer to which tradeoffs you should prefer.

I took some notes some years ago on the subject of dense instruction sets, optimized for the number of bits to encode programs rather than the number of instructions; perhaps you will find them of interest: https://dercuano.github.io/notes/tiny-interpreters-for-micro...

Ideal in what regard? Easy to code for humans or generate for compilers? Code size or decoding simlicity? Parallelism or cache friendliness? Energy efficiency or low cpi? Flexibility? Future-proofness or backward compatibility? In theory you only need one instruction (subleq), everything else is a highly narrow optimization attempt.

I remember a lot of work in this area in the late 80s before RISC really took off.

If you search for "frequency analysis of instruction sets" in Google Scholar you should find something.

CPUs are general purpose computers. "An idea set of instructions" depends on what you're designing for. If you already know what you're computing, you design an ASIC.

Many have tried to derive an optimal instruction set, and RISC-V is such an attempt. But for now trying is failing, and one can only chose the way one will fail. With the possible exception of only the Mill architecture, but that architecture requires a grand scale.

One common bottleneck, orienting instruction set design, is the need to pull in constants (indeed the instructions themselves are). One could theoretically share them between functions, and think of smart ways to reduce the amount of code. But in practice this is futile, as the modern CPU is a race car on a highway, if not a train on rails, so it can't be bothered to stop and deal with that kind of smartness. There's just to much inertia behind you... once you approach the speed of light. The road itself should have all information needed to let the CPU drive the correct track. And no special cases.

In addition, almost all CPU's are designed to execute a C type machine abstraction, because that's the paradigm. Though I root for the Mill, my guess is we'll only see a different instruction set once the paradigm shifts towards another execution model, likely one that is less stack bound.

In terms of length and density at least, the optimal solution is something like compression with Huffman coding, as it is fundamentally a compression question, where we want to represent the most frequent operations and operands with the fewest bits, on average. As with any question of compression, the optimal format will depend on the nature of the compressed data. So at least in that domain, there is no truly ideal solution, only approximately ideal solutions. (The approximately ideal solution is quite good though -- in practice Huffman-encoded instructions for stack machines with a rich operation set based on an average instruction mix, come around 4 bits per instruction on average, IIRC. I've seen the approach used with a VM interpreter on a memory-constrained embedded system to pack in more code.) I suspect the same is true of other criteria you might select for what makes an ideal instruction set; it's always going to be some compromising trade-offs, some of which depend on runtime properties like actual instruction mix.

A related question is that of code density, but that depends on more factors than just on which raw arithmetic or bitwise ops you have available. For instance, having a greater number of registers can be a benefit for some algorithms. Then, how many bits are used to encode each instruction.

There have been studies comparing code-density of common algorithms compiled to or hand-optimised for different instruction sets. For instance: <https://web.eece.maine.edu/~vweaver/papers/iccd09/ll_documen...>

In general, the top densest have been 2-address CISC ISAs such as Motorola 680x0 and x86 variants, followed by 2-address RISC for embedded processors such as Super-H, ARM Thumb and RISC-V's C-extension.

There's the issue of integers overflow, on Rust they're only detected in debug mode not in release mode.

The MIPS had 'trap on overflow ' integer arithmetic instructions but sadly the RISC-V doesn't have those..