Closed bradjc closed 3 years ago
Thank you for a PR!
I understand the growing demand for RV32, but I'm a bit reluctant to make this default since it will impose a burden on those that would have been happy with RV64. It will make their compile times longer and increase the size of the bottles.
What do you think of copying the formula (riscv-gnu-toolchain.rb
) and making a new one for with RV32? You could even take it a step further and make a riscv-tools32
formula that also builds the right form of pk, and when it invokes spike to test, uses an RV32 ISA string?
What do you think of copying the formula (
riscv-gnu-toolchain.rb
) and making a new one for with RV32?
That was a thought but what would happen if someone installed both?
You could even take it a step further and make a
riscv-tools32
formula that also builds the right form of pk, and when it invokes spike to test, uses an RV32 ISA string?
I have to admit to not understanding any of this.
I understand the growing demand for RV32, but I'm a bit reluctant to make this default since it will impose a burden on those that would have been happy with RV64. It will make their compile times longer and increase the size of the bottles.
Also, it looks like, at least, the packages on ubuntu (https://packages.ubuntu.com/hirsute/gcc-riscv64-unknown-elf) use --enable-multilib
by default.
I've agreed to your request to include multilib by default. I've pushed code (189cbbc4d9eb68ba2738a3a1124e18f08b69e038 ) and new bottles. I added an option to disable it in case someone doesn't want to wait a long time.
Unrelated to this change, it appears spike can't find pk. I'll try to fix that in the next few days.
I'm not sure if there is a downside to shipping the full RISC-V GCC by default, but it would certainly make it easier to do embedded development on 32 bit targets. Right now it takes over 30 minutes to compile everything from source.
And with the growing number of RISC-V embedded hardware platforms, I assume this will be in greater demand going forward: