Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What is RISC-V and why it matters to Canonical

ubuntu.com

Post reply on HN
Print view View original

61–70 of 129 posts

Re: What is RISC-V and why it matters to Canonical

#61

Post by bsder »

storus wrote: post #31

Will RISC-V end up with the same (or even worse) platform fragmentation as ARM? Because of absence of any common platform standard we have phones that are only good for landfill once their support lifetime is up, drivers never getting upstreamed to Linux kernel (or upstreaming not even possible due to completely quixotic platforms and boot protocols each manufacturer creates). RISC-V allows even higher fragmentation…

> Will RISC-V end up with the same (or even worse) platform fragmentation as ARM?

Sadly, yes. RISC-V vendors are repeating literally every single mistake that the ARM ecosystem made and then making even dumber ones.

Re: What is RISC-V and why it matters to Canonical

#62

Post by topspin »

wk_end wrote: post #36
mikestorrent wrote: post #25

Earlier quoted context omitted.

x86_64 machines are RISC under the hood and have been for ages, I believe; microcode is translating your x64 instructions to risc instructions that run on the real CPU, or something akin to that. RISC never died, CISC did, but is still presented as the front-facing ISA because of compatibility.

That's a common factoid that's bandied about but it's not really accurate, or at least overstated. To start, modern x86 chips are more hard-wired than you might think; certain very complex operations are microcoded, but the bulk of common instructions aren't (they decode to single micro-ops), including ones that are quite CISC-y. Micro-ops also aren't really "RISC" instructions that look anything like most typical RI…

That's an excellent rebuttal to this common factoid.

Recently I encountered a view that has me thinking. They characterized the PIO "ISA" in the RPi MCU as CISC. I wonder what you think of that.

The instructions are indeed complex, having side effects, implied branches and other features that appear to defy the intent of RISC. And yet they're all single cycle, uniform in size and few in number, likely avoiding any microcode, and certainly any pipelining and other complex evaluation.

If it is CISC, then I believe it is a small triumph of CISC. It's also possible that even characterizing it as and ISA at all is folly, in which case the point is moot.

Re: What is RISC-V and why it matters to Canonical

#63

Post by MobiusHorizons »

hajile wrote: post #33
storus wrote: post #31

Will RISC-V end up with the same (or even worse) platform fragmentation as ARM? Because of absence of any common platform standard we have phones that are only good for landfill once their support lifetime is up, drivers never getting upstreamed to Linux kernel (or upstreaming not even possible due to completely quixotic platforms and boot protocols each manufacturer creates). RISC-V allows even higher fragmentation…

RVA23 is the standard target for compilers now. If you support newer stuff, it’ll take a while before software catches up (just like SVE in ARM or AVX in x86). If you try to make your own extensions, the standard compiler flags won’t be supporting it and it’ll probably be limited to your own software. If it’s actually good, you’ll have to get everyone on board with a shared, open design, then get it added to a future…

Compiling the code is not the issue. The hard part is the system integration. Most notably the boot process and peripherals. It's not actually hard to compile code for any given ARM or x86 target. Even much less open ecosystems like IBM mainframes have free and open source compilers (eg GCC). The ISA is just how computation happens. But you have to boot the system, and get data in and out for the system to be actually useful, and pretty much all of that contains vendor specific quirks. Its really only the x86 world where that got so standardized across manufacturers, and that was mostly because people were initially trying to make compatible clones of the IBM PC.

Re: What is RISC-V and why it matters to Canonical

#64

Post by popcornricecake »

ddtaylor wrote: post #23

I stopped listening to what Canonical says. They often get involved in things and disturb the ecosystem then abandon stuff or dig a "not invented here" hole. Unity, Bazaar, Mir, Upstart, Snap, etc. All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.

Ubuntu Touch... I was so excited about it that I bought one of the phones with it preloaded. I even used it as my sole daily driver for months, until I learned that I was not receiving all calls made to me. Even after that I kept hoping it would keep developing so that I could pick it up again one day. But then Canonical abandoned it instead. That's when they became as good as dead to me.

Re: What is RISC-V and why it matters to Canonical

#65

Post by LeFantome »

hajile wrote: post #40
indolering wrote: post #34

Earlier quoted context omitted.

The answer is unequivocally yes: RISC-V is designed to be customizable and a vendor can put whatever they like into a given CPU. That being said, profiles and platform specs are designed to limit fragmentation. The modular design and core essential ISA also makes fat binaries much more straight-forward to implement than other ISAs.

