riscv-boom VS riscv-gnu-toolchain

Looks like from Appendix D that only 2 bugs were found in BOOM:

> 1. Inaccurate instruction count when minstret is written by software

I don't know what that means, but having minstret written by software was definitely not something I ever tested. In general, perf counters are likely to be undertested.

> 2. Static rounding is ignored for fdiv.s and fsqrt.s

A mistake was made in only listening to the dynamic rounding mode for the fdiv/sqrt unit. This is one of those bugs that is trivially found if you test for it, but it turns out that no benchmarking ever cared about this and from all of the fuzzers I used when I worked on BOOM, NONE of them hit it (including commercial ones...). Ooops.

Fixed here: https://github.com/riscv-boom/riscv-boom/pull/629/files

The two most micro architecturally advanced cores that I know of are BOOM, an out of order RV64GC core with all the features you expect plus sort of weird fancy things like short forward branch predication, and VROOM, another out of order RV64GC core with things like uop fusion and a trace cache.

it is used in the Berkley Out-of-Order RISC-V processor: https://github.com/riscv-boom/riscv-boom

SonicBOOM: https://github.com/riscv-boom/riscv-boom

Some cores are open source and you can see for yourself.

Rename logic from BOOM, a RISC-V core written in a DSL embedded in Scala:

https://github.com/riscv-boom/riscv-boom/blob/1ef2bc6f6c98e5...

From RSD, a core designed for FPGAs written in SystemVerilog:

https://github.com/rsd-devel/rsd/blob/master/Processor/Src/R...

And then there's the recently open-sourced XuanTie C910, which contains this Verilog… which is completely unreadable. Seems like it was produced by some kind of code generator that they didn't open-source?

https://github.com/T-head-Semi/openc910/blob/d4a3b947ec9bb8f...

We don't have Sifive's specifically but we do have the open source cores they've historically used to design their cores: https://github.com/riscv-boom/riscv-boom https://github.com/chipsalliance/rocket-chip

If you look at the decoder (https://github.com/riscv-boom/riscv-boom/blob/master/src/main/scala/exu/decode.scala), you can see that the fence instructions are also marked as "unique" instructions. Only one "unique" instruction is allowed in the pipeline at a time.

> no absurdely and grotesquely massive and complex compilers anywhere

Absence of evidence is not evidence of absence, and anyway there's not even an absence: https://github.com/riscv-collab/riscv-gnu-toolchain https://llvm.org/docs/RISCVUsage.html

> feature creeps on computer language syntax nowhere to be found

At least one of us is very confused, and in case it's me, how do language details matter to RISC-V?

I then looked at the .cargo/config.toml provided by the guide and saw that it wasn't actually statically compiling the code. After a bit of tinkering and building my own toolchain from here, I ended up with this config.toml file:

b) collabriscv - essentially gcc 12.2 + binutils master/2.40 as per https://github.com/riscv-collab/riscv-gnu-toolchain

Or would it be better to take what is in https://github.com/riscv-collab/riscv-gnu-toolchain which is gcc 12.2 and start from there?

I'm not able to build https://github.com/riscv-collab/riscv-gnu-toolchain.git like this: