Live data from Hacker News

RISC-V Is Inevitable: State of the Union Keynote Argues

eetimes.com

131–140 of 142 posts

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#131
post #120
post #100

Earlier quoted context omitted.

Major OS vendors have added loads of hardening to their C compilers. Not bounds checking specifically (because even if the overhead was only 20% that would be too high) but tons of other stuff such as: stack canaries, control flow integrity, hardened string functions, ASLR, zeroing uninitialized auto variables, forced warnings, linker hardening. These are added as standard in all decent Linux distros today. Probably…

Kind of, because to this day it has been a quixotic battle for devs to use them at scale. Those OS vendors rather push for Swift, Java/Kotlin, C#, and Rust instead. Alongside ARM MTE, Pluton, SPARC ADI. Also, all those hardening measures and lack of bounds checking could have been solved with WG14 papers, nowhere to be found. C isn't set in stone.

Those techniques are implemented by default in Fedora & Debian. You have to opt out if for some reason you don't want to use them. So almost all C software compiled in these two major distros are using all of them. (Likely in other distros too, but I'm less familiar with how they configure their compilers).

Fedora will soon implement shadow stacks across the entire C codebase: https://discussion.fedoraproject.org/t/f45-change-proposal-e...

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#132
post #12
post #10

> “CHERI is not an extension; CHERI is a new base,” Asanović clarified to the keynote audience. > Addressing concerns that creating a new base ISA might fracture the open-source community, Asanović offered a devoted defense to EE Times. “CHERI is too invasive to be a simple extension on regular RISC-V, and so needs a new base ISA for that reason,” To me it sounds like they're creating RISC-VI before RISC-V even winni…

There's zero chance CHERI will go anywhere, I wouldn't worry about it.

That is not true. Two days ago lowRISC announced that OpenTitan used in Google Chromebooks will include CHERI:

https://lowrisc.org/news/opentitan-earl-grey-2-to-support-ch...

Last year, Google announced that their Coral NPU will include CHERI:

https://developers.googleblog.com/en/introducing-coral-npu-a...

There are more cores that companies are actively working on:

X730 from Codasip https://codasip.com/solutions/riscv-processor-safety-securit...

ICENI from SCI Semiconductor: https://www.scisemi.com/products/iceni-device-family/

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#133
post #10

> “CHERI is not an extension; CHERI is a new base,” Asanović clarified to the keynote audience. > Addressing concerns that creating a new base ISA might fracture the open-source community, Asanović offered a devoted defense to EE Times. “CHERI is too invasive to be a simple extension on regular RISC-V, and so needs a new base ISA for that reason,” To me it sounds like they're creating RISC-VI before RISC-V even winni…

I've been trying to get access to CHERI for quite a while - I have a background in hardware security so was very curious to have a play. But only 'approved partners' are allowed to have access... guessing even in projects like this, Security through Obscurity still reigns.

That is not true. During the Digital Security by Design programme UKRI was shipping Morello boards to organisations that requested them. Since DSbD is over, the CHERI Alliance has taken over that initiative. You can request an Arm Morello board via the following link:

https://cheri-alliance.org/discover-cheri/cheri-products/mor...

Also, you can buy a Sonata board with CHERIoT from Mouser:

https://www.mouser.co.uk/en/ProductDetail/NewAE/NAE-SONATA-O...

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#134
post #121

Earlier quoted context omitted.

> I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance. RISC-V is an objectively bad ISA design (a resell of MIPS dropping some of the most ominous features, then trying fix the code density issue with billions of extensions), but x86 is way worse and it didn't prevent Intel from making performant implementations. And RISC-V is…

>trying fix the code density issue with billions of extensions Not sure what you're on about. By the time the spec was first ratified (2019), RV64GC was already the densest 64bit ISA, and it's not even close.

> the densest 64bit ISA

Because all other 64-bits were designed with no regard to density too. On 32-bit (and thats where density matters) it's sill worse then Thumb even with compression extension.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#135
post #129
post #119

Earlier quoted context omitted.

