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

151–160 of 467 posts

Re: RISC-V: They Should Have Known Better

#151

Post by brucehoult »

mhh__ wrote: post #65
zephen wrote: post #56

Earlier quoted context omitted.

> it's the fact that it is an open standard not encumbered by intellectual property law. There are actually many of those. But Risc-V has become, through effective marketing, the Schelling point for anybody who wants to avoid the x86 and Arm ecosystems, both for the rent-seeking behaviors you mention, and also, in some instances, for security reasons. And, as others have mentioned, the ISA doesn't really matter. As l…

The ISA not mattering I think isn't as true when you account cost e.g. in a huge OOO cpu all the fusions and so on are afaict fairly doable but if you are on a cheaper / worse CPU all those extra bytes in the instruction stream do add up.

Performance is subject to debate and quality of implementation and whether such implementations will ever be financed and made ...

But *code size* is a demonstrable fact.

RISC-V has by far the most compact code of any popular 64 bit ISA, and that was true even of RV64GC. The gap has only widened with RVA23.

Just load up your favourite OS (e.g. Ubuntu 26.04) for various ISAs in Docker and compare the `text` size of various binaries, individually or in aggregate.

In 32 bit ARMv7-M / ARMv7-A had a small code size lead over RV32IMAC, but this is reversed in modern RISC-V e.g. if you look at RISC-V Hazard3 vs Arm Cortex-M33 in the RP2350 (Raspberry Pi Pico 2) where you can trivially change one option setting in your project and recompile and test.

The only exception is that the M33 has a single-precision FPU, which neither the Hazard3 nor the Cortex-M0+ in the RP2040 have.

Re: RISC-V: They Should Have Known Better

#152

Post by brucehoult »

wren6991 wrote: post #80
mhh__ wrote: post #65

Earlier quoted context omitted.

The ISA not mattering I think isn't as true when you account cost e.g. in a huge OOO cpu all the fusions and so on are afaict fairly doable but if you are on a cheaper / worse CPU all those extra bytes in the instruction stream do add up.

The RISC-V fusion arguments from back in ~2018 didn't really pan out. A lot of those fusion opportunities are just instructions now. slli + add? Zba (sh*add). slli + srli? Zbb (zext.*). slli + srai? Believe it or not, also Zbb (sext.*). Look at that pair of RVC instructions you used instead of a single 32-bit opcode. They are: * Taking up valuable compressed instruction space; each compressed codepoint has an opportu…

And all modern high performance Arm and x86 cores do more fusion than RISC-V cores that are currently on the market.

Intel has being fusing `CMP` and `Bcc` since Core 2 and AMD since Zen 1.

This is

- already one instruction in RISC-V

- an *extremely* common pattern, often occurring once every 5 or 6 instructions.

Re: RISC-V: They Should Have Known Better

#153

Post by brucehoult »

Retr0id wrote: post #31

I wrote an RV64IMA emulator recently. I just needed a virtual CPU core that could boot linux, and RV64IMA seemed like the simplest way to do that - and I think that's more or less true. But then I wanted to be compatible with off-the-shelf toolchains and binaries, and I found myself needing to extend the ISA profile to RV64GC. Not a huge lift, but it involved pulling in a softfloat library. That got me as far as boot…

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.

Re: RISC-V: They Should Have Known Better

#155

Post by Joel_Mckay »

ngl999 wrote: post #148
d-us-vb wrote: post #61

Earlier quoted context omitted.

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.

Sure, the constellation of features is no longer a general purpose computer in the retail context, but rather an ASIC appliance the ends up incompatible/useless rather quickly.

Maybe Gentoo could tame that level of chaos... or people just buy ARM64 again knowing the software ecosystem already works. =3

Re: RISC-V: They Should Have Known Better

#156

Post by TheAceOfHearts »

api wrote: post #53
kev009 wrote: post #9

It's basically MIPS all over again The conclusion is honest, and you can of course brute force any ISA into any role. I used to loathe x86 for that reason, but now that I'm older I respect the game.

X86 is the best argument that you can build a fast efficient RISC-V chip... because the X86 instruction set is a much bigger mess. It just blows my mind sometimes when designers don't learn insanely obvious lessons from the past, basic stuff like "complexity is evil" and "make the fast path overlap with the most common use cases" and "a standard with N optional extensions is actually N! (N factorial) standards." That…

There is a general pattern I've noticed, where people from past generations fail to share the lessons they have learned somewhere that is accessible for the next generations, so they are stuck repeating the lesson.

In particular, the next generation might recognize some aspects that seem bad and be confused over how to prioritize correctly because they don't know any better.

Re: RISC-V: They Should Have Known Better

#157

Post by brucehoult »

monocasa wrote: post #128
phire wrote: post #123

Earlier quoted context omitted.

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…

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 basic blocks — that it's just a non-issue.

Re: RISC-V: They Should Have Known Better

#158

Post by brucehoult »

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

History is much easier than prediction.

I'm with Jim Keller when he says that in time the fastest CPUs will be RISC-V ones.

Re: RISC-V: They Should Have Known Better

#159

Post by brucehoult »

monocasa wrote: post #143
dmitrygr wrote: post #140

Earlier quoted context omitted.

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…

There is zero chance that Apple doesn't have MacOS and iOS running on RISC-V in the lab.

They did that with x86 and Arm half a decade before any announcement about a switch, not to mention a number of other ISAs that didn't make it to shipping (e.g. M88k) and probably ones that word has never leaked about. IA64, anyone?

They're too large and rich and risk-averse to *not* do it.

Re: RISC-V: They Should Have Known Better

#160

Post by kazinator »

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

Honestly, I would feel uncomfortable if I were designing an instruction encoding and came up with some addressing mode format where there are two bits for a displacement. I would pull myself aside and have a word with myself. That's just me, though.
Post reply on HN