Hacker News Reader

Part of the idea is to create standard ways to do certain things and then hope compiler writers generation code according to that. That will allow more chip designers to take advantage of those if they want to.

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.

RISC-V is designed for very small and very large system

That's exactly the problem --- there is no one-size-fits-all when it comes to instruction set design.

There is a trade-off but there is overall far more value in having it be unified.

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.

>overall far more value in having it be unified.

>[...]

>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?

The goal is that there is a unified core that runs the majority code. The majority of ecosystem and tooling works of a common base. Lots of code can be used in a way to be very universal.

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.

Again, I ask: Unified, or something else?

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.

Not having the definition being controlled by a company, being and open specification and the whole ecosystem and tooling from the ground up being designed around a fully modular instruction set with use-case specific profiles that can evolve independently is very different then what we have now.

> 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.

I agree with the latter portion, and that's the part I like about RISC-V the most.

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.

I think overall it is amazing. I think considering everything they had to do and everything they wanted to achieve, I think they made really, really good overall choices.

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.

I do not think much of the choice on how to do math and not have flags.

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.

In the context of gmp, people write architecture-specific assembly for the inner loop anyway.

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.

If they didn't implement those benchmarks (at least in simulation, like they benchmarked everything else) before releasing the spec, then they have nothing but handwaving and wishful thinking in saying this issue can be solved by op fusion. The reality is that they optimized for 1980s-style C programming without noticing that this isn't the 1980s any more.

> and it actually makes high-performance implementations (wide superscalar) more difficult thanks to the variable width decoding.

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.

I don’t see why offsets larger than 16-bit are important. Are you implying that most fusion candidate pairs would need this? In tight inner loops why would you need large offsets?

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?

Let's assume you are right. In 5 years the organization behind RISC-V apologizes and introduces a "bignum" extension. That doesn't sound too bad.