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

261–270 of 467 posts

Re: RISC-V: They Should Have Known Better

#261

Post by 201984 »

_chris_ wrote: post #257
201984 wrote: post #194

Earlier quoted context omitted.

>I still do believe RISC-V did a lot of things better than x86... Such as? I can't think of anything it does better for high performance cores.

1B through 15B variable length instruction mess, for one. Which still yields a worse than average 4-5B per instruction average.

That is a strength, not a weakness. It allows for things like 64-bit immediate loads, 32-bit branch offsets, and nearly unlimited future extensibility.

With RISC-V, multiple instruction workarounds are needed for all of the above, and those sequences are usually sequentially dependent ones so they can't be run in parallel. i.e. the insanity of loading a 64-bit value through repeated 12-bit immediates with shifts, using multiple instructions to compute branch offsets, and RVV needing setvli instructions everywhere due to not having opcode space to encode vector length/type.

AArch64 is better, but still has problems with limited opcode space when it comes to future extensions. They've had to make "start mode" and "end mode" for SME to save on opcode space, and future compromises will likely be necessary.

Re: RISC-V: They Should Have Known Better

#263

Post by Someone »

phire wrote: post #112
wmf wrote: post #17

Earlier quoted context omitted.

Better than x86 is a low bar when ARMv8 exists.

And personally, I'm not even sure it crosses that bar. RISC-V somehow manages to be more fragmented than x86 (which is impressive), and just can't compete on instruction density. I think a large part of the issue with RISC-V is that it predates (public knowledge of) ARMv8 by a year or two, so it couldn't use it as inspiration. If you compare RISC-V to 32-bit ARM, the comparisons are much more favourable.

> think a large part of the issue with RISC-V is that it predates (public knowledge of) ARMv8 by a year or two

Does it? https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p... has a section on ARMv8 (section 2.5)

It says they became aware of it a year after they started the RISC-V project, but that’s five years before that paper was published.

Re: RISC-V: They Should Have Known Better

#264

Post by rnvannatta »

p_l wrote: post #8
80x86 wrote: post #4

100% agree with dmitrygr. I was excited when I heard about the project just after it started. However, past experiences taught me to wait before getting excited about the new 'shiny thing'. I did it differently with RISCV. I waited. I am glad I did. It took a long time for actual silicon to appear. Also, the silicon today has all the facepalming special cases mentioned in the article. Its almost like those old soviet…

I'd say RISC won, when you consider how "RISCy" x86 is[1] compared to the ur-CISCs (68k, VAX ) that RISC projects were in opposition to. [1] Not because of often-called "risc like" microcode engine, but because the most complex addressing mode on x86 usually decodes two microinstructions, and decodes in single cycle. In comparison VAX needed separate pipeline for instruction decoding.

The two winning instruction sets are the RISCiest CISC, x86, and the CISCiest RISC, arm.

Re: RISC-V: They Should Have Known Better

#265

Post by throw16180339 »

hinkley wrote: post #204
pocksuppet wrote: post #195

Earlier quoted context omitted.

Sure can. Just change the encodings. You thought RISC-V chips were compatible with each other beyond the basics? They're not. RISC-V is only a starting point for designing the ISA your chip will actually implement. Don't get me wrong - it's still beneficial that simple code works on many chips.

HP wrote a JIT to migrate old applications to their new hardware. So did Apple, twice. I don't know if IBM were the first but they've done it a few times as well for their mainframe hardware. In HP's case, they tried running their JIT to translate from architecture B to architecture B and ended up with better performance than running it directly.

HP also used a binary translator to migrate from HP3000 to PA-RISC in the 80s.

Re: RISC-V: They Should Have Known Better

#266

Post by boredatoms »

brucehoult wrote: post #153
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.

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

Re: RISC-V: They Should Have Known Better

#267

Post by koverstreet »

mcdow wrote: post #231
Narishma wrote: post #214

Earlier quoted context omitted.

Why is that funny?

it’s funny because it’s unexpected. one of those members is not like the others. the rest are tech companies. it does make me wonder what prompted them to join. it would suggest to me there are forward looking people in Brazil’s government. I am impressed.

I consistently see a level of competence and professionalism in South America that has left the building in the states.

Re: RISC-V: They Should Have Known Better

#268

Post by camel-cdr »

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 want to try looking at codesize for -Os builds with the different ISAs including the compressed variants you mentioned. As well as dynamic icount with overflow checking.

Do you have any specific project in mind that I could use for testing?

Re: RISC-V: They Should Have Known Better

#269

Post by AlotOfReading »

aappleby wrote: post #223

Having written a few RISC-V cores, worked on a chip design project that used RISC-V cores, and generally being OK with the architecture in real-world use cases: What the heck is this guy's problem? Just about every thing he mentioned as a problem is not a problem in practice. Too many options? Who cares, you're not trying to write code that runs on every possible configuration. Either you're writing embedded firmware…

     Either you're writing embedded firmware and know exactly what core you're using, or you're writing an application that runs in an operating system and that system has a minimum ABI like RVA20 or whatever.
It's very common for embedded teams these days to support a diverse set of cores with a shared codebase, depending on the specific requirements of different products/systems. SoC vendors will often change cores between versions or product lines, and I might need performance in this one system vs specific interfaces in another. So even if I know what core I'm using today, I don't know what core I'll be using in a year or five. I may also be writing a library or other reusable component and have no idea what core will run things today.

    Array accesses take an extra instruction? Either you're in a tight loop walking a tiny array and you don't do the full offset calculation per step, or you're walking over an array in RAM and you're bottlenecked by the memory bus.
Let's take the bitfield instructions the author complains about for similar reasons. If bfi/bfx takes multiple instructions, optimal structure packing isn't necessarily a win for performance or memory usage. The programmer needs to trade off how often the structure is instantiated vs accessed. Even they can make the right decision today, it might not be the right decision tomorrow. And if they get it wrong, that might not be apparent until later (when it will be somewhat obscured in superficial memory usage analysis). Or the ISA can get it right the first time and also make things easier for compilers/humans in the process.

    "Who can predict how their binary will act when a floating point store silently becomes a double-register move or a jump instruction, or vice-versa?" - THIS DOES NOT HAPPEN IN PRACTICE.
I can easily imagine this happening. When you change embedded platforms, the typical approach is to take the existing system and compile it for the new platform without carefully revisiting every decision made in the old system. If one of your vendor blobs was specified for the old system and the new system is "similar", you'll just link it in and see what happens. The metadata in the blob will hopefully catch the issue at link time, but it was an avoidable error.
Post reply on HN