Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RISC-V: They Should Have Known Better

dmitry.gr

Post reply on HN
Print view View original

341–350 of 467 posts

Re: RISC-V: They Should Have Known Better

#341

Post by brucehoult »

boredatoms wrote: post #266
brucehoult wrote: post #153

Earlier quoted context omitted.

Ubuntu 24.04 LTS exists and needs only RV64GC and will be supported and enhanced for many more years. Debian has no plans to require more than RV64GC. RVA23 is a very good thing in certain markets, but nothing forces you to support it for a personal project.

I cant see debian remaining on rv64gc later on when enough rva23 boards are purchasable

Why? It'll still run fine.

Just like Debian still runs on original x86-64-v1 from 1999, not x86-64-v3 (needs AVX2,FMA, BMI1, BMI2, LZCNT) or even x86-64-v3 (needs AVX-512).

Similarly, Debian for arm64 still requires only ARMv8.0-A from 2011 not even ARMv8.2-A (everything from A75/A55 to A78/N1/V1) let alone ARMv9-A (A710, A510, X2 and on).

Why would they do in the RISC-V world what they totally haven't done in amd64 or arm64?

Re: RISC-V: They Should Have Known Better

#342

Post by dzaima »

dmitrygr wrote: post #331
dzaima wrote: post #7

Random minor-ish notes: - A big problem with extension detection RISC-V has is that there's no central authority mandating vendors to not overlap things (obviously, given RISC-V being an open standard), so basic bitmasks for supported extensions is generally rather problematic (and of course even if you collected a standardized bitmask of all extensions from all vendors, it'd grow quite massive quite quickly); you'd…

> many, if not the vast majority, of aarch64 TBZ/TBNZ are probably branching on a boolean None are. There is CBZ/CBNZ for that. https://www.scs.stanford.edu/~zyedidia/arm64/cbnz.html It is just THAT useful to branch in a bit.

Both clang and gcc do actually generate TBZ/TBNZ for checking a bool: https://godbolt.org/z/K6evhaxGT

Re: RISC-V: They Should Have Known Better

#343

Post by Permik »

phire wrote: post #335
wk_end wrote: post #245

Earlier quoted context omitted.

The RISC-V specs insist that this is important for simplifying high performance designs, because a flag register is a single piece of shared state that instructions are constantly (and often inadvertently!) touching. This necessarily introduces hazards and serialization. I don’t know enough about high performance microarchitecture design to evaluate that argument confidently, but it seems to make sense to me.

I don't agree with the argument. By the time you have an out-of-order core, there is already so much shared state you have to synchronise, and you have a bunch of complex mechanisms for dealing with it. Adding a flags register doesn't really add any more complexity, it's just a small bit of extra state attached to it. And we already have the solution, it's register renaming. We are already renaming all the GPRs and F…

  By the time you have an out-of-order core
You're thinking too high level and high performance/high power use -- think about minimal embedded controllers, no need to add the complexity of O3 exe, but there's still the possibility of getting to optimize the hazards and execution without the shared state.

Doing the deliberate choice of leaving flags out of the core and then using them in the fp ops ext will nudge designers towards "this is probably the point you should think about out-of-order execution"

Re: RISC-V: They Should Have Known Better

#344

Post by phire »

camel-cdr wrote: post #180
phire wrote: post #129

Earlier quoted context omitted.

The fact that it's only "competitive" with aarch64's code density is a solid black mark against RISC-V. The only reason it's "competitive" is the compressed instructions, which means it's paying all the costs of variable length instructions, yet only getting marginal benefits. IMO a modern ISA taking advantage of variable length instructions should be able to absolutely smash the code density of a fixed width ISA lik…

> The fact that it's only "competitive" with aarch64's code density is a solid black mark against RISC-V. Arm uses complex instructions with multiple writeback, that require cracking, to improve code density. RISC-V uses a variable length encoding to improve code density. Both have anaougus decoding complexity, but RISC-V achieves higher code density, while impacting the cost of things before decode (how much, idk).

But imagine the code density you could get combining both strategies.

> Arm uses complex instructions with multiple writeback, that require cracking, to improve code density.

While smaller cores have the option of cracking the multiple writeback instructions, many arm cores just pay the extra cost of having a 3 read, 2 write register file, so they aren’t actually cracking those instructions.

They do crack other instructions.

