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

351–360 of 467 posts

Re: RISC-V: They Should Have Known Better

#351

Post by phire »

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…

If the spec was only arguing that avoiding flags allowed for simpler implementation of minimal in-order pipelines... I might actually agree with it.

But the argument in the spec explicitly uses the "added complexity to out-of-order microarchitectures" as a part of the justification for not having conditional move (and flags). It's the most commonly parroted part of the argument (see above) and the part of the argument I'm responding to.

I actually agree with much of the spec's argument. The cost of not having flags is pretty low, the MIPS approach does work pretty well, and it does simply things.

I'm just not sure it was the right trade off, and I strongly disagree with its attempt to use OoO cores as part of the justification.

Re: RISC-V: They Should Have Known Better

#353

Post by lmz »

jurgenburgen wrote: post #346
pseudohadamard wrote: post #315

Earlier quoted context omitted.

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 in…

> 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. How expensive is it to license the instruction set so you can expand it?

Surely those expanding the instruction set do not fall into "most users"?

Re: RISC-V: They Should Have Known Better

#354

Post by chicken-stew »

ACCount37 wrote: post #290
jack_h wrote: post #285

> What does a cheap microcontroller core need? Let's inspect what they are used for. Typical use cases are to interface with and quickly reconfigure hardware blocks in a larger chip, eg in an MP3 player, an SD card, or a USB stick. The hard work is done by custom IP and the CPU core is just there to occasionally prod a register or configure something. This is not the only reason to use a microcontroller or 75% of mic…

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.

Re: RISC-V: They Should Have Known Better

#355

Post by riversflow »

pertymcpert wrote: post #303
dofm wrote: post #286

Earlier quoted context omitted.

> Perhaps the most interesting thing is that RISC-V shows just how ISA agnostic people are To the extent that Raspberry Pi shipped a microcontroller that can literally be either RISC-V or ARM (indeed, one of each at the same time I think?) RISC-V, it seems to me, lives in that cognitive space occupied by things like: open source, open weights, C, HTML, ethernet, Greggs sausage rolls and VHS. Far from optimal, obvious…

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.

Re: RISC-V: They Should Have Known Better

#356

Post by joha4270 »

NooneAtAll3 wrote: post #325
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"?

A lot of CPUs does not execute instructions directly, but instead translate them into a second set of "uOps"

This allows it to split complex instructions into multiple operations instead of having dedicated hardware for it.

High performance cores can also do the opposite trick of "fusing" two instructions into a single uOp: The usual example is compare-and-branch

Re: RISC-V: They Should Have Known Better

#357

Post by phire »

camel-cdr wrote: post #349
phire wrote: post #344

Earlier quoted context omitted.

But imagine the code density you could get combining both strategies. > Arm uses complex instructions with multiple writeback, that require cracking, to improve code density. While smaller cores have the option of cracking the multiple writeback instructions, many arm cores just pay the extra cost of having a 3 read, 2 write register file, so they aren’t actually cracking those instructions. They do crack other instr…

> While smaller cores have the option of cracking the multiple writeback instructions, many arm cores just pay the extra cost of having a 3 read, 2 write register file, so they aren’t actually cracking those instructions. No, every high performance core I know of cracks them at decode, some re-fuse some of them after rename (Apple). Because otherwise you would need to rename up to 4 destinations per rename slot, effe…

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)

Re: RISC-V: They Should Have Known Better

#358

Post by mort96 »

dlcarrier wrote: post #313
mort96 wrote: post #300

Earlier quoted context omitted.

Å 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'?

Yes, it's one of the options there. But I'm not doing that, I'm just pressing the A key and it automatically gets transformed to Å once I hit space around 50% of the time.

Re: RISC-V: They Should Have Known Better

#359

Post by mort96 »

cuu508 wrote: post #340
mort96 wrote: post #300

Earlier quoted context omitted.

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

Isn't there a setting to turn auto-correct off?

Yes but autocorrect is on the whole useful, I'm a bit sloppy when I type on glass and it's probably correct a little bit more than it's wrong.

Actually I'm not sure if that's even true anymore. It constantly "corrects" "its" into "it's" (it even did it just now) in situations where "its" is appropriate. It corrected the "on" in "type on glass" earlier to "in". And half of my "A" gets turned into "Å" (it just happened again and I had to go back and fix it). Maybe it has gotten to a point where it's wrong more than it's right.

Re: RISC-V: They Should Have Known Better

#360

Post by camel-cdr »

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

Earlier quoted context omitted.

> While smaller cores have the option of cracking the multiple writeback instructions, many arm cores just pay the extra cost of having a 3 read, 2 write register file, so they aren’t actually cracking those instructions. No, every high performance core I know of cracks them at decode, some re-fuse some of them after rename (Apple). Because otherwise you would need to rename up to 4 destinations per rename slot, effe…

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.

Post reply on HN