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

321–330 of 467 posts

Re: RISC-V: They Should Have Known Better

#321

Post by hmry »

inigyou wrote: post #312
random3 wrote: post #296

Yet it's royalty-free and good enough for Espressif (maker of ESP32) to move exclusively to the RISC V open-source instruction set architecture [1]. "Good enough ISA plus zero licensing cost" beats "perfect ISA plus royalties" in the embedded space. Also, let's not forget that the reason the world is built on the von Neumann architecture is that it was made available for free. [1] - https://www.eenewseurope.com/en/es…

Why didn't they make their own ISA long ago? Then they could have zero royalties. AFAIK ESP8266 was already its own architecture.

ESP8266 uses an Xtensa CPU like the ESP32 (just a non-customizable preset)

Re: RISC-V: They Should Have Known Better

#322

Post by bjornnn »

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?

even when foundational patents expire, licensing agreements and copyright and trademark and other things remain legally enforceable. chinese companies actually did start investing in mips at one point but ended up getting sued. people tried to open source mips years ago but gave up and just switched to risc-v because it's too much of a legal hassle to try to open source something that was proprietary for decades and has all the legacy baggage of multiple previous owners who want to sue you for any reason they can think of. it was easier to just design a new architecture that was open from the start.

Re: RISC-V: They Should Have Known Better

#323

Post by NooneAtAll3 »

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…

> diagram for the Arm T32 BL encoding

is that... bit xor?

did they attempt signed immediate, but gave up 3 bits into a 32 bit immediate?

wtf

Re: RISC-V: They Should Have Known Better

#324

Post by wren6991 »

NooneAtAll3 wrote: post #323
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…

> diagram for the Arm T32 BL encoding is that... bit xor? did they attempt signed immediate, but gave up 3 bits into a 32 bit immediate? wtf

It originally had a range of 4 MiB, and they extended it to 16 MiB in a later ISA revision. The bits with the XORs were originally constant-1 and they wanted to keep backward compatibility, so bits J1 and J2 are interpreted as "if this bit is clear, toggle this position in the leading sign bits".

Re: RISC-V: They Should Have Known Better

#325

Post by NooneAtAll3 »

camel-cdr wrote: post #171

My disagreement with the article is mostly the following: RISC-V is not an ISA, but an ISA generation framework. If RISC-V would've standardized aarch64 1-to-1, the end result would've still been a huge extension mess, because a lot of people (RVI member) have different requirements and a very happy to build their own subsets, which would then be upstreamed because multiple vendors want the same subsets and compatibi…

wdym by "gets cracked at decode"?

Re: RISC-V: They Should Have Known Better

#326

Post by skew-aberration »

ChuckMcM wrote: post #243
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…

> RISC-V is .. fine. Yeah, so was 8051 and it sucked too :-). I appreciated having this rant all in one place. Ranting against bad architecture is always cathartic and absolutely useless since the people who built and now champion the bad architecture are invested so one's rant simply irritates them. And like the parent comment here, I too find RISC-V "useful" in that it has sufficient tooling to make most everything…

Nobody wants to cross compile a full linux OS though just for their project. I assume most are using debian multiarch (as they do for arm), and that does mandate a common RISC-V ISA subset. So presumably this will drive further standardization

Re: RISC-V: They Should Have Known Better

#327

Post by ip26 »

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…

They even loudly declared how they were going to clean up all the messy corners and warts.

The underlying truth seems to be that a “clean” ISA doesn’t by nature make the beer taste better, and many of the warts probably have a reason for existing.

Re: RISC-V: They Should Have Known Better

#328

Post by NooneAtAll3 »

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 keep seeing comments here saying that a)compressed instruction are awful for pipeline decode, so they aren't used in any ISA on fast speed and b)risc-v loses in code size if you compare against compressed instructions

I don't understand how the two viewpoints fit together

Re: RISC-V: They Should Have Known Better

#329

Post by skew-aberration »

userbinator wrote: post #301
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…

it still is a much better starting point than coming up with your own bespoke ISA, building a toolchain around it and convincing potential customers that your proprietary architecture is worth the effort to deal There are lots of somewhat successful yet little-known Chinese companies with their own proprietary architectures and the toolchains to match, so I don't think it's that clear-cut. (That said, most if not all…

Google search turns up LoongArch (RISC), Shenwei (CUDA-like, HPC), UniCore (RISC). ESP32 is using Tensilica LX6/LX7 RISC base (RISC designed for custom hardware extensions).

Re: RISC-V: They Should Have Known Better

#330

Post by dmitrygr »

wren6991 wrote: post #324
NooneAtAll3 wrote: post #323

Earlier quoted context omitted.

> diagram for the Arm T32 BL encoding is that... bit xor? did they attempt signed immediate, but gave up 3 bits into a 32 bit immediate? wtf

It originally had a range of 4 MiB, and they extended it to 16 MiB in a later ISA revision. The bits with the XORs were originally constant-1 and they wanted to keep backward compatibility, so bits J1 and J2 are interpreted as "if this bit is clear, toggle this position in the leading sign bits".

There is very cool history as to why. In armv5 the BL was two separate instructions. You could take an interrupt in between. And it was documented what each did. Veeery cool. Then they wanted more range. And now that they redefined the two halves as one instruction that could not be in halves, they also redefined a few bits that were always 1 before, to allow the second half of the instruction to be recognized right without a “previous instruction was first half of BL” flag somewhere that would need to be context switched and all that.
Post reply on HN