That allows more flexibility for CPU designs to optimize transistor count vs speed vs energy consumption.
This guy clearly did not look at the stated rationale for the design decisions of RISC-V.
Beyond that, compressed instructions are not a 1:1 substitute for more complex instructions, because a pair of compressed instructions cannot have any fields that cross the 16-bit boundary. This means you can't recover things like larger load/store offsets.
Additionally, you can't discard architectural state changes due to the first instruction. If you want to fuse an address computation with a load, you still have to write the new address to the register destination of the address computation. If you want to perform clever fusion for carry propagation, you still have to perform all of the GPR writes. This is work that a more complex instruction simply wouldn't have to perform, and again it complicates a high performance implementation.
Besides that, you raise good points on sources of complexity. I’m waiting for the benchmarks once such developments have been incorporated. Everything else is guesswork.
They spent a lot of time and effort on making sure the decoding pretty good and useful for high performance implementations.
RISC-V is designed for very small and very large system. At some point some tradeoffs need to be made but these are very reasonable and most of the time no a huge problem.
For the really specialized cases where you simply can't live with those extra instruction, those will be added to the standard and then some profiles will include them and others not. If those instructions are really as vital as those that want them claim, they will find their way into many profiles.
Saying RISC-V is 'terrible' because of those choices is not fair way of evaluating it.
That's exactly the problem --- there is no one-size-fits-all when it comes to instruction set design.
The trade-offs are mostly very small or non existent once you consider the standard extensions that different use cases will have.
Overall having a unified open instruction set is far better then hand designing many different instruction sets just to get marginal improvement. Some really extreme application might require that, but for the most part the whole indsutry could do just fine with RISC-V. Both on the low and on the high end, and in fact better then most of the alternative all things considered.
If integer checking is really the be all end all and without it RISC-V can not be successful without it, it will be added and it will be pulled into all the profiles. If it is not actually that relevant then it wont. If it is very useful for some verticals and not others, it will be in those profiles and not in others.
>[...]
>If integer checking is really the be all end all and without it RISC-V can not be successful without it, it will be added and it will be pulled into all the profiles. If it is not actually that relevant then it wont. If it is very useful for some verticals and not others, it will be in those profiles and not in others.
So which is it? Unified or something else?
Some verticals that will be special like deep embedded will likely be different enough that it will be slightly different, but it still profits from all the work going into the overall ecosystem.
RISC-V allows 'the market' to decide between uniformity and specialty in a orthogonal way. My bet is that this will actually lead to a lot of uniformity in most verticals.
Having a "majority" isn't really different from what we have now, and it includes the downside of a more robust monoculture.
And to be clear here, I'm not anti RISC-V. I am very highly skeptical, given how frequently we see things like code size critics responded to with 'but it will be faster', which isn't really an answer,
The same thing happened here. Hand wavy "the market" and "orthogonal way" doesn't communicate anything meaningful, and or worth some clear downsides at present.
Finally, "the goal" is really "a goal or vision" as expressed by proponents. It's not really one in the objective sense.
> Finally, "the goal" is really "a goal or vision" as expressed by proponents. It's not really one in the objective sense.
No idea what that means.
I don't know if it will be faster, frankly I don't care if its slightly slower, even if I don't really think that will be the case. An open ISA allows for real open chips and finally making real progress in that direction in terms of openness.
Just wish some of the choices were made differently. Open could be open and amazing. We are likely to get open with a bit of hobbling built in early on, and that makes me wonder.
This discussion is much improved over the initial, "unified, but..." one we started with.
There are some things here and there one can argue, depending on what one considers the main usecase. Overall I think starting with a very small base makes a lot of sense.
In fact they actually went to large in some places and that's why they have been working on a profile that is considerably smaller, less registers and floats in int register standards.
Given that this was made by a small group of students and one professor I think its remarkable and innovative.
We will see over time.
My preference is a hybrid. There are ops we know will repeat a lot. Targeting those with efficient, small instructions will be a win over this every time.
I expect to see that done.
Sing the tool chains all come up as a good thing though. We're heading into interesting times.
More difficult than x86? We're talking about a damn simple variable width decoding here.
I could imagine RISC-V with C extension being more tricky than 64-bit ARM. Maybe.
> and again it complicates a high performance implementation.
But so much of the rationale behind the design of RISC-V is to simplify high performance implementation in other ways. So the big question is what the net effect is.
The other big question is if extensions will be added to optimise for desktop/server workloads by the time RISC-V CPUs penetrate that market significantly.
Of course you discard architectural state changes in fusion. If I have a bunch of instructions which end up reading from memory into register x10, then I can fuse with all previous instructions which wrote into x10, as their results get clobbered anyway.
Disclaimer: I may have misunderstood the point you made. However you don’t seem to make it clear how fusion is bad for performance.
What performance tricks are you giving up by doing fusion?
> I have heard that Risc V proponents say that these problems are known and could be fixed by having the hardware fuse dependent instructions. Perhaps that could lessen the instruction set shortcomings, but will it fix the 3x worse performance for cases like the one outlined here?
Macro-fusion can to some extent offset the weak instruction set, but you're never going to get a multiple integer multiplier speedup out of it given the complexity of inter-op architectural state changes that have to be preserved, and instruction boundary limitations involved; it's never going to offset a 3x blowup in instruction count in a tight loop.
Also, it's said that x86 is bad because the instructions are then reorganized and translated inside the CPU. But it seems that you are proposing the same, the CPU that preprocessed the instructions and fuses some into a single one (the opposite that x86 does). Ad that point, it seems to me that what x86 does makes more sense: have a ton of instruction (and thus smaller programs and thus more code that can fit in cache) and split them, rather than having a ton of instructions (and waste cache space) for then the CPU to combine them into a single one (a thing that a compiler can also do).
Also don't reason with the desktop or server use case in mind, where you have TB of disk and code size doesn't matter. RISC-V is meant to be used also for embedded systems (in fact their use nowadays is only for these systems), where usually code size matter more than performance (i.e. you typically compile with -Os). In these situations more instructions means more flash space wasted, meaning you can fit less code.
An elegant architecture is easier to reason about. Compilers will make fewer wrong decisions, fewer bugs will be introduced, and fewer workarounds will need to be implemented. An architecture that's simple to reason about is an invaluable asset.
Anyway what you gain from this is a very simple ISA, which helps tool writers, those who implement hardware as well in academia for teaching and research.
How does the insanely complex x86 instructions help anyone?