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

161–170 of 467 posts

Re: RISC-V: They Should Have Known Better

#161

Post by [deleted] »

Twirrim wrote: post #83
hn_submit wrote: post #44

Earlier quoted context omitted.

So you write software for a platform you know nothing about?

> So you write software for a platform you know nothing about? That's how a sizeable chunk of software is written and shipped. Runtime detection of CPU features is very much a thing, and is in fact used extensively in software you use or interact with every single day. Just as a quick example, OpenSSL's approach for x86_64 is OPENSSL_ia32cap https://docs.openssl.org/master/man3/OPENSSL_ia32cap/ This ensures (in theor…

[deleted]

Re: RISC-V: They Should Have Known Better

#162

Post by brucehoult »

dmitrygr wrote: post #113
kazinator wrote: post #104

> Say you want to store a byte to a register plus offset. What range of offsets can a [compressed] 16-bit instruction encode? Zero through three. If a compressed instruction could load or store a word to a word-scaled offset 0-3, relative to a register base address, that would be quite useful. It could be used for accesses to all structures four words or smaller.

In thumb, it can encode 0..31

And Arm dropped a T16-like encoding entirely from their 64 bit instruction set.

If they did everything exactly the same they would be the same ISA not different ISAs.

It's just as easy to point to things that RVC can do that T16 can't.

You need to look at a far larger picture to decide on who made the better decisions overall.

Re: RISC-V: They Should Have Known Better

#163

Post by phire »

monocasa wrote: post #146
phire wrote: post #142

Earlier quoted context omitted.

I agree that 16-bit/32-bit variable length would struggle to beat x86. But I suspect it could have gotten close, simply because x86 wastes a huge amount of its advantage on legacy cruft. The important point is that there is no reason why a 16-bit/32-bit encoding shouldn't have smashed Aarch64's 32-bit only code density. My secondary point, is that why should RISC-V limit itself to just 16-bit/32-bit? It has the encod…

> I agree that 16-bit/32-bit variable length would struggle to beat x86. But I suspect it could have gotten close, simply because x86 wastes a huge amount of its advantage on legacy cruft. I'm saying the opposite. Maybe some theoretical CISC-V would leave RISC-V behind, but x86(and -64) makes wild choices for instruction density, and RV64GC already clearly beats x86-64 in .text density. > My secondary point, is that…

> and RV64GC already clearly beats x86-64 in .text density.

Maybe I'm misremembering. Or maybe the numbers I'm remembering took into account the fact that most compilers unroll more aggressively on x86 than on targets they consider to be "embedded" (another pet peeve of mine)

I stand by my assessment that the code density of rv64gc (and especially rv64g) is lower than it would be if they had actually put a focus on code density.

> A 16-32 decoder is pretty simple, a 16-32-48 isn't the worse thing in the world (and a 32bit immediate might make it worth it), but you start to hit weird explosions in gate count once you go much past that.

Not sure I would say 16-32 is simple, certainly massively simpler than x86. My point is that you have already paid the tax for going variable length, and 16-32-48 isn't that much more complex. And probably worth it for 32-bit immediate/offsets.

And maybe 16-32-48-64 is worth it... Hard to tell, but I wouldn't entirely rule it out without study. The advantage would either be immediates/offsets that are too big to fit in 48 bits. Or some kind of VLIW style scheme which actually packed three 20-bit instructions into aligned 64-bit packets. (Or other mixtures of sizes like 30-30, 30-15-15, 40-20, or 15-15-15; We are talking about a complete break from RISC-V. There is a thread somewhere on HN where we brainstorm something like this).

But beyond that, no point really. Just pointing out that RISC-V reserved the space.

Maybe I need to prototype the 64-bit aligned packets idea someday, at least far enough to get instruction density numbers.

Re: RISC-V: They Should Have Known Better

#164

Post by kev009 »

jcranmer wrote: post #96
kevin_thibedeau wrote: post #62

Earlier quoted context omitted.

x86 chips don't truly exist anymore. They only use it as a compressed ISA for a more capable internal representation that can be freely updated at any time.

