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

381–390 of 467 posts

Re: RISC-V: They Should Have Known Better

#381

Post by dzaima »

dzaima wrote: post #342
dmitrygr wrote: post #331

Earlier quoted context omitted.

> 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.

Both clang and gcc do actually generate TBZ/TBNZ for checking a bool: https://godbolt.org/z/K6evhaxGT

Some stats on an aarch64 binary of my current main project (1.6MB .text, 6600 symbols as per whatever "nm the-binary | wc -l" includes, from "objdump -d the-binary"):

    19546 /tbn?z/
    18029 /tbn?z.*, #0x0/  (but this includes boolean checks)
      224 /tbn?z.*, #0x1f/ (i.e. 32-bit x
Said project doesn't do fixed bitfields much (there are some, but a chunk of those test multiple bits) so unsurprisingly not much. (I could imagine that the kernel has significantly more, but it's an edge-case (though perhaps an important one) of being basically massive amounts of fixed configurable glue)

Re: RISC-V: They Should Have Known Better

#382

Post by sylware »

This guy is weird: there is no perfect ISA, only compromises and tradeoffs. He is looking for _his_ perfect. Won't happen, unless lucky, namely your perfect aligns with RISC-V tradeoffs. There are also sweet spots, and I am writting RISC-V assembly almost every day and that "hits" them often. I currently use at 99.99% the core ISA (I have a few muls and divs here and there). I don't even use the bit manipulation extension...

There are millions of RISC-V chips out there. Performant microarchitectures are getting there, but the access to the latest silicon process is gated by the other ones, hogging production capacity (and they probably don't want RISC-V to "get there"...).

And most of all, hardware manufacturer/designers won't have a lawyer ringing at their door: this is so much critical, this will make them tolerate a lot of RISC-V tradeoff choices they dislike.

And ofc, big mistakes WILL BE MADE AND WILL HURT BAD. Expecting anything else is thinking like a teenager.

It seems the current biggest mistake is the compressed instruction extension. It seems the complexity it adds for high performance is not worth it (arm removes the thumb instructions for reasons). I have suspicions on some microarchitectures designed around the compressed instructions (16bits) having a negative performance impact on core ISA 32bits instructions (and many compiler optimizations are friendly to the way compressed instructions are, namely the destination register is one of the source register, that due to the legacy x86_64). BTW, Intel APX something, is basically RISC-V for x86_64.......

Another aspect people tend to forget while dealing with RISC-V, many of those design choices were made for the simplest way to implement performant CPU microarchitectures. Some say thats why on 'out-of-order' CPUs, you don't want a status flag register (there is none in RISC-V).

Re: RISC-V: They Should Have Known Better

#383

Post by pseudohadamard »

jurgenburgen wrote: post #346
pseudohadamard wrote: post #315

Earlier quoted context omitted.

That's why I've never understood the point of RISC-V. Anyone can design a (reasonably OK) ISA. It's everything else that's the hard part. It's like announcing a new house, it's going to be pained Benjamin Moore Yellow Oxide and everything else is someone else's problem to sort out. Success! We've got a new house! The only argument I've ever seen for RISC-V that's vaguely logical is that there's no licensing to Arm in…

> The only argument I've ever seen for RISC-V that's vaguely logical is that there's no licensing to Arm involved, but since I can get M0/M3 devices for a dollar or so with infinite tool and library support that's something that's totally irrelevant for most users. How expensive is it to license the instruction set so you can expand it?

Dunno, I'm still saving up for the billion-dollar fab I'll need before I can think about licensing an instruction set.

As an aside, Espressif (or Xtensa if you want to split hairs) have been quietly doing a lot of what RISC-V is supposed to do for years now. I know they've also been fiddling with RV32's but all the real work is LX6/LX7. They're best-known for their use in ESP32s but they also crop up in an awful lot of industrial/commercial gear.

Re: RISC-V: They Should Have Known Better

#384

Post by artemonster »

"What range of offsets can a 16-bit instruction encode? Zero through three. Not thirty three, not three hundred and three. Three! Well, maybe it is better for storing a halfword? Nope... zero or two. What even? Why" What the fuck is this criticism? Its sanely specced, who would want arbitrary unaligned offsets, like for anything? Supporting such obscure idiot cases is too much unnecessary pain, so cut it off on spec level

Re: RISC-V: They Should Have Known Better

#385

Post by genxy »

rayiner wrote: post #75
bjornnn wrote: post #49

the significance and allure of risc-v, the reason china is investing heavily in it right now, has little to do with the technical details of how it works under the hood, it's the fact that it is an open standard not encumbered by intellectual property law. even if it isn't technically the best general-purpose processor architecture, it sets an important precedent by proving that it is possible to develop an open publ…

Isn't almost everything in MIPS long outside patent protection?

I think the issue is then, if you have the same base lineage and you start extending and fixing things, then it will be easy to overlap with new patents that whomever still holds MIPS IP.

RISC-V is mainly a way to avoid IP conflicts, not as a technical breakthrough. MIPS itself was a boring (this is good) implementation of the original RISC papers, but they asserted a bunch of things legally which eventually, along with the legal work of Arm meant that ISAs were effectively owned by their parent corporations.

I'd assert that much like 3rd parties being able to make replacement car parts, that we should be able to make ISA compatible chips. But here we are, RISC-V needs to exist and does, but for legal reasons, not technical ones.

*edit, I forgot to refresh before posting, what bjornnn said.

Re: RISC-V: They Should Have Known Better

#387

Post by camel-cdr »

dzaima wrote: post #381
dzaima wrote: post #342

Earlier quoted context omitted.

Both clang and gcc do actually generate TBZ/TBNZ for checking a bool: https://godbolt.org/z/K6evhaxGT

Some stats on an aarch64 binary of my current main project (1.6MB .text, 6600 symbols as per whatever "nm the-binary | wc -l" includes, from "objdump -d the-binary"): 19546 /tbn?z/ 18029 /tbn?z.*, #0x0/ (but this includes boolean checks) 224 /tbn?z.*, #0x1f/ (i.e. 32-bit x Said project doesn't do fixed bitfields much (there are some, but a chunk of those test multiple bits) so unsurprisingly not much. (I could imagin…

Did a quick grep over object files of a half build defconfig kernel:

    total: 15510
    #0:  3720
    #31: 2247
    #1:  1349
    #21: 1208
    #2:  810
    #3:  524
    #8:  493
    ...

Re: RISC-V: They Should Have Known Better

#388

Post by summa_tech »

wren6991 wrote: post #302
AlotOfReading wrote: post #269

Earlier quoted context omitted.

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

> 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. And what if that blob has instructions your new core just doesn't implement? This problem has nothing to do with overlap.

Then you take an illegal instruction exception, and you have a choice to request a rebuild, patch it, or emulate it. (Yeah, sometimes the vendors just don't cooperate.)

Incidentally, emulating opcodes is quite often practical (unless the performance must not be affected), and is greatly helped by having the plainest, cleanest instruction encoding possible, and a well designed system register & exception architecture.

Re: RISC-V: They Should Have Known Better

#390

Post by pseudohadamard »

exmadscientist wrote: post #339
indrora wrote: post #307

Earlier quoted context omitted.

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

It looks an awful lot like something that was designed by a sizeable committee made up mostly of academics, most of whom won't have written ten lines of code in as many years. I don't actually know in this case, but I've had to sit and watch standards created in this manner, and Dmitry's description of the RISC-V mess matches their output fairly closely, a chaotic mess that includes every idea everyone on the standards committee has ever had, all made optional so no-one will vote against it when it comes to balloting.
Post reply on HN