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

301–310 of 467 posts

Re: RISC-V: They Should Have Known Better

#301

Post by userbinator »

spicyjpeg wrote: post #67
wren6991 wrote: post #43

RISC-V is... fine. It satisfies my two requirements for an ISA as a hobby CPU designer, which are: 1. Supported in mainline LLVM and GCC. 2. I can implement it without lawyers sending me a love letter. Everything else, I can fix in post. There are enough good ideas spread across the extensions that I can assemble a reasonably put-together, curated embedded ISA with competitive performance and code density that admits…

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 of them are somewhat MIPS/RISC-V-ish anyway...)

I do think 8051 is better when you don't need 32 or even 16 bits. Even 4-bit MCUs are still around in ultra-low-cost ultra-high-volume products, which is to say RISC-V is, as you said, just a different flavour of MIPS with very similar tradeoffs.

Re: RISC-V: They Should Have Known Better

#302

Post by wren6991 »

AlotOfReading wrote: post #269
aappleby wrote: post #223

Having written a few RISC-V cores, worked on a chip design project that used RISC-V cores, and generally being OK with the architecture in real-world use cases: What the heck is this guy's problem? Just about every thing he mentioned as a problem is not a problem in practice. Too many options? Who cares, you're not trying to write code that runs on every possible configuration. Either you're writing embedded firmware…

Either you're writing embedded firmware and know exactly what core you're using, or you're writing an application that runs in an operating system and that system has a minimum ABI like RVA20 or whatever. It's very common for embedded teams these days to support a diverse set of cores with a shared codebase, depending on the specific requirements of different products/systems. SoC vendors will often change cores betw…

> If one of your vendor blobs was specified for the old system and the new system is "similar", you'll just link it in and see what happens.

And what if that blob has instructions your new core just doesn't implement? This problem has nothing to do with overlap.

Re: RISC-V: They Should Have Known Better

#303

Post by pertymcpert »

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…

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.

Re: RISC-V: They Should Have Known Better

#304

Post by AlotOfReading »

wren6991 wrote: post #302
AlotOfReading wrote: post #269

Earlier quoted context omitted.

Either you're writing embedded firmware and know exactly what core you're using, or you're writing an application that runs in an operating system and that system has a minimum ABI like RVA20 or whatever. It's very common for embedded teams these days to support a diverse set of cores with a shared codebase, depending on the specific requirements of different products/systems. SoC vendors will often change cores betw…

> If one of your vendor blobs was specified for the old system and the new system is "similar", you'll just link it in and see what happens. And what if that blob has instructions your new core just doesn't implement? This problem has nothing to do with overlap.

Then it crashes in a nice, obvious way as soon as you execute one of them? Illegal instructions aren't usually that hard to debug unless they're related to memory safety issues.

Re: RISC-V: They Should Have Known Better

#305

Post by pocksuppet »

dismalaf wrote: post #199
api wrote: post #190

Earlier quoted context omitted.

Linux is decent for its core use cases, but it is far from a solid pro-grade OS in a lot of areas... and in the areas it did get there, it took a long time to get there.

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

Re: RISC-V: They Should Have Known Better

#306

Post by password4321 »

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.

That autocorrect business would be a great modern technology prank to do to someome on purpose.

Re: RISC-V: They Should Have Known Better

#307

Post by indrora »

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…

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

Re: RISC-V: They Should Have Known Better

#308

Post by panic »

atomicUpdate wrote: post #145

It’s kind of funny that all of the complaints about optionality apply equally to Vulkan. Google even created the same profile solution with “Android Vulkan Profiles (AVP)”. I suspect Vulkan suffers from the same design by committee problem, which similarly caused it to miss seemingly basic features in the base spec that then need to be filled in with extensions and also made it too difficult for developers to want to…

Wayland too!

Re: RISC-V: They Should Have Known Better

#309

Post by inigyou »

password4321 wrote: post #306
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.

That autocorrect business would be a great modern technology prank to do to someome on purpose.

Auto Incorrect, or for short, AI.

Re: RISC-V: They Should Have Known Better

#310

Post by inigyou »

pyvpx wrote: post #237
creato wrote: post #218

Earlier quoted context omitted.

If that's really all it takes, then it is not much of a moat.

In the set of all possible working implementations, there are one or more that are novel enough to become a moat legally or otherwise. If everyone has the same power (number of tokens) then capability (experience and understanding) becomes the differentiator to “find” that moat first.

If everyone has equal ability to build a moat, it's not a moat.
Post reply on HN