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

311–320 of 467 posts

Re: RISC-V: They Should Have Known Better

#311

Post by adastra22 »

wren6991 wrote: post #193
adastra22 wrote: post #119

Earlier quoted context omitted.

I… you can’t be serious.

Yes, I'm serious. I think the overlap is an aesthetic problem rather than a practical one, given that: * The profile used by "Big SoCs" already explicitly depends on F + D + C, implying ZcdZcf, so the newer Zce won't be implemented. * The compressed float load/store opcodes repurposed for Zce are often unimplemented on embedded processors. * The ELF file has an attribute section telling you the exact ISA string. If y…

There is a lot to unpack, hence my reaction. Instead of a straight compressed instruction format supported (or not supported) everywhere, we get an alphabet soup of options. C -> "ZcfZcdZca" just by itself is insanity. But the actual technical change is a problem too. Now I can't make vendor-independent RISC-V code, since apparently they all support different compressed instruction sets.

I represented my company as a founding member of the RISC-V foundation. I now shake my head at what it has become and hope I never have to write code for a RISC-V system again. Every time I check in it seems like some new insanity has manifest itself.

Re: RISC-V: They Should Have Known Better

#312

Post by inigyou »

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.

Re: RISC-V: They Should Have Known Better

#313

Post by dlcarrier »

mort96 wrote: post #300
ACCount37 wrote: post #290

Earlier quoted context omitted.

This is a "microcontroller core", not a "microcontroller". We're talking "deep embedded" applications - where an ASIC is designed for a very specific purpose, and that design just so happens to call for a programmable CPU core to be included in it. This is the kind of design that lives in your keyboard, your mouse, your USB stick, your USB hub, your HDD, your SSD, your eMMC chip, your memory card and more. Remember:…

Å microcontroller needs a microcontroller core. EDIT: Leaving that Å in. For some reason, iOS on iPad is obsessed with autocorrecting "A" to "Å" even when using the English keyboard. It's driving me nuts.

Does the 'Å' pop up if you long press 'A'?

Re: RISC-V: They Should Have Known Better

#314

Post by hajile »

walrus01 wrote: post #26
hn_submit wrote: post #16

Why is he complaining about everything being optional in RISC-V? Isn't that the whole idea of RISC-V? The market can sort it out for themselves. RISC-V is already dominant in the MCU space despite its flaws, and many of them will be solved in due time. Most MCUs are used for dead-simple solutions, like electric blankets and microwaves with segment displays or LEDs. Whether their interrupts are handled in 44 or 22 cyc…

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

How can you use consistency and SSE/AVX in the same sentence?

SSE has inconsistencies like SSE4.x vs SSE4a. AVX is an even more mixed bag. There are some 19 AVX-512 extensions and ZERO chips support all of them.

The situation is so bad that AMD and Intel got together to make AVX10 to unify everything. That seemed great, but Intel now has AVX 10.1 and 10.2 in addition to the base set, so there we go again...

x86 is a massive battleground with tons of competing extensions like FMA3 vs FMA4 (why did FMA3 win???) and in cases where one of the competing variants didn't win, we get something like virtualization extensions being completely different between Intel and AMD. There's also the rash of security extensions that have gone through various support and dropped support (not to mention using some of this stuff for market segmentation and further fragmenting the ecosystem).

