5 ms·

RP2350 Hazard3 Added to LLVM

• stavros 2y ago
  Does this mean that any language that compiles to LLVM can now run on the RP2350?
  • voidbert 2y ago
    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.
  • bri3d 2y ago
    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.
    • snvzz 2y ago
      >(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.
      • bri3d 2y ago
        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.
        • snvzz 2y ago
          >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.
        • wren6991 2y ago
          > 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.
• deleted 2y ago
  [deleted]