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

141–150 of 467 posts

Re: RISC-V: They Should Have Known Better

#141

Post by monocasa »

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…

I said easily less than half a pipeline not a full stage. Everything kind of shifts around a bit because of that, and it ends up being a pretty different design than a fixed width front end because of it (hence qualcomm's objections), but it's not clearly worse.

And for better than aarch64 density, it seems to make a lot of sense.

Re: RISC-V: They Should Have Known Better

#142

Post by phire »

monocasa wrote: post #134
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…

There's a huge difference between 2/4 byte variable density and 1-15 byte variable density. And as I've said in other places, my experiments showed that it ended up being kind of across the board less than half a pipeline stage to handle C instructions, kind of orthogonally to decode width. It is a different front end design, so that's why Qualcomm didn't want to reengineer their aarch64 core more than they had to, b…

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 encoding space set aside for 6 bytes, 8 bytes, 10 bytes and all the way up to 24 bytes (which is overkill). If it's already paying the variable length tax, it should be making better use of it. IMO, a 2, 4, 6, 8, 10... byte scheme should be able to massively improve on x86's code density.

Re: RISC-V: They Should Have Known Better

#143

Post by monocasa »

dmitrygr wrote: post #140
monocasa wrote: post #139

Earlier quoted context omitted.

> You do realize that Linux got basic SMP support 3 years after NT? Linux started about three years after NT did. And NT could only support 64 processors for a long time when Linux could support thousands. > It still does not have reliable sleep-wake. Neither does NT really. Both depend on ACPI for the systems you're talking about, and it's the platform interface that's ultimately fucked. > And it only added native a…

We shall see :) When my iPhone or laptop is no longer running aarch64, i'll happily admit i had been wrong

I mean, Apple is different from pretty much every other manufacturer here. They collborated in the design of aarch64, and a rumored to own a lot of the base IP themselves which they've cross licensed with ARM. It's very close to AMD:Intel::Apple:ARM when it comes to aarch64. That heavily changes the licensing costs. My point isn't that RISC-V is markedly better, but instead that it's equivalent from a perf achievable from in the same nexus of PPA and NRE effort. So there's no reason for Apple to take the pain of a leap with no real gain, but NRE losses.

I would expect to see RISC-V Android phones (probably initially out of China, despite ARM China) within the next few years. They've been busy bees since RVA23 was ratified with a bunch of Chinese companies making changes to optimize AOSP for RVA23. I've also heard on the grapevine that NT already has a RISC-V port internally, but take that with whatever grain of salt you feel like. But Microsoft has already been contributing to the RISC-V specs (they contributed to Ztso for instance).

Re: RISC-V: They Should Have Known Better

#144

Post by phire »

IshKebab wrote: post #36
NetMageSCW wrote: post #30

Earlier quoted context omitted.

I don’t think making optional what optional features are available is a little mistake. It is a torpedo to the waterline.

It's not. In practice you have two scenarios: 1. You have a microcontroller. You're compiling code yourself and the docs tells you what features are available and which compiler flags to use. 2. You are writing application code. In that case you simply target RVA23. The edge case is the same edge case where you use CPUID on x86, I.e. you want to target say RVA23 and RVA28 in the same binary. In that case you do have…

Don't forget:

3. You are writing a kernel, with large amounts of inline assembly

4. You are writing a compiler, either offline or online

5. You are writing embeddable blobs that don't know what platform they will be running on.

6. You are designing a RISC-V core, and need to decide which extensions you should be supporting for your intended use-case.

Re: RISC-V: They Should Have Known Better

#145

Post by atomicUpdate »

It’s kind of funny that all of the complaints about optionality apply equally to Vulkan. Google even created the same profile solution with “Android Vulkan Profiles (AVP)”.

I suspect Vulkan suffers from the same design by committee problem, which similarly caused it to miss seemingly basic features in the base spec that then need to be filled in with extensions and also made it too difficult for developers to want to move too.

Re: RISC-V: They Should Have Known Better

#146

Post by monocasa »

phire wrote: post #142
monocasa wrote: post #134

Earlier quoted context omitted.

There's a huge difference between 2/4 byte variable density and 1-15 byte variable density. And as I've said in other places, my experiments showed that it ended up being kind of across the board less than half a pipeline stage to handle C instructions, kind of orthogonally to decode width. It is a different front end design, so that's why Qualcomm didn't want to reengineer their aarch64 core more than they had to, b…

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 why should RISC-V limit itself to just 16-bit/32-bit? It has the encoding space set aside for 6 bytes, 8 bytes, 10 bytes and all the way up to 24 bytes (which is overkill). If it's already paying the variable length tax, it should be making better use of it. IMO, a 2, 4, 6, 8, 10... byte scheme should be able to massively improve on x86's code density.

There's nonlinear issues as you add more options. 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. Hence x86's splitting into essentially multiple front end banks in modern designs, and even then typically only has one decoder per bank that can decode everything, and even that takes multiple cycles for some instruction sequences, even just to discover the length.

The larger lengths in the RISC-V spec are more targeted towards bespoke stuff like GPGPU that's maxing out issuing a single instruction per instruction stream anyway. When you look at shader machine code, it's clear density was essentially an afterthought, but they love them some 64bit wide instructions. Which unsurprisingly is pretty much the same width of vertical microcode in archs that still do such a thing.

Re: RISC-V: They Should Have Known Better

#148

Post by ngl999 »

d-us-vb wrote: post #61
Joel_Mckay wrote: post #34

Earlier quoted context omitted.

Some are already on RVA23.1 even before the standard made it to more than 4 manufacturers product lines. The meme joke about standards is sadly relevant for riscv. =3 https://xkcd.com/927/

As I’ve come to understand it, standards simplify intensionally, not extensionally. For those who select a part that is compliant with a standard, more standards to choose from is better because engineers are able to make better tradeoffs; they’re not forced to select a part that does way more than the application needs thus making the product more expensive if there are lots of “competing” standards: some do less so…

That is given, vendors actually _know_ what exact practical applications they are building for.

Re: RISC-V: They Should Have Known Better

#149

Post by brucehoult »

zephen wrote: post #54
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…

> RISC-V is... fine Exactly. > It satisfies my two requirements for an ISA as a hobby CPU designer... You probably have some unstated requirements as well, such as available toolchains and "vetted well enough to actually be able to run code." Risc-V now occupies the Schelling point for people who, for whatever reason (rent-seeking and security top the list) want to leave the x86 and Arm ecosystems.

Luke is too modest. Something in the region of 5 million chips containing his hobby CPU have shipped since launch on August 8, 2024.

Re: RISC-V: They Should Have Known Better

#150

Post by lowbloodsugar »

kjs3 wrote: post #90
lowbloodsugar wrote: post #77

Earlier quoted context omitted.

>You learned it in the 70s [emphasis mine] I really don't know anything about this space, but you just said that 8051 is dominant because it has one dominant architecture since the 70s. It has hundreds of manufacturers making identical parts. As you say, software matters. If the Software can't run because of hundreds of extensions that can't be checked for, then you're going to pick a target that works, no? So in fac…

I really don't know anything about this space And yet you couldn't help yourself... but you just said that 8051 is dominant I said absolutely no such thing. If the Software can't run because of hundreds of extensions The software in the x86 world runs because there aren't hundreds of mutually incompatible extensions. I think the last time there was a major completely incompatible x86 ISA divergence was AMD "3DNow" vs…

Yeah, I completely misinterpreted you post. Apologies.
Post reply on HN