2 ms·

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 LLV

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

by bri3d 2y ago

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.