You can choose to develop proprietary extensions, but who’s going to use them? A great case study is the companies that implemented the pre-release vector standard in their chips. The final version is different in a few key ways. Despite substantial similarities to the ratified version, very few people are coding SIMD for those chips. If a proprietary extension does something actually useful to everyone, it’ll either…

Yes, extensions are perfect for embedded. But not just there.

Extensions allow you to address specific customer needs, evolve specific use cases, and experiment. AI is another perfect fit. And the hyperscaler market is another one where the hardware and software may come from the same party and be designed to work together. Compatibility with the standard is great for toolchains and off-the-shelf software but there is no need for a hyperscaler or AI specific extension to be implemented by anybody else. If something more universally useful is discovered by one party, it can be added to a future standard profile.

Re: What is RISC-V and why it matters to Canonical

#66

Post by ddtaylor »

popcornricecake wrote: post #64
ddtaylor wrote: post #23

I stopped listening to what Canonical says. They often get involved in things and disturb the ecosystem then abandon stuff or dig a "not invented here" hole. Unity, Bazaar, Mir, Upstart, Snap, etc. All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.

Ubuntu Touch... I was so excited about it that I bought one of the phones with it preloaded. I even used it as my sole daily driver for months, until I learned that I was not receiving all calls made to me. Even after that I kept hoping it would keep developing so that I could pick it up again one day. But then Canonical abandoned it instead. That's when they became as good as dead to me.

Sadly, KDE and Gnome each spent a lot of time on the same things. Plasma Mobile has ate more time that could have went into making Plasma a better desktop.

Re: What is RISC-V and why it matters to Canonical

#67

Post by MobiusHorizons »

avadodin wrote: post #58
topspin wrote: post #14

Earlier quoted context omitted.

"It is Chinese companies looking for ARM alternative" The V in RISC-V represents iteration of the ISA, over the last 46 years, most of which occurred in the US, mainly at Berkeley.

They push it to save a couple nickels per core on the ARM licenses, not out of nationalistic fervor. And it is the Chinese doing it because virtually 100% of all chips are made in China and Taiwan.

That's not really how it works. There are only a few companies on the planet that are licensed to create their own cores that can run ARM instructions. This is an artificial constraint, though and at present China is (as far as I know) cut off from those licenses. Everyone else that makes ARM chips is taking the core design directly from ARM integrating it with other pieces (called IP) like IO controllers, power management, GPU and accelerators like NPUs to make a system on a chip. But with RISC-V lots of Chinese companies have been making their own core designs, that leads to flexibility with design that is not generally available (and certainly not cost effective) on ARM.

Re: What is RISC-V and why it matters to Canonical

#68

Post by ddtaylor »

loloquwowndueo wrote: post #51
ddtaylor wrote: post #23

I stopped listening to what Canonical says. They often get involved in things and disturb the ecosystem then abandon stuff or dig a "not invented here" hole. Unity, Bazaar, Mir, Upstart, Snap, etc. All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.

The project bzr was trying to uproot may not be the one you’re thinking of. First release of Bzr predates git by about a month.

Correct, and I used bzr quite a bit during that time. It was interesting in some ways, but Canonical pushed it for many years after git was obviously the better choice.

Even to this day there is a complex and archaic process of using Launchpad where git is tacked on because they stuck with Bazaar for so long.

Re: What is RISC-V and why it matters to Canonical

#69

Post by LeFantome »

stuxnet79 wrote: post #10

Not my area of expertise but what exactly is the difference between RISC-V and Power PC? Didn't Power-PC get a good run in the 90s and 2000s? Just wondering why there's renewed interest in RISC-like architectures when industry already had a good exploration of that area.

There are many more RISC chips than not. Apple Silicon is RISC. All ARM is RISC (eg. Raspberry Pi).

Re: What is RISC-V and why it matters to Canonical

#70

Post by LeFantome »

invalidator wrote: post #35
stuxnet79 wrote: post #10

Not my area of expertise but what exactly is the difference between RISC-V and Power PC? Didn't Power-PC get a good run in the 90s and 2000s? Just wondering why there's renewed interest in RISC-like architectures when industry already had a good exploration of that area.

The interest is BECAUSE it's well explored territory. The concept is proven and works fine. On the low end where RISC-V currently lives, simplicity is a virtue. On the high end, RISC isn't inherently bad; it just couldn't keep up on with the massive R&D investment on the x86 side. It can go fast if you sink some money into it like Apple, Qualcomm, etc have done with ARM.

ARM is RISC and dominates x86 in most markets.

In 2026, RISC-V is not what I would call “low end”. Look up the P870-D, or Ascalon, it C950.

Do you think Apple spends more money than Intel on chip design?

Post reply on HN