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

71–80 of 467 posts

Re: RISC-V: They Should Have Known Better

#71

Post by kjs3 »

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.

I keep seeing this line of reasoning and have no idea why it's relevant. You don't program that 'internal representation'. The software people want to run only care if that software doesn't run. Cyrix, Transmeta,NexGen, Centaur, WinChip, etc., etc, theoretically had "more capable internal representation". The only thing that actually matters is "does it run the exact same x86 software I bought X many years ago" and "does it run it at a decent price/performance ratio". Everything else is dick measuring.

Today, we have Intel and AMD, and some bit-player embedded folks.

Re: RISC-V: They Should Have Known Better

#74

Post by amluto »

wren6991 wrote: post #43

RISC-V is... fine. It satisfies my two requirements for an ISA as a hobby CPU designer, which are: 1. Supported in mainline LLVM and GCC. 2. I can implement it without lawyers sending me a love letter. Everything else, I can fix in post. There are enough good ideas spread across the extensions that I can assemble a reasonably put-together, curated embedded ISA with competitive performance and code density that admits…

You can’t fix the mutually incompatible overlapping encodings in post.

Re: RISC-V: They Should Have Known Better

#75

Post by rayiner »

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?

Re: RISC-V: They Should Have Known Better

#76

Post by jcranmer »

hn_submit wrote: post #27
tsukikage wrote: post #21

Earlier quoted context omitted.

He explains, at length: there is no sane way to determine what the hardware you are running on actually supports, and so there is no sane way to ship compiled code that is both compatible and performant. We already had the mystery meat CPU wars several decades ago. We know how to make sane ISAs now and should be past that.

You don't need to probe what hardware you're running on because you know being the manufacturer. The code is bespoke for your solution and nothing more. No foreign code is going to run on it. Different problems require different solutions. An electric blanket doesn't need a barrel shifter for multiplication or even floating point hardware. The ISA can change depending on what's needed to solve a particular problem, n…

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 think to ask? How about communicating the change to all of the vendors or contractors providing you binary blobs? I don't know how likely it would be for a scenario like he author here describes, but it is definitely a plausible scenario.

Re: RISC-V: They Should Have Known Better

#77

Post by lowbloodsugar »

kjs3 wrote: post #35
walrus01 wrote: post #26

Earlier quoted context omitted.

> The market can sort it out for themselves Because nobody will write software for 300 unique hardware variations of a platform that have inconsistent capabilities. Consistency is one of the reasons why x86-64 with extensions like like SSE, AVX2 etc is popular.

Noone uses an 8051 because it's elegant. Billions are still still sold every year because no matter if you learned it in the 70s or last week and no matter who made it, the basics are exactly alike. Software matters; ISAs don't.

>You learned it in the 70s [emphasis mine]

I really don't know anything about this space, but you just said that 8051 is dominant because it has one dominant architecture since the 70s. It has hundreds of manufacturers making identical parts.

As you say, software matters. If the Software can't run because of hundreds of extensions that can't be checked for, then you're going to pick a target that works, no? So in fact the ISA matters most: which ISA has the most software? Which ISA means my software runs on the most devices?

Re: RISC-V: They Should Have Known Better

#78

Post by rayiner »

api wrote: post #53
kev009 wrote: post #9

It's basically MIPS all over again The conclusion is honest, and you can of course brute force any ISA into any role. I used to loathe x86 for that reason, but now that I'm older I respect the game.

X86 is the best argument that you can build a fast efficient RISC-V chip... because the X86 instruction set is a much bigger mess. It just blows my mind sometimes when designers don't learn insanely obvious lessons from the past, basic stuff like "complexity is evil" and "make the fast path overlap with the most common use cases" and "a standard with N optional extensions is actually N! (N factorial) standards." That…

> X86 is the best argument that you can build a fast efficient RISC-V chip... because the X86 instruction set is a much bigger mess.

I don't think that's actually true. There's weird historical baggage and whatnot. But if you're running in long mode, it's actually a fairly sensible architecture with useful memory addressing modes.

Re: RISC-V: They Should Have Known Better

#79

Post by fluffybucktsnek »

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.

> Of course not because that's impossible to prove.

Why?

Re: RISC-V: They Should Have Known Better

#80

Post by wren6991 »

mhh__ wrote: post #65
zephen wrote: post #56

Earlier quoted context omitted.

> it's the fact that it is an open standard not encumbered by intellectual property law. There are actually many of those. But Risc-V has become, through effective marketing, the Schelling point for anybody who wants to avoid the x86 and Arm ecosystems, both for the rent-seeking behaviors you mention, and also, in some instances, for security reasons. And, as others have mentioned, the ISA doesn't really matter. As l…

The ISA not mattering I think isn't as true when you account cost e.g. in a huge OOO cpu all the fusions and so on are afaict fairly doable but if you are on a cheaper / worse CPU all those extra bytes in the instruction stream do add up.

The RISC-V fusion arguments from back in ~2018 didn't really pan out. A lot of those fusion opportunities are just instructions now. slli + add? Zba (sh*add). slli + srli? Zbb (zext.*). slli + srai? Believe it or not, also Zbb (sext.*).

Look at that pair of RVC instructions you used instead of a single 32-bit opcode. They are:

* Taking up valuable compressed instruction space; each compressed codepoint has an opportunity cost of 64k uncompressed ones.

* Limited in which registers they can use (usually x8..x15).

* Often clobber their input operand instead of giving a free move.

Also consider that the frequency data that drove the RVC compression decisions was driven by the lack of architecturally fused instructions like sh*add, so any arguments you derive from that data are circular. An instruction can be a good uarch fusion target because it's compressed, and a good compression target because you didn't fuse it in the architecture.

I think designing for uarch fusion in your ISA is coming at it from the wrong end. Fusion is something uarch designers do to make up for shortcomings in the ISA.

Post reply on HN