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

331–340 of 467 posts

Re: RISC-V: They Should Have Known Better

#331

Post by dmitrygr »

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.

Re: RISC-V: They Should Have Known Better

#332

Post by dmitrygr »

brcmthrowaway wrote: post #10

> What does a cheap microcontroller core need? Let's inspect what they are used for. Typical use cases are to interface with and quickly reconfigure hardware blocks in a larger chip, eg in an MP3 player, an SD card, or a USB stick. The hard work is done by custom IP and the CPU core is just there to occasionally prod a register or configure something. He forgot electronic cigarettes (vapes)

My apologies. I’ll update my shitpost with this example. :)

Re: RISC-V: They Should Have Known Better

#333

Post by brucehoult »

dmitrygr wrote: post #217
brucehoult wrote: post #151

Earlier quoted context omitted.

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 va…

> RISC-V has by far the most compact code of any popular 64 bit ISA, Forgot to say “RISC”. Cause else: amd64

No, RISC-V code is much more compact than Amd64. This is easily demonstrated on any real application, such as those in your favourite Linux distribution.

Re: RISC-V: They Should Have Known Better

#334

Post by brucehoult »

ACCount37 wrote: post #292
aurelian15 wrote: post #236

Earlier quoted context omitted.

I think the GP is talking about the Hazard3 [1] core. This is one of the CPU cores besides the ARM M33 instantiated on the RP2350 µC [2]. See this article from Luke Wren (Wren6991) back when the RP2350 came out [3]. [1] https://github.com/Wren6991/Hazard3 [2] https://www.raspberrypi.com/products/rp2350/ [3] https://www.raspberrypi.com/news/risc-v-on-raspberry-pi-pico...

What I find interesting is that RP2350 is designed as "one or the other", no way to use ARM and RISC-V concurrently, and has fuses that can kill ARM M33 cores outright. Makes me wonder if an "ARM cores fused off, RISC-V only, no ARM fees" SKU is possible.

You can choose Arm in one pair and RISC-V in the other pair if you want.

Re: RISC-V: They Should Have Known Better

#335

Post by phire »

wk_end wrote: post #245
_0ffh wrote: post #212

Earlier quoted context omitted.

>absolute distain for flag registers It's worst aspect maybe.

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 FPRs, and we are probably also renaming part of fscr (because turns out, RISC-V does have flags for floating point operations), maybe a few other bits of state. So we just use the existing renaming mechanism to rename a bank of flags registers; That single logical shared flags register is actually backed with a bank of non-shared physical flags registers, neatly solving all concerns.

Sure, the renamed flags do take up a bit of die space. But IMO they don't add any extra design complexity, and shouldn't have any performance impact on maximum clock speed.

RISC-V isn't quite as disadvantaged by the lack of flags as some might suggest (and I wouldn’t say the lack of flags is RISC-V’s worst aspect), but there are a few sequences (add-with-carry, some conditional-moves, detecting overflow) where RISC-V is forced to burn an extra instruction or two to deal with the lack of flags, and IMO eliminating that would be worth the cost of slightly more die space.

Also, avoiding the need for dedicated compare-and-branch instructions would free up encoding space for other things (including larger range on branches)

Re: RISC-V: They Should Have Known Better

#336

Post by brucehoult »

adrian_b wrote: post #248
brucehoult wrote: post #151

Earlier quoted context omitted.

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 va…

That is false. All the claims of the RISC-V fans that I have seen in the past compared the compressed variant of RISC-V with the uncompressed variants of the other ISAs. Most other ISAs, like ARM, POWER and MIPS, also have compressed variants and if RISC-V were compared with those, it would lose. Moreover, if you use safe compilation options with RISC-V, the code size explodes in comparison with any other ISA, becaus…

I specified "popular 64 bit ISA", which comes down to amd64 and arm64. But you can include Elbrus and LoongArch if you want. Or POWER. Or Itanium.

> I assembly by hand almost any function that is not too simple I can make it shorter on Cortex-M33 than on RISC-V

Not if you use the RISC-V ISA properly.

Re: RISC-V: They Should Have Known Better

#337

Post by brucehoult »

chrisjj wrote: post #216
brucehoult wrote: post #154

Earlier quoted context omitted.

It's not wasted when it makes programs overall smaller, as it does.

It is wasted if its reduction is less than that of alternative uses for that instruction space.

Such as?

There is still plenty of unused 32 bit (30 bit) opcode space.

Re: RISC-V: They Should Have Known Better

#338

Post by brucehoult »

dmitrygr wrote: post #254
brucehoult wrote: post #159

Earlier quoted context omitted.

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.

I do wonder, which of the two of us actually worked for years in Apple’s kernel team? :)

Not me for sure. I have no idea about you. Of household name companies I've only worked at Mozilla and Samsung R&D. And SiFive if you count people in threads such as this.

I could of course be wrong but I think the publicly known history sets the pattern pretty reliably for the speculation.

Re: RISC-V: They Should Have Known Better

#339

Post by exmadscientist »

indrora wrote: post #307
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…

> Designing a good 64-bit ISA [...] is easy [...] could design such an ISA in a couple of weeks Let me know when you've got it all worked out and published. Should be easy, right?

It is the easy part. Four weeks is plenty of time.

That's why it's so bizarre that the RISC-V design is so awful.

The hard part is the software support side (though, as comments elsewhere in the thread point out, AI is pretty helpful there) and then those lovely pieces like specifying the precise behavior of interrupts.

If it had a snowball's chance in hell of going in to any kind of production anywhere, I'd have no problem spending the next month laying out an ISA. But, again, as this thread makes very, very clear: ISA really just doesn't matter.

Re: RISC-V: They Should Have Known Better

#340

Post by cuu508 »

mort96 wrote: post #300
ACCount37 wrote: post #290

Earlier quoted context omitted.

This is a "microcontroller core", not a "microcontroller". We're talking "deep embedded" applications - where an ASIC is designed for a very specific purpose, and that design just so happens to call for a programmable CPU core to be included in it. This is the kind of design that lives in your keyboard, your mouse, your USB stick, your USB hub, your HDD, your SSD, your eMMC chip, your memory card and more. Remember:…

Å microcontroller needs a microcontroller core. EDIT: Leaving that Å in. For some reason, iOS on iPad is obsessed with autocorrecting "A" to "Å" even when using the English keyboard. It's driving me nuts.

Isn't there a setting to turn auto-correct off?
Post reply on HN