x86 is anything but consistent if you look into its history (or even it's present).

Re: RISC-V: They Should Have Known Better

#315

Post by pseudohadamard »

adrian_b wrote: post #238
dreamcompiler wrote: post #138

Earlier quoted context omitted.

> it still is a much better starting point than coming up with your own bespoke ISA 5 years ago I would have agreed with this but now I'm not so sure. We live in an era where you can tell a robot "Here's some C code. Design a 64-bit ISA, write the Verilog to implement it in an FPGA, write a C compiler for it, and use it to compile the C code I showed you earlier." And now your ISA and your compiler are part of your m…

Designing a good 64-bit ISA, much better than RISC-V, is easy. There are thousands of people who could design such an ISA in a couple of weeks, without any AI assistance. The hard part, which has always been the moat of RISC-V, is writing all the required support software for a new ISA, i.e. all the utilities from binutils (assembler, static linker, ELF/DWARF utilities), compiler backends at least for gcc and llvm, d…

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 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. And if I don't mind going with Chinese suppliers there's no licensing to Arm being paid anyway.

Apart from being able to thumb your nose at Arm, I just can't see what the point of RISC-V is. Is that really all there is going for it?

Re: RISC-V: They Should Have Known Better

#316

Post by dismalaf »

pocksuppet wrote: post #305
dismalaf wrote: post #199

Earlier quoted context omitted.

> but it is far from a solid pro-grade OS in a lot of areas... Insane take given all the things that run on Linux...

It's server-grade. Not desktop-grade.

Tell that to Valve or the millions who use it as a desktop.

Also, have you used Windows recently?

Re: RISC-V: They Should Have Known Better

#317

Post by phire »

brucehoult wrote: post #182
imtringued wrote: post #170

Earlier quoted context omitted.

And even if you go to those extremes, the biggest nay sayer says the cost of the design flaw will require you to double the number of decoders, which hardly sounds like a big deal to me.

It's not even double, because half of them are RVC-only decoders.

The annoying thing about RVC is that 32-bit instructions can now appear misaligned. I would be far less annoyed about RVC if it didn't break alignment, as you could solve the problem with a bunch of RVC-only decoders at the misaligned offsets.

So you either need (almost) double the number of full decoders, or a length decode and a bunch of shifters to get each decoder the right input bits (which get larger the wider the front end is. The 8th instruction can be at one of 7 possible offsets)

Re: RISC-V: They Should Have Known Better

#318

Post by LukeShu »

ACCount37 wrote: post #292
aurelian15 wrote: post #236

Earlier quoted context omitted.

I think the GP is talking about the Hazard3 [1] core. This is one of the CPU cores besides the ARM M33 instantiated on the RP2350 µC [2]. See this article from Luke Wren (Wren6991) back when the RP2350 came out [3]. [1] https://github.com/Wren6991/Hazard3 [2] https://www.raspberrypi.com/products/rp2350/ [3] https://www.raspberrypi.com/news/risc-v-on-raspberry-pi-pico...

What I find interesting is that RP2350 is designed as "one or the other", no way to use ARM and RISC-V concurrently, and has fuses that can kill ARM M33 cores outright. Makes me wonder if an "ARM cores fused off, RISC-V only, no ARM fees" SKU is possible.

Several of the peripherals in the RP2350 are also ARM IP.

Re: RISC-V: They Should Have Known Better

#319

Post by hajile »

IshKebab wrote: post #25
__d wrote: post #11

So … use RISC-V as the strawman, and create a community-based RISC-6 that doesn’t have these weaknesses? Better to get in now before it becomes too solidly entrenched.

Likely impossible unless you somehow come up with something vastly better (unlikely). None of these things are remotely bad enough to make the downsides of using another ISA palatable.

How about EPIC-esque packet-based instructions?

64-bit instructions with 4 bits indicating instruction formats (60-bit, two 40+20-bit variants, 30+30-bit, 20+20+20-bit, three 30+15+15-bit variants, and 15+15+15+15-bit). Have each larger instruction type be a strict superset of the smaller instructions, but with larger immediates, more registers, and maybe additional instruction formats (eg, for SIMD).

Something like that would be even easier to decode (converting short instructions to long is simply a bit of wiring). Instruction density should increase due to 20-bit instruction type. Having properly-aligned instructions would help with fetching performance. Larger instructions means you can jump 4x further with the same immediate and 16-bit offsets. No need to have some of the V extension workarounds (from not wanting to add 48-bit instructions).

Re: RISC-V: They Should Have Known Better

#320

Post by zephen »

IcyWindows wrote: post #136
hn_submit wrote: post #111

Earlier quoted context omitted.

x86 is basically one big cabinet of horrors, but people seem to put up with it because it's "the standard." Then why not with RISC-V? Which is much if not infinitely better.

The article explains why it's worse

The article explains why the author believes it's worse.
Post reply on HN