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

371–380 of 467 posts

Re: RISC-V: They Should Have Known Better

#371

Post by phire »

Someone wrote: post #263
phire wrote: post #112

Earlier quoted context omitted.

And personally, I'm not even sure it crosses that bar. RISC-V somehow manages to be more fragmented than x86 (which is impressive), and just can't compete on instruction density. I think a large part of the issue with RISC-V is that it predates (public knowledge of) ARMv8 by a year or two, so it couldn't use it as inspiration. If you compare RISC-V to 32-bit ARM, the comparisons are much more favourable.

> think a large part of the issue with RISC-V is that it predates (public knowledge of) ARMv8 by a year or two Does it? https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p... has a section on ARMv8 (section 2.5) It says they became aware of it a year after they started the RISC-V project, but that’s five years before that paper was published.

2015 is when it started to gain steam as a community run project.

But version 1.0 of the spec [1] was released all the way back in May 2011, and the first RISC-V chip was taped out at the same time. This is 5 months before ARMv8 was even announced, and we didn't start seeing actual aarch64 chips until late 2013.

And TBH, I'm not sure anyone realised just how good of an ISA aarch64 is until quite a bit later.

RISC-V 1.0 isn't binary compatible with modern RISC-V, they hadn't frozen the encoding, but rough design is all there.

[1] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/Archive/EE...

Re: RISC-V: They Should Have Known Better

#372

Post by krunkcoin »

Permik wrote: post #343
phire wrote: post #335

Earlier quoted context omitted.

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…

By the time you have an out-of-order core You're thinking too high level and high performance/high power use -- think about minimal embedded controllers, no need to add the complexity of O3 exe, but there's still the possibility of getting to optimize the hazards and execution without the shared state. Doing the deliberate choice of leaving flags out of the core and then using them in the fp ops ext will nudge design…

Without knowing it, you're thinking at neither high nor low level. You've accepted at face value claims made by RISC-V architects about how to design an ISA for low level embedded controllers, but they weren't actual experts in that field. Instead, they were largely academics.

When you read their stuff, they're constantly overestimating the value of ultra-minimalist CPU designs in the modern context. In fact, they often show little understanding of the real impact of ISA design decisions on implementation complexity, so some of their decisions don't even make sense as minimalist decisions.

To expand on the low value of minimalism: even in trailing edge process nodes, if you're designing something on the scale of a simple single-issue in-order 32-bit RISC core targeting no particular frequency, gates are essentially free. The RISC-V guys are badly out of touch. If minimum gate count mattered as much as they think it does, there would still be a thriving market for 8-bit microcontrollers. Instead, they're steadily losing market share to 32-bitters, even in applications where an 8-bit µC would be more than enough. It's not the 1980s, you don't have to struggle to fit a featureful 32-bit core into a single die anymore, but they're hellbent on relitigating that era's debates.

Re: RISC-V: They Should Have Known Better

#373

Post by deepsun »

> So what does it even mean to comply with the spec then, if everything is optional?

Similarly, I kept saying it for long that a file/wire format's usefulness is not in what it supports, but in what it forbids. A binary file supports any type of data, but it's not useful.

Re: RISC-V: They Should Have Known Better

#374

Post by phire »

camel-cdr wrote: post #368
phire wrote: post #335

Earlier quoted context omitted.

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.

Yeah... I more mean that it shouldn't add much design and verification complexity. You are mostly just reusing mechanisms you already need. Nor should it negatively impact FMAX. And I suspect the area cost is reasonably low (but not zero)

The lack of flags on those ALUs probably tells us more about the lengths CPU designers will go for reasonably small savings than it tells us about how much flags actually costs. And it's probably more of a "our metrics never gave us enough justification to even consider adding flags to the extra three ALUs" than "we considered it, but the cost was too high".

Re: RISC-V: They Should Have Known Better

#375

Post by benj111 »

riversflow wrote: post #355
pertymcpert wrote: post #303

Earlier quoted context omitted.

Not sure why you had to take a pop at Greggs there. Nothing wrong with a hot sausage roll at all. Assuming you can find a hot one.

you should review the data on processed meat. It's one of the least healthy things you can eat.

Do Greggs sausage rolls even contain meat?

Re: RISC-V: They Should Have Known Better

#376

Post by phire »

exmadscientist wrote: post #339
indrora wrote: post #307

Earlier quoted context omitted.

> Designing a good 64-bit ISA [...] is easy [...] could design such an ISA in a couple of weeks Let me know when you've got it all worked out and published. Should be easy, right?

It is the easy part. Four weeks is plenty of time. That's why it's so bizarre that the RISC-V design is so awful . The hard part is the software support side (though, as comments elsewhere in the thread point out, AI is pretty helpful there) and then those lovely pieces like specifying the precise behavior of interrupts. If it had a snowball's chance in hell of going in to any kind of production anywhere, I'd have no…

> That's why it's so bizarre that the RISC-V design is so awful.

Not bizarre.

The design is a direct result of the biases of its initial designers, and its original intended use-case. And TBH, if you assess it by its original design criteria, it's actually pretty good.

It's just by the time RISC-V had escaped containment and was starting to become a general purpose open ISA, it was a little too late to start from the beginning and consider what the correct design criteria should even be.

Re: RISC-V: They Should Have Known Better

#377

Post by ACCount37 »

chicken-stew wrote: post #354
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:…

I thought cortex-m0 was taking over that slice of the pie.

Not really. Before RISC-V, the low end was held firmly by 8051, and at the high end, it was a fight between Xtensa, ARC, M0, and "others", be that custom ISAs or something like legally distinct MIPS.

Now, both ends have RISC-V seeping into them.

Re: RISC-V: They Should Have Known Better

#379

Post by inigyou »

Neywiny wrote: post #133

I think I get it. I've tried microblaze-v for a while now. And just look at their interrupt handler. https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/sta... . With the FPU enabled at compile time, that's > 128 memory ops per interrupt. That's insane, especially without an NVIC and chaining and all that. My latency was astronomical, and my maximum interrupt frequency was pitiful. Ended up doing the work (sw an…

Don't you have to save registers on any architecture, or not use them in the interrupt handler?
Post reply on HN