.
An interesting article by Erik Engheim, addressing the question of whether RISC-V overdoes the minimalism. And answering in the negative, because of two features which should work better for RISC-V: Compressed Instructions and Macro-Operation Fusion

The article is here but I'm having trouble reading it. Here's an archive - I could read it if I force-stop the loading. Oh, but here's a better archive.

And here's some of the content:







via

It sounds good I wonder though how it will pan out in practice. Macro-fusion is an interesting sounding technical term. Many small instructions are already fused into a larger one. For instance, compare-and-branch in a single instruction. Or regular register indirect-with displacement addressing. If one really wants to go all out fusing instructions then these instructions should be split apart so they can be implemented as fused instructions.

Do they give any examples of macro-fused instructions? I think there are not that many instructions that would be macro-fused. Besides the obvious one of supplying indexed addressing mode, which is missing. Every example I could think of where one would want to use macro fusion, a CISC style instruction works just as well.

My impression of macro-fusion is that the instructions fused must be locked together. And if there are intermediate results maybe a virtual intermediate result register file could be used. Intermediate registers do not need to persist outside the execution of the instruction. I think they can just be pipeline registers. But then one needs a way to distinguish intermediate registers from real registers.
Suppose one wants a *b + c * d using macro fused instructions.
The a*b = e would be one instruction
c * d = f would be one instruction
e+f = g would be one instruction
Note that e, f do not need to be real registers since they are discarded anyway once the result is formed. But then why not just use the fused-dot-product instruction?

With macro fused instructions one has to worry about how much precision to carry in a register. Is that multiply going to need a double precision result or not? With a CISC style instruction that can be hidden.

Yes, there is a worked example in the article.

I don't think precision is a concern because the fused macro ops are a way to keep the machinery busy, not intended to change the semantics of the instructions which get fused.

I think one way to look at this is a late binding. The external instruction encoding should be dense, and regular, so there's not too much cache pressure, memory bandwidth, or decoder complexity. The internal instruction encoding should be wide and trivial to decode, and of course suited to the specific capability of the microarchitecture. By binding late to the encoding which drives the execution units, it's possible and highly desirable to fit the internal encoding to the microarchitecture. What's needed is a stable external encoding, for portability, but a highly specific internal encoding, to allow for low-cost or high-performance implementations.

A central idea is that RISC-V was invented for, and optimised for, execution on high performance CPUs. Earlier RISC ISAs had in mind simple pipelining, and I think I'm right in saying that both MIPS and ARM had to be adjusted to suit later higher performance implementations.

Because RISC-V is still RISC, and because it's defined as an obligatory core set with various optional extensions, it should also work well for low power, low complexity, low cost implementations. And so it's also good for teaching:
13-Year-Old, Nicholas Sharkey, Creates a RISC-V Core

I think RISC may be better defined as "Easy to Pipeline with serial memory". Registers are a side effect
rather than a feature of RISC. With all the complexity of todays RISC"s, A CSIC like a
CRAY could it give similar performace?

Without some assumed semantics more complex instructions are needed anyway. If one wants to get minimal error from a fused dot-product then a fused-dot-product instruction is required in the instruction set, because fusing simpler instructions which do not change semantics will not supply the lower error. To control the semantics of sequences of instructions that are fused would require additional instructions anyway.

The example of scaled-indexed addressing given in the article was about the only example I could think of, of fusing instructions. That is why I would like to see another example besides an address calc. The result of the example was that it was just as good as the ARM. In other words, it was not a whole lot better.

I added scaled-indexed addressing as custom instructions to a RISC-V core as a 32-bit instruction and they are just as code dense as the example and use one less register. I do not see how fusing the instructions is better, it looks to be about equivalent to me. Except that it complicates the decode with additional pattern matching and fusion to create new instructions. It probably adds a pipeline stage or more to the decode.

To get high performance (in a simple manner) one probably wants to go with a fixed size instruction. I think the ARM 64 and PowerPC are better in that regard.

One place where macro-fusion / instruction fission is useful is in isolating an instruction set from the micro-architecture that executes it. This is maybe suitable when an complex instruction set is being implemented on simpler technology.

Agreed, a multiply-accumulate or dot-product instruction is (or may be) a different thing.

I found this:
https://en.wikichip.org/wiki/macro-oper ... ion#RISC-V



(I'm not greatly in favour of the perjorative term 'bloat' but it's in the title of the paper.)

> isolating an instruction set from the micro-architecture that executes it.

Absolutely! That for me is the main drive of RISC-V. It's not an ISA for a single implementation, or for a short period, it's meant to decouple one thing which should be stable from another thing which should be flexible.

Read through the Berkley paper. RISCV is definitely an excellent ISA and approach. Having quantified research is a little better than "it looks this way or that way". Using macro-fusion as a “fix” for the lack of indexed addressing is just as good as having indexed addressing. Keeping in mind that the instruction set was designed for a wide variety of environments. It was noted that a couple of routines like memset() and memcpy() were suffering from a lack of a wide memory loads and stores compared to other architectures such as ARM and x86.

I have been wondering how to use macro fusion to get more read ports for the fused dot-product operation, which requires four source ports. Could there be an instruction whose sole purpose is to read operands? Which then would be fused to following instructions. Hmm, I wonder if a branch-to-next instruction could be used for this. Branches read two operands and do not store a result.