But the cracking seems to be more about ALU limitations (aarch64 has instructions that can do both a shift of any width and an add, but the ALUs might not support this, or only support smaller shifts of 1-3 bits (useful for addressing)

What this means is that despite the cracking, each μop in an aarch64 core is quite a bit more powerful than a typical RISC-V instruction (especially compressed instructions).

So to be competitive on backend performance, a high performance RISC-V is going to spend a lot of resources post-decode doing massive amounts of instruction fusion to try to get μops of similar capabilities to aarch64 (or just settle for simpler μops, and pay scheduling costs of more μops)

So the costs of the RISC-V compressed instruction approach aren’t just limited to pre-decode.

Re: RISC-V: They Should Have Known Better

#345

Post by phire »

acutelittlebox wrote: post #172
phire wrote: post #97

Earlier quoted context omitted.

Considering just how many of the problems seem to come from RISC-V being a clean-sheet design, I suspect we would be better off not doing another. What I am interested in is the idea doing an AArch64 style revamp of the ISA, were much of the non-encoding semantic stuff is kept, but the entire instruction encoding (plus all the CSRs, and other things) are reworked to be sane. You might even do two reworkings in parall…

I feel like that's largely mitigated by profiles. RVA23 is really looking like it'll be the modern base target used for high performance application processors and it makes mandatory pretty much everything you'd want for those use cases, and other comments by people familiar with designing RISC-V CPUs mention that the variable length encoding can be dealt with in a very simple manner that doesn't even add another pip…

Well, the revamp I’m suggesting would essentially be implemented as a RISC-V new profile, just with a different instruction encoding.

Re: RISC-V: They Should Have Known Better

#346

Post by jurgenburgen »

pseudohadamard wrote: post #315
adrian_b wrote: post #238

Earlier quoted context omitted.

Designing a good 64-bit ISA, much better than RISC-V, is easy. There are thousands of people who could design such an ISA in a couple of weeks, without any AI assistance. The hard part, which has always been the moat of RISC-V, is writing all the required support software for a new ISA, i.e. all the utilities from binutils (assembler, static linker, ELF/DWARF utilities), compiler backends at least for gcc and llvm, d…

That's why I've never understood the point of RISC-V. Anyone can design a (reasonably OK) ISA. It's everything else that's the hard part. It's like announcing a new house, it's going to be pained Benjamin Moore Yellow Oxide and everything else is someone else's problem to sort out. Success! We've got a new house! The only argument I've ever seen for RISC-V that's vaguely logical is that there's no licensing to Arm in…

> The only argument I've ever seen for RISC-V that's vaguely logical is that there's no licensing to Arm involved, but since I can get M0/M3 devices for a dollar or so with infinite tool and library support that's something that's totally irrelevant for most users.

How expensive is it to license the instruction set so you can expand it?

Re: RISC-V: They Should Have Known Better

#347

Post by jurgenburgen »

pavlov wrote: post #220
inigyou wrote: post #68

Earlier quoted context omitted.

Has it been proven that no patent troll holds a patent covering RISC-V? Of course not because that's impossible to prove.

Patents only last 20 years. If you build your architecture on ideas that are documented to be older than twenty years, it greatly reduces the risk that a patent holder comes from nowhere: even if they did have the patent, it would have expired.

How quickly does the industry move? Would there be any value in a 2006-era instruction set? How would you even start making sure you didn’t infringe on any patents that came after 2006?

Re: RISC-V: They Should Have Known Better

#348

Post by camel-cdr »

NooneAtAll3 wrote: post #325
camel-cdr wrote: post #171

My disagreement with the article is mostly the following: RISC-V is not an ISA, but an ISA generation framework. If RISC-V would've standardized aarch64 1-to-1, the end result would've still been a huge extension mess, because a lot of people (RVI member) have different requirements and a very happy to build their own subsets, which would then be upstreamed because multiple vendors want the same subsets and compatibi…

wdym by "gets cracked at decode"?

The decoder decodes them into two or more internal instructions (uops).

Take for example a post increment load, which does a=mem[b++], notice how this writes to two registers. Handeling two writes (up to 4) would explode the stage after decode (rename). So high performance arm implementations generate two uops for this. But since the number of decoders is fixed and the number of rename slots as well, you now have alnost the same problem as in RISC-V with compressed instructions: the nth input to the rename stage can come from a variaty of outputs of the decode stage, so you need a large shuffle network, and propagate the uop counts from start to end.

Cracking is a lot cheaper, if you can do it later in the pipeline. E.g. the cheapest is if you can simply "replay" the instruction. That is, instead of removing the entry from the issue queue, when it starts executing, you decrement a counter and keep the entry to do something else next. But as I mentioned that doesn't really work with multiple write back.

Re: RISC-V: They Should Have Known Better

#349

Post by camel-cdr »

phire wrote: post #344
camel-cdr wrote: post #180

Earlier quoted context omitted.

> The fact that it's only "competitive" with aarch64's code density is a solid black mark against RISC-V. Arm uses complex instructions with multiple writeback, that require cracking, to improve code density. RISC-V uses a variable length encoding to improve code density. Both have anaougus decoding complexity, but RISC-V achieves higher code density, while impacting the cost of things before decode (how much, idk).

But imagine the code density you could get combining both strategies. > Arm uses complex instructions with multiple writeback, that require cracking, to improve code density. While smaller cores have the option of cracking the multiple writeback instructions, many arm cores just pay the extra cost of having a 3 read, 2 write register file, so they aren’t actually cracking those instructions. They do crack other instr…

> While smaller cores have the option of cracking the multiple writeback instructions, many arm cores just pay the extra cost of having a 3 read, 2 write register file, so they aren’t actually cracking those instructions.

No, every high performance core I know of cracks them at decode, some re-fuse some of them after rename (Apple). Because otherwise you would need to rename up to 4 destinations per rename slot, effectively 4xing your already limiting rename stage.

Cracking other stuff later in the pipeline isn't expensive.

Re: RISC-V: They Should Have Known Better

#350

Post by ksec »

dmitrygr wrote: post #64
UncleOxidant wrote: post #63

Is there a RISC-VI in the works where they try to learn from the RISC-V mistakes to make improvements?

Given the amount of learning that could have been done before RISC-V and wasn’t, I wouldn’t have such high hopes.

This and exactly this. If there is anything I learned in the past 15 to 20 years, I doubt it will be any different. The mentality of development is just different.

I want the iteration of the product that is in its 2nd or 3rd official iteration. Where you have a lot of learning done and battle tested. Preferably without the backward compatibility to create something truly beautiful. Would it be perfect? Of course not. But it will be Great.

I so wish ARM had some counter offering. They might as well give away their their low end design for free.

Post reply on HN