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

361–370 of 467 posts

Re: RISC-V: They Should Have Known Better

#361

Post by wren6991 »

adastra22 wrote: post #311
wren6991 wrote: post #193

Earlier quoted context omitted.

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…

> C -> "ZcfZcdZca" just by itself is insanity

Separating the float load/stores from the rest of the compressed ISA is insanity? Why?

> Now I can't make vendor-independent RISC-V code

I think this is what RVA23 is for. Any system running shrinkwrapped binaries is going to have vanilla RVC.

I agree there is some insane stuff going on in RISC-V. Like when the double-trap spec was in public review I popped my head in to say "hi, this seems to break all existing code that uses nested interrupts because the condition is overly broad" and the spec maintainer said words to the effect of "yes, it's supposed to do that."

This is not that weird, though? Float load/store should never really have been included in the C extension, but we can't revise the C extension. So, define an extension for "C: the good parts", aka Zca, and separate extensions for float load/store (two of them because F and D are separate). Ideally we wouldn't have made the mistake in the first place, but what would have been a better way to redact it?

Re: RISC-V: They Should Have Known Better

#362

Post by phire »

camel-cdr wrote: post #360
phire wrote: post #357

Earlier quoted context omitted.

Really? Interesting. Though, I guess fusing after cracking makes things easier because you don't actually have to search for fusion candidates (supported by the fact that Apple's Firestorm doesn't seem to make any effort to fuse things that aren't alu + branch, crypto, or amx)

Edit: removed Yeah, fusing is probably easier, if you already know what to fuse. On the other hand, if you want to fuse load pair on RISC-V you have the entire rename stage to figure out which uops can be fused independently of the rename stage, if fusion haopens after rename as well.

You shouldn't be sharing that.

Despite my curiosity, I explicitly refused to agree to Apples terms for accessing those documents, because they were very draconian. The terms absolutely forbids using the information for anything other than optimising software for apple devices.

Discussing the design tradeoffs of RISC-V μarches couldn't be further from "optimising software for apple's devices".

Re: RISC-V: They Should Have Known Better

#363

Post by brucehoult »

skew-aberration wrote: post #329
userbinator wrote: post #301

Earlier quoted context omitted.

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

C-Sky and Andes NDS32 were popular enough to be supported by both GCC and the Linux kernel, both switched to RISC-V. ESP32 switched to RISC_V for all new chips.

Interestingly Synopsys's ARC's latest version ARC-V is RISC-V.

I think all major FPGA vendors now offer fully supported RISC-V soft cores either alongside their older proprietary ISAs or as the latest upgrade. Several (e.g. Microchip and Gowin) have included real RISC-V cores inside FPGAs.

Re: RISC-V: They Should Have Known Better

#364

Post by camel-cdr »

phire wrote: post #362
camel-cdr wrote: post #360

Earlier quoted context omitted.

Edit: removed Yeah, fusing is probably easier, if you already know what to fuse. On the other hand, if you want to fuse load pair on RISC-V you have the entire rename stage to figure out which uops can be fused independently of the rename stage, if fusion haopens after rename as well.

You shouldn't be sharing that. Despite my curiosity, I explicitly refused to agree to Apples terms for accessing those documents, because they were very draconian. The terms absolutely forbids using the information for anything other than optimising software for apple devices. Discussing the design tradeoffs of RISC-V μarches couldn't be further from "optimising software for apple's devices".

> You shouldn't be sharing that

Ah, I suppose.

Re: RISC-V: They Should Have Known Better

#365

Post by pavlov »

jurgenburgen wrote: post #347
pavlov wrote: post #220

Earlier quoted context omitted.

Patents only last 20 years. If you build your architecture on ideas that are documented to be older than twenty years, it greatly reduces the risk that a patent holder comes from nowhere: even if they did have the patent, it would have expired.

How quickly does the industry move? Would there be any value in a 2006-era instruction set? How would you even start making sure you didn’t infringe on any patents that came after 2006?

The first version of RISC-V was released in 2010. It was based on work done at Berkeley in the 1980s (RISC versions one to four).

One reason that RISC-V has so many optional extensions is that you can trust the core is very likely to be patent-free (because everything in it is documented to be older than 20 years) and just evaluate the extensions you need.

Re: RISC-V: They Should Have Known Better

#366

Post by camel-cdr »

brucehoult wrote: post #341
boredatoms wrote: post #266

Earlier quoted context omitted.

I cant see debian remaining on rv64gc later on when enough rva23 boards are purchasable

Why? It'll still run fine. Just like Debian still runs on original x86-64-v1 from 1999, not x86-64-v3 (needs AVX2,FMA, BMI1, BMI2, LZCNT) or even x86-64-v3 (needs AVX-512). Similarly, Debian for arm64 still requires only ARMv8.0-A from 2011 not even ARMv8.2-A (everything from A75/A55 to A78/N1/V1) let alone ARMv9-A (A710, A510, X2 and on). Why would they do in the RISC-V world what they totally haven't done in amd64…

No, debian requires ARMv8.0-A + FP + NEON, as those are optinal extensions (even optional in ARMv9.0-A)

Re: RISC-V: They Should Have Known Better

#368

Post by camel-cdr »

phire wrote: post #335
wk_end wrote: post #245

Earlier quoted context omitted.

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.

I don't agree with the argument. By the time you have an out-of-order core, there is already so much shared state you have to synchronise, and you have a bunch of complex mechanisms for dealing with it. Adding a flags register doesn't really add any more complexity, it's just a small bit of extra state attached to it. And we already have the solution, it's register renaming. We are already renaming all the GPRs and F…

> Adding a flags register doesn't really add any more complexity, it's just a small bit of extra state attached to it.

I agree in general, we do however see that the cost of flags isn't free by the fact that most modern Arm processors only support ADCS on half of the ALUs supporting ADD. If it was free/negligible, you would see ADCS support on all ALUs.

Re: RISC-V: They Should Have Known Better

#369

Post by phire »

camel-cdr wrote: post #360
phire wrote: post #357

Earlier quoted context omitted.

Really? Interesting. Though, I guess fusing after cracking makes things easier because you don't actually have to search for fusion candidates (supported by the fact that Apple's Firestorm doesn't seem to make any effort to fuse things that aren't alu + branch, crypto, or amx)

Edit: removed Yeah, fusing is probably easier, if you already know what to fuse. On the other hand, if you want to fuse load pair on RISC-V you have the entire rename stage to figure out which uops can be fused independently of the rename stage, if fusion haopens after rename as well.

> On the other hand, if you want to fuse load pair on RISC-V you have the entire rename stage to figure out which uops can be fused independently of the rename stage

That's a good point.

If some RISC-V μarch was going to invest the extra gates for a complex fusion setup, the search isn't actually going to slow anything down, as it can run in parallel with other frontend operations (like renaming).

I always just assumed fusion was done as early as possible, only considering instructions that are right next to each-other (that's certainly the intent of the RISC-V spec), and then resolved immediately after decode.

But maybe it's better to do it right at the end of the front end; After renaming, during insertion into the scheduler.

Re: RISC-V: They Should Have Known Better

#370

Post by petra »

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…

China is different - the state probably has impact on cpu/mcu vendor selection.
Post reply on HN