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

391–400 of 467 posts

Re: RISC-V: They Should Have Known Better

#391

Post by Neywiny »

inigyou wrote: post #379
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?

No. That's also partially in the article. But even in ones that do, usually it's a subset. In arm-m, some registers get stacked on interrupt (basically the caller saved ones in the ABI so any regular functio is automatically IRQ compatible). In this implementation, 64 registers do. Very different from I think it's r0-r3, lr, and pc. Some architectures bank them, so as long as you don't nest or call functions you can just use the interrupt bank.

RV actually allows for that. But not dictating that registers get pushed to the stack, flexibility in how you manage them opens up. So for RV, and some other architectures, you have to mark the function an IRQ and the compiler will know how to figure that out.

Another gotcha is that for AXI and other burst interfaces, the hardware being able to say "I'm going to send you X words" is dramatically better for latency than each one being a single transaction. So if your stack is in a location that requires multi-cycle memory access times, this balloons in timing cost.

Sadly this is a very hard topic to condense into a few sentences. Maybe if I wrote an article on it with graphics it would help. Unsure

Re: RISC-V: They Should Have Known Better

#392

Post by dzaima »

camel-cdr wrote: post #387
dzaima wrote: post #381

Earlier quoted context omitted.

Some stats on an aarch64 binary of my current main project (1.6MB .text, 6600 symbols as per whatever "nm the-binary | wc -l" includes, from "objdump -d the-binary"): 19546 /tbn?z/ 18029 /tbn?z.*, #0x0/ (but this includes boolean checks) 224 /tbn?z.*, #0x1f/ (i.e. 32-bit x Said project doesn't do fixed bitfields much (there are some, but a chunk of those test multiple bits) so unsurprisingly not much. (I could imagin…

Did a quick grep over object files of a half build defconfig kernel: total: 15510 #0: 3720 #31: 2247 #1: 1349 #21: 1208 #2: 810 #3: 524 #8: 493 ...

That is quite a good bit more evenly-spread (the "..." is 5159 instrs).

Wonder what's up with bit 21; if whatever uses it so much is repositionable (and not an aarch64-specific thing), could save like 2KB on x86-64 via putting it in the low 8 bits instead.

Re: RISC-V: They Should Have Known Better

#393

Post by snapplebobapple »

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…

How many people are working on this in your couple years example? Is that just one guy or a team of 20 or something else? Whats the average salary for the team *n this scenario?

Re: RISC-V: They Should Have Known Better

#394

Post by lenocinor »

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.

You can add a correction going the other way and it may fix the problem (it did for me for a similar problem, anyway) in Settings -> General -> Keyboard -> Text Replacement. Try replacing “Å” with “A”, or “A” with “A”, and see if that helps.

Re: RISC-V: They Should Have Known Better

#395

Post by izacus »

inigyou wrote: post #380
pulse7 wrote: post #367

So it's mostly the "Optionality". Like USB. And yet USB is everywhere...

And USB-C is known as a compatibility mess.

Is it though? Is it really? Outside the HN rant circles which want to return back to times where you needed an adapter for every single laptop model or be shit out of luck for connecting your mouse or projector?

Re: RISC-V: They Should Have Known Better

#396

Post by fidotron »

bigyabai wrote: post #288
brcmthrowaway wrote: post #15

It's clear that RISC-V started as an academic exercise (albeit from a group with esteemed credentials) and they had to bolt on these hacks to make it work in industry. Sad.

ARM was also rooted in an academic exercise. A lot of the drawbacks for modern ARM PC platforms stem from the aversion to actually advanced features like SVE/SVE2 and UEFI. It's sad, but it was also wildly successful. RISC-V has already replaced ARM in highly-custom embedded spaces like Nvidia's GPU controllers, and it likely won't stop unless ARM finally changes their tune vis-a-vis licensing.

> ARM was also rooted in an academic exercise.

Where do people get ideas like this from? Just nonsense.

Re: RISC-V: They Should Have Known Better

#397

Post by bee_rider »

dofm wrote: post #286
ChuckMcM wrote: post #243

Earlier quoted context omitted.

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

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

What’s far from optimal about open source? Open source seems like a window into another universe, which is just lightly better than ours: people just working on problems and sharing solutions, because humans are basically good social creatures that enjoy solving problems. To the extent to which there are issues like the difficulty of funding open source projects: our society is wrong, not open source.

Re: RISC-V: They Should Have Known Better

#398

Post by renox »

hajile wrote: post #319
IshKebab wrote: post #25

Earlier quoted context omitted.

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…

So a VLIW, interesting but usually compressed instructions are at most two-registers..

Re: RISC-V: They Should Have Known Better

#399

Post by remexre »

amluto wrote: post #213
wren6991 wrote: post #203

Earlier quoted context omitted.

> The fact that the relevant CPU features can’t even be enumerated in user mode just makes it worse. User-mode feature detection is usually used to select paths for acceleration instructions, like SIMD or crypto. The overlapping RISC-V instructions don't fit in that category: they're compressed versions of basic functions, mostly used in epilogs/prologs, which would be unconditionally compiled in. There are no overla…

At least with user-mode feature detection there could be an assertion that the correct feature set is present.

Doesn't the ELF loader do that?

Re: RISC-V: They Should Have Known Better

#400

Post by corndoge »

josephg wrote: post #298
ChuckMcM wrote: post #243

Earlier quoted context omitted.

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

> Perhaps the most interesting thing is that RISC-V shows just how ISA agnostic people are Of course! Most people in the computing world work way higher up the ladder of abstraction. I suspect a small minority of working software engineers know what an ISA even is. I did some contract work in web development for a time. It is staggering how few people understand how the javascript they write gets executed on the mach…

What's next? Programming Javascript without understanding Javascript??
Post reply on HN