RP2350 Hazard3 Added to LLVM | Hacker News Reader

RP2350 Hazard3 Added to LLVM

github.com

16 pointshasheddan7 comments

Does this mean that any language that compiles to LLVM can now run on the RP2350?

That was possible before when targeting RV32. If I understand correctly, this makes it possible for LLVM to use all RISC-V extensions supported by the core with a simple command line (the patch describes what features the core supports), resulting in better-optimized code.

However, to run any language on the Pi Pico, that language still needs to interop with Pico's SDK, which you'd have to do manually if no one created bindings yet.

That was already true given that the main RP2350 cores are just normal Cortex-M33s. The Hazard3 cores are just selectable replacements, and this is mostly just adding support for the specific set of RISC-V oddities taped out into Hazard3 on the RP2350 (this class of issue is going to be a big issue for the RISC-V ecosystem moving forward, imo).

But yes, normally when a new LLVM backend lands most frontends will immediately gain support; this is the goal of the LLVM architecture. Peripheral drivers and a standard library that functions on a given hardware target are an exercise for the reader, although most LLVM frontend languages can bridge to C in some way or another.

>(this class of issue is going to be a big issue for the RISC-V ecosystem moving forward, imo)

What issue? Generic RV32I code "just works" in this microcontroller.

This is not unlike telling LLVM the target is Zen4, which enables e.g. avx-512.

Generic RV32I code is comically bad, since it doesn't even have things like hardware multiply.

Regardless, I was wrong about the way RISC-V options work on LLVM and it's fine; I was under the impression from "I'm of the opinion that the lack of arm-like -mcpu=<core>+<optional stuff>+no<disabled stuff> equivalent for RISC-V is a good thing" in the linked discussion that a new processor type was necessary to enable even basic extensions, but it turns out that `-march=rvi20u32_mac` also works - it takes a profile name followed by extensions.

>Generic RV32I code is comically bad, since it doesn't even have things like hardware multiply.

Which is great when you don't need hardware multiply.

Alas there was an oversight, which is that M includes divide, but in the smallest cores, very often multiply is desired yet divide, which is much more costly, is not.

Some Z extension was later defined to give multiply w/o divide.

Most RISC-V MCUs in the wild are currently implementing at least RV32IMAC.

>it turns out that `-march=rvi20u32_mac` also works - it takes a profile name followed by extensions.

Yup, and most of the time simply targeting a profile is desired.

Microcontrollers and very embedded cores are of course their own world, but fortunately the world of custom is also a world where binary application compatibility does not matter.

> I was under the impression from "I'm of the opinion that the lack of arm-like -mcpu=<core>+<optional stuff>+no<disabled stuff> equivalent for RISC-V is a good thing" in the linked discussion that a new processor type was necessary to enable even basic extensions

I think lenary's complaint there is more about the defaults being poor for the Arm -mcpu stuff (everything is on and you have to disable everything explicitly and individually) and the way it conflates CPU vs arch variant. They used to be an Arm compiler engineer so there is a lot of past trauma there.

Reply on news.ycombinator.com