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

221–230 of 467 posts

Re: RISC-V: They Should Have Known Better

#221

Post by u1hcw9nx »

inigyou wrote: post #68
spicyjpeg wrote: post #67

Earlier quoted context omitted.

RISC-V is in many aspects just legally-distinct-MIPS, from the base instruction set all the way up to how certain extensions introduce kludges that are very reminiscent of later MIPS additions. While I do somewhat agree on the fact it was a huge missed opportunity to improve upon MIPS's technical flaws in order to realistically compete against the likes of ARMv8, we still have to keep in mind that the primary driving…

Has it been proven that no patent troll holds a patent covering RISC-V? Of course not because that's impossible to prove.

If you iterate trough every concept RISC-V has, you might be able to prove it.

The RISC/MIPS concepts date back over 40 years. The base instruction set is intentionally designed with unencumbered, expired, or public-domain architectural concepts.

RICV-V microarchitectures and implementations are at much high risk of violating patents. Especially anything that is even slightly high performance. SiFive, Andes , and Alibaba’s T-Head are filing thousands of patents on microarchitectural optimizations and extensions. China's RISC-V patent-sharing alliances and other industry groups are building defensive patent cross-license around their RISC-V-related patents.

Re: RISC-V: They Should Have Known Better

#222

Post by apple1417 »

monocasa wrote: post #91
jcranmer wrote: post #76

Earlier quoted context omitted.

I'm not an embedded programmer myself, but from what I've heard... it's actually a pretty big assumption that the software people know what model hardware they're running on. Especially consider the possibility that a product manager decides to swap out the core for a different core to save 5¢ on the BOM. Does the product manager know to ask if the two cores follow the same RISC-V profile? Do the software programmers…

That doesn't really happen in the embedded space. Even if the core was supported just fine, all of the IO mux stuff is pretty much guaranteed to be different even with the same chip in a different package. You're looking at explicit support for each chip.

I worked on a project porting from an STM32L073 to a STM32U073, which management were assured was a complete drop in replacement. Well, it was only in the sense that you could drop one onto the old PCB. It became a running joke how many software compatibilities we ran into. My favourite was an "LCD clock disable" bit became "LCD clock enable". And this was for a specifically chip designed to be an easy replacement.

Re: RISC-V: They Should Have Known Better

#223

Post by aappleby »

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

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.

Hell, 90% of his arguments are "You can't detect X at runtime from user code without relying on some extension" - Yes, that is totally fine. Either you know your target CPU, or you don't - and then you ask your OS for details. This is not some dealbreaker.

From the article - "For example, if you are writing a kernel and want it to support all RISC-V cores" - NOBODY IS DOING THAT. You target a platform spec, not the combinatorial explosion of everything from RV32E to RVA22 or whatever the latest is.

You want to distinguish S mode from M mode? WHY DO YOU NOT ALREADY KNOW THIS?

Instruction encoding is weird? WHO CARES, the decoding is like eight lines of Verilog.

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

Guhhhhh, I don't get it. This guy has some vendetta and either has not shipped any risc-v code or is just in love with his own personal favorite instruction set.

Re: RISC-V: They Should Have Known Better

#224

Post by dgellow »

brucehoult wrote: post #149
zephen wrote: post #54

Earlier quoted context omitted.

> RISC-V is... fine Exactly. > It satisfies my two requirements for an ISA as a hobby CPU designer... You probably have some unstated requirements as well, such as available toolchains and "vetted well enough to actually be able to run code." Risc-V now occupies the Schelling point for people who, for whatever reason (rent-seeking and security top the list) want to leave the x86 and Arm ecosystems.

Luke is too modest. Something in the region of 5 million chips containing his hobby CPU have shipped since launch on August 8, 2024.

Could you share a link or more details? What is this hobby CPU project?

Re: RISC-V: They Should Have Known Better

#225

Post by [deleted] »

_0ffh wrote: post #212
phire wrote: post #114

Earlier quoted context omitted.

Yeah, very much legally distinct MIPS, at least as a starting point. The biggest tell is the mnemonics. While RISC-V takes a bunch of ideas from other places, and cleans things up, it copies a lot of mnemonics straight from MIPS. But it also copies a lot of other ideas from MIPS, like the absolute distain for flag registers.

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

[deleted]

Re: RISC-V: They Should Have Known Better

#226

Post by Lord-Jobo »

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…

Yeah the OP post read to me like someone throwing the baby out with three drops of bath water. If this was presented more like “minor gripes with risc V” I’m guessing I wouldn’t feel that way

Re: RISC-V: They Should Have Known Better

#227

Post by bfrog »

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…

The encoding being oddball does have some effects on linkers/loaders though I imagine?

Not that linking/loading is a super hot path people generally worry about.

Re: RISC-V: They Should Have Known Better

#228

Post by bfrog »

kevin_thibedeau wrote: post #62
kjs3 wrote: post #28

Earlier quoted context omitted.

I think MIPS is a great example, and even there I don't think there's the bizarre bifurcation of ISA options RISC-V brings to the table. As a fellow olderster, I can't help but think that after almost 50 years of "ISA X is sooooo much better than x86 it's obvious ISA X is the future and x86 will be dead Real Soon Now (for whatever todays version of x86 is)" I can only shake my head ruefully and say "ping me when that…

x86 chips don't truly exist anymore. They only use it as a compressed ISA for a more capable internal representation that can be freely updated at any time.

There's still repercussions to the unaligned variable length instruction set that is x86 though, and the decoder and prefetch have to deal with the insanity that falls out from it... ultimately limiting how parallel the instruction decode and dispatch can be.

Re: RISC-V: They Should Have Known Better

#229

Post by aappleby »

bfrog wrote: post #227
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…

The encoding being oddball does have some effects on linkers/loaders though I imagine? Not that linking/loading is a super hot path people generally worry about.

It has an effect only in terms of how big an offset you can encode in a relative jump, the _arrangement_ of those bits in the instruction is irrelevant (and already abstracted away in the compiler/linker framework).

Re: RISC-V: They Should Have Known Better

#230

Post by coredog64 »

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 or HP née Compaq née Digital Equipment Corporation?
Post reply on HN