There's no real need for LLVM, GCC or CUDA to be memory safe. POSIX libc is of course C by definition but libc's are normally extremely well tested, and it is possible to avoid libc entirely if you want. V8 is actually a nice case for CHERI since you can easily sandbox the JIT'd code. If you were to just rewrite V8 in Rust then you wouldn't get that benefit (you can't run the borrow checker on generated assembly). I…

Why not? There are many cases where it matters, also routine CVEs show how well tested they are in practice.

Why not what? Sorry I'm not sure which bit of my comment you are responding to.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#136
post #108
post #83

Earlier quoted context omitted.

ten years is a very long time in technology, RISC-V ecosystem could be so vibrant and advanced that it might prove more cost effective for Apple just to feed off it (assuming Apple is still relevant by then). It's almost like trying to predict if the smartphone leaders in 2006 (Nokia / RIM) would want to adopt this new mobile operating system that hardly anyone uses (android) in 2016.

>ten years is a very long time in technology, 10 years is relatively short time in hardware, that is only at best 4 cycles. In today's world it is only 3 cycles. The amount of time, energy and resources required to switch from ARM to RISC-V only to save $100M a year makes very little sense. That is assuming you can get the same performance switching over in the first place. Which right now isn't the case in the next…

Well you can see from the original poster's timeline, that 10 years from now will be effectively 16 years into Apple's ARM journey, so you can add two more cycles.

And also from the timeline you can see that the average Apple hardware transition period is 2.75 cycles, so I wouldn't bet too much that their ARM journey will last more than 6 cycles.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#137
post #121

Earlier quoted context omitted.

>trying fix the code density issue with billions of extensions Not sure what you're on about. By the time the spec was first ratified (2019), RV64GC was already the densest 64bit ISA, and it's not even close.

> the densest 64bit ISA Because all other 64-bits were designed with no regard to density too. On 32-bit (and thats where density matters) it's sill worse then Thumb even with compression extension.

>On 32-bit (and thats where density matters) it's sill worse then Thumb even with compression extension.

Thumb is really good, but this is no longer true as of late 2021, when bitmanip and the code reduction extensions landed.

RISC-V is currently the most dense 64bit ISA, as well as the most dense 32bit ISA.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#138
post #130
post #81

Earlier quoted context omitted.

Right: it's not clear whether the availability of some $300 US CHERI SBCs would be enough to carry CHERI to glory, but it would obviously generate a significant pop of awareness, support and grassroots activity. For their part the antis could then transition seamlessly from "nobody wants it lol" to "all these enthusiasts are so annoying and out of touch with reality lol" as is traditional. Instead, AFAICT, the CHERI…

Mid-level technical staff don't push hardware out the door for major OS vendors, unless it is something their management already cares about.

We're talking mostly about companies which push hardware in the door, here, such as the hyperscaler types which the CHERI people have been showing slide decks to.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#139

Earlier quoted context omitted.

>This is mostly because their approach to SIMD is so different, but also because I can't test it at all. Are there any RISC-V "machines"? that one can use to do something useful or fun with that someone here could recommend? I would also be interested in RISC-V emulators etc.

QEMU. Docker, using QEMU under the hood, there automatically with Docker Desktop on Mac & Windows, install QEMU yourself on Linux and configure binfmt_misc to use it.

I forgot to thank you, I didn't know qemu supported risc-v arch! I am already using it for various vms.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#140

Headline could read: "RISC-V adoption is 'inevitable' according to RISC-V advocate at RISC-V conference to people who are invested in RISC-V who had come to hear about state of RISC-V adoption". I'm curious where the data is to support the argument. I am struggling to see the adoption appetite outside of niche applications where licensing costs of existing architectures are a key barrier.

"Inevitable" is in keeping with the brash, larger-than-life marketing angle the whole RISC-V space has adopted. Everything is superlative-themed. "World's first", "world's best", "highest performance", "unmatched", "unleashed", "industry-leading", "gold standard", "world leader", "disruption", "revolution". I don't think it's something that should be taken literally.
Post reply on HN