vroom VS riscv-isa-manual

Maybe implement a big feature for a open source design? like vroom or xiangshan.

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.

I had VROOM! in mind (https://github.com/MoonbaseOtago/vroom) because I remembered it aims for 4 IPC avg with a width of 8. Though looking again it's 8 compressed 16 bit instructions or 4 uncompressed 32 bit instruction.

So you could argue a real mix of instructions is not going to be all 16 bit but some 16 and some 32, so the 8 is rarely achieved in practice, and also the block diagram only shows 4 decode blocks. But it can in fact peak at 8 instructions decoded per clock, so I think that qualifies. (You could even argue it's especially impressive, since RISC-V technically qualifies as variable-length encoding like x86, it's just that only 16/32 instructions are really used at the moment)

If you are interested in high performance look into vroom , c910 and xianghan, maybe you could adopt one of them.

On top of what others mentioned (Red Hat) , it is also possible to go with the mysql/mariadb model of dual licensing, you can have a copyleft license where you must contribute back changes, but also allow selling an proprietary license if they want to enhance it but not share the improvements (like amazon or Ampere Computing that enhance ARM designs and sells it for servers), there is already a RISK-V implementation that aims to do that (vroom). another option is a non profit foundation that companies contribute to because they use the project and want it to be better (like the linux foundation) , risc-v has similar nonprofits like the chips alliance (which develops the Rocket-Chip ) or the OpenHW Group (which develops CVA6), there is also lowrisc which develops ibex (but as far as i can tell isn't governed by the contributing companies like the other non profits).

You want a very optimistic answer? someone is working on open source server core, It is already announced and i have been told it is somewhere around four years for a chip to ship after announcement so i would say 4 years from now.

At the moment the Apple M1/M2 are the king of wide decode. Within a couple of years you will see equally wide decode and execute of RISC-V from companies such as Rivos, or indeed open source and GPL'd projects such as VROOM! (https://github.com/MoonbaseOtago/vroom)

> True performance RISCV designs are going to be people's money maker and never open sourced.

That turns out not to be the case.

Alibaba's C910 core -- roughly comparable to the ARM A72 cores (at the same MHz) in the Pi 4 -- is open sourced. It is being used, at 2.5 GHz, in the upcoming "Roma" laptop. That is rather expensive (for now), but I suspect the same TH1520 SoC will quickly find its way onto cheaper SBCs.

There is a very wide OoO GPL'd RISC-V core that is under development. It is aiming for eventual Apple M1 level performance. The current iteration is falling short of that at the moment, but it's already comparable to the ARM A76 in the latest RK3588 SBCs: https://github.com/MoonbaseOtago/vroom

Then you can help open source hardware designs like xiangshan or vroom.

https://github.com/riscv/riscv-isa-manual/releases

Regarding the recent "How to improve the RISC-V specification" post [0], I just wanted to point out, that the latest draft manual is already a great improvement. (see link above)

It includes a lot of the newly ratified extensions: bitmanip,zicond,vector,vector crypto, ...

And there are a bunch of included SAIL definitions for bitmanip and zicond, but other instructions are still missing the SAIL code. Most notably, the SAIL definitions from the RV32I/RV64I base isa are also missing.

I asked for the further SAIL integration plans here: https://github.com/riscv/riscv-isa-manual/issues/1369

Here is an example SAIL snippet from cpopw:

    let bitcount = 0;

I encourage you to look at the newest isa manual draft on github: https://github.com/riscv/riscv-isa-manual/releases

It includes the more recently extensions, and e.g. the bitmanip instructions all have associated pseudo code.

Here is e.g. the code for cpopw:

    let bitcount = 0;

I tried searching the spec [1] for "overflow" and here is what it says at page 17:

> We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches.

> For general signed addition, three additional instructions after the addition are required

Is this "cheap", replacing 1 instruction with four? According to some old mainframe era research (cannot find link now), addition is the most often used instruction and they suggest that we should replace each one with four?

Their "rationale" is not rational at all. It doesn't make sense.

Overflow check should be free (no additional instructions required), otherwise we will see the same story we have seen for last 50 years: compiler writers do not want to implement checks because they are expensive; language designers do not want to use proper arithmetic because it is expensive. As a result, there will be errors and vulnerabilities. A vicious circle.

[1] https://github.com/riscv/riscv-isa-manual/releases/download/...

Why not use the actual release PDF instead from their github? https://github.com/riscv/riscv-isa-manual

https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf Part 2

If you don't want to cheat then read the RISC-V ISA manual: https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf

Yeah you are on the right track. Processors are designed on top of an Instruction Set Architecture (ISA). For an example you can look on top of the RISC-V specifications:https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf (possible PDF download)