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

251–260 of 467 posts

Re: RISC-V: They Should Have Known Better

#251

Post by Rohansi »

camel-cdr wrote: post #185
Tuna-Fish wrote: post #87

Earlier quoted context omitted.

You forgot the variable that RISC-V chose to maximize: 5) Weird principles that are completely detached from anyone's actual needs and that are carried to a length similar to religious convictions. My biggest personal pet peeve about the architecture is the JAL instruction. That is, PC-relative jump and link immediate, which jumps to an PC + sign extended immediate value and stores the address of the next instruction…

https://github.com/riscv/riscv-isa-manual/pull/3269

Everything being an optional extension is covered by the article. It's bad enough for OpenGL and Vulkan but to burn that into silicon and not have a reliable way to detect them is way worse!

Re: RISC-V: They Should Have Known Better

#252

Post by monocasa »

dismalaf wrote: post #198
monocasa wrote: post #122

Earlier quoted context omitted.

The same kind of people that 'worked for free' to develop Linux.

Most Linux devs have been corporate employees getting paid to develop it for a very long time. It's not the early 90's any more.

That's why I put 'worked for free' in quotes like that.

Re: RISC-V: They Should Have Known Better

#254

Post by dmitrygr »

brucehoult wrote: post #159
monocasa wrote: post #143

Earlier quoted context omitted.

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.

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

Re: RISC-V: They Should Have Known Better

#255

Post by wasmperson »

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…

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

I'm not a hardware person, but whenever I look at compiler output I find computed index accesses all over the place in the assembly. This would suggest to me that at least compiler developers believe these addressing modes to be important.

> Yes, that is totally fine. Either you know your target CPU, or you don't - and then you ask your OS for details.

So then my code has to choose between being hardware-dependent or OS-dependent? That doesn't seem ideal.

> "For example, if you are writing a kernel and want it to support all RISC-V cores" - NOBODY IS DOING THAT.

I'd hate to live in a future where linux distros need to ship a separate kernel binary for every random combination of RISC-V features. That said maybe the run-time feature-detection extension will be so widely supported in practice that this wouldn't come up?

Re: RISC-V: They Should Have Known Better

#257

Post by _chris_ »

201984 wrote: post #194
ethin wrote: post #13

I can definitely see his argument, although I still do believe RISC-V did a lot of things better than x86... I really do hope that the arch is eventually able to fix this. Better that there be an open ISA than them all be closed IMO.

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

Re: RISC-V: They Should Have Known Better

#258

Post by theamk »

baron3dl wrote: post #256

This feels like Andy Tennenbaum's LINUX is OBSOLETE post from 30 years ago.

don't see how? the last section is pretty explicit:

> None of this is to say that RISC-V is doomed. As I said, I fully expect it to take over the space currently occupied by [...] Much like the linux kernel -- the price is right.

Re: RISC-V: They Should Have Known Better

#259

Post by _0ffh »

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.

Inadvertent touching is fixable, ARM for example did it with the S bit (though on AArch64 it's slightly more complicated).

I regard it as a mistake of RISC-V. The flag register was invented for good reasons, and dropping it is a trade-off I personally do not think is worth the downside.

Re: RISC-V: They Should Have Known Better

#260

Post by mycall »

Neywiny wrote: post #133

I think I get it. I've tried microblaze-v for a while now. And just look at their interrupt handler. https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/sta... . With the FPU enabled at compile time, that's > 128 memory ops per interrupt. That's insane, especially without an NVIC and chaining and all that. My latency was astronomical, and my maximum interrupt frequency was pitiful. Ended up doing the work (sw an…

You can bypass AMD's heavy BSP abstractions according to gpt.
Post reply on HN