This is a load of bullshit that largely exists as copium to explain how x86 did the impossible and made a superscalar CISC processor. x86 is doing the same thing that (to my knowledge) all high-end processors do, yet no one tries to call out those chips as compiling to a different internal ISA. But you also don't see any chips trying to run with multiple ISA modes: the closest you get is 32-bit and 64-bit modes coexi…

I haven't kept up with POWER after POWER9, but I recall it to be a true hardwired control RISC, pure as the driven snow. This had some interesting properties (along with other clever designs like eFuses and pNOR) for creating a really credible security posture. They do have a millicode system and chicken bits for oops moments (which are kind of an opposite risk, if you don't get those right for unexpected problems).

Re: RISC-V: They Should Have Known Better

#165

Post by imtringued »

kevin_thibedeau wrote: post #62
kjs3 wrote: post #28

Earlier quoted context omitted.

I think MIPS is a great example, and even there I don't think there's the bizarre bifurcation of ISA options RISC-V brings to the table. As a fellow olderster, I can't help but think that after almost 50 years of "ISA X is sooooo much better than x86 it's obvious ISA X is the future and x86 will be dead Real Soon Now (for whatever todays version of x86 is)" I can only shake my head ruefully and say "ping me when that…

x86 chips don't truly exist anymore. They only use it as a compressed ISA for a more capable internal representation that can be freely updated at any time.

Whenever I see someone say this I'm thinking the following:

If what they say is true, then x86 won because ISA doesn't matter, precisely because ISA is the public instruction set architecture. If you can convert anything to a better representation then the argument of exposing the better representation doesn't actually follow.

Additionally, you are claiming that an internal implementation detail that only Intel and AMD know about is secretly implementing your favourite instruction set, which when you think about it, is incredibly implausible and impossible to prove. It's eerily similar to an unfalsifiable theological claim.

Then there is the silly argument that x86 chips don't exist anymore, when x86 chips have distinctive differentiating factors that make them unlike chips that implement other ISAs. The most obvious one is that x86 is primarily used in the personal computing and server space. This means the chips focus on high single threaded performance with large caches and large core counts plus swappable memory and storage devices, whereas most ARM and RISC-V devices target a completely different space, primarily embedded devices where everything is included on the PCB and there are very few external interfaces. You have to be pretty delusional that an unfalsifiable claim on an internal architectural detail of a CPU core somehow invalidates the rest of the silicon that happens to be on the same die.

I hate comments like yours because they are self defeating and require a lot of effort to debunk.

Re: RISC-V: They Should Have Known Better

#166

Post by camel-cdr »

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 compatibility between them. Obviously it would've been better, similar to if RISC-V spawned with RVA23 done, but development takes time and RISC-V International started, because people where already using RISC-V.

RISC-V also is the most DOSed ISA, with people proposing crazy stuff. Just the other day somebody proposed an instruction that would do up to 2^30 16-bit comparisons in one instruction at the largest VLEN. Because they wanted to improve their string processing usecase.

---

In my experience RVA23 matches aarch64 and x86 in uop count (without fusion), code density is better, instruction count is slightly higher. The biggest impact on the instruction count advantage of aarch64 over RVA23 is a single instruction, load-pair, which gets cracked at decode in every high-performance implementation, because it writes to to registers.

The Arm approach to code density is using multiple writeback instructions that have to be cracked and the RISC-V one is RVC. Both prohibit simple linear scaling of parallel decoding, so code density seems to have mattered to Arm enough to make the tradeoff worth it.

Re: RISC-V: They Should Have Known Better

#167

Post by imtringued »

phire wrote: post #123
monocasa wrote: post #115

> The second category for big-compute is actual desktops and SBCs that do interactive computation, browsing, gaming, and other such "desktop work". I do not expect RISC-V to be a serious player at the top of this market. Simply put, the architecture is not designed for it, as pointed out above. Additionally, this market has the margins to afford licensing a much-better-designed aarch64 core from ARM, and gain proper…

I'm not sure the gate count argument works in RISC-V's favour. While RISC-V is quite optimised for gate count for small cores; In large wide OoO cores the variable length encoding really bulks out the decoders. You basically have the same requirement as x86, where you have to attempt to decode a 32-bit instruction every 16-bits (because there is no alignment guarantee for 32-bit instructions), and then cancel out the…

I don't believe this will impact performance in practice, because nothing forces CPU vendors to implement fast compressed instructions. If compressed instructions become slower than non compressed instructions as the instruction decoders get wider, compilers will stop emitting them in the future.

Re: RISC-V: They Should Have Known Better

#168

Post by jacksons5f »

wren6991 wrote: post #43

RISC-V is... fine. It satisfies my two requirements for an ISA as a hobby CPU designer, which are: 1. Supported in mainline LLVM and GCC. 2. I can implement it without lawyers sending me a love letter. Everything else, I can fix in post. There are enough good ideas spread across the extensions that I can assemble a reasonably put-together, curated embedded ISA with competitive performance and code density that admits…

100% agree. Is it ideal? Nah. Can you launch successful products with it with only a moderate amount of headache? Yep!

Heart of our system that powers a household name devices is a RISC-V multi-hart SoC. It does quite a bit - a little bit of compute, a little bit of DSP. Definitely not the best fit, but cheap and works well enough. The buggest gap for us was the lack of the decent debugging featurea like ARM's Data Watchpoint Traces - but maybe there is an extension for that already?

Re: RISC-V: They Should Have Known Better

#169

Post by imtringued »

phire wrote: post #135
monocasa wrote: post #128

Earlier quoted context omitted.

You don't really have to have a separate decoder every 16-bits. What you have is a length decoder every 16 bits (so just a single nand gate over the first two bits versus a huge chunk of the prefix/opcode part of the decoder for x86), which then feeds into a set of muxes for the actual decoders. The actual increase in complexity ends up coming from the critical path of the stack up of length selection affecting start…

Yes... but then you are kind of wasting a pipeline stage on nothing more than length decoding. I suspect a design with a full decoder every 16-bits might actually win on everything but gate count, mostly because it can deal with variable length instructions and variable number of μops per instruction in the same step. A decoder that doesn't output a μop because it was clobbered by a previous instruction, can be handl…

Ok, so you doubled the number of decoders, how is that not significantly better than x86?

I'm not even sure you have a point with regards to it being a valid criticism. Doubling the silicon area for instruction decoding probably costs nothing, because if you have a simple decompression stage, the maximum number of decoders is already doubled in the first place, because you're hypothetically encoding twice as many instructions to begin with. If you can double the decoders in the decompression stage, you can probably get rid of a separate decoding stage altogether and thereby reduce the cost to literally nothing.

Look, it might not be obvious but in university I once had to design an ASIP and then do the floor plan with Cadence and the area of the SRAM dwarfed everything to the point where my ASIP was a tiny vertical column in-between two SRAM chips. I personally was shocked by the fact that I struggled to even find my ASIP on the floor plan, because it was maybe ten standard cells wide in-between the SRAM blocks. Like, ridiculously tiny to the point where it is hard for me to even care about the area the ASIP took up.

Re: RISC-V: They Should Have Known Better

#170

Post by imtringued »

brucehoult wrote: post #157
monocasa wrote: post #128

Earlier quoted context omitted.

You don't really have to have a separate decoder every 16-bits. What you have is a length decoder every 16 bits (so just a single nand gate over the first two bits versus a huge chunk of the prefix/opcode part of the decoder for x86), which then feeds into a set of muxes for the actual decoders. The actual increase in complexity ends up coming from the critical path of the stack up of length selection affecting start…

> you can use the same base trick behind a carry lookahead adder YESSSS. I've been pointing this out for years and years. By the point that you're looking at the same propagation delay as a common 64 bit adder you're decoding 64 chunks of 16 bits per cycle. That's 128 bytes, or a 32-64 instructions wide decoder. That is so much wider than anyone is making or contemplating — or that even makes sense given the size of…

And even if you go to those extremes, the biggest nay sayer says the cost of the design flaw will require you to double the number of decoders, which hardly sounds like a big deal to me.
Post reply on HN