Posted by bhouston 4 days ago
So even after modern CPU features like OoO execution are implemented in hardware, I absolutely will not be surprised that RISC-V hardware will be slow on certain workloads without extensive software tuning. And let's be honest, most software developers will not bother to implement RISC-V-specific paths.
I still wish for RISC-V to be successful and to displace the market dominance of x86 and ARM, but I think in the end it will be Linux of the hardware world. A great advancement, created just in the right time, which eventually becomes a roadblock for further development of alternatives saddled with a lot of tech debt.
[1] https://github.com/sifive/benchmark-coremark/blob/4486de1f0a... [2] https://github.com/riscv/riscv-isa-manual/issues/353
As explained, it is the only way it is possible to use a single set of 64 bit conditional branches (and SLT/SLTU) for both 32 bit and 64 bit, signed and unsigned, values.
The Coremark restriction is stupid and explicitly ARM-centric. Any sensible person would either lazily use "int" or any 64 bit type ("long", "size_t" etc) for indexes, all of which work fine on RISC-V. The only reason to use "uint32_t" is to prematurely optimise for CPUs that zero-extend 32 bit values.
Furthermore, any sensible real-world software will allow per-architecture #if'd typedefs.
----
Most integer computational instructions operate on XLEN-bit values. Additional instruction variants are provided to manipulate 32-bit values in RV64I, indicated by a ‘W’ suffix to the opcode. These “*W” instructions ignore the upper 32 bits of their inputs and always produce 32-bit signed values, i.e. bits XLEN-1 through 31 are equal.
The compiler and calling convention maintain an invariant that all 32-bit values are held in a sign-extended format in 64-bit registers. Even 32-bit unsigned integers extend bit 31 into bits 63 through 32. Consequently, conversion between unsigned and signed 32-bit integers is a no-op, as is conversion from a signed 32-bit integer to a signed 64-bit integer. Existing 64-bit wide SLTU and unsigned branch compares still operate correctly on unsigned 32-bit integers under this invariant. Similarly, existing 64-bit wide logical operations on 32-bit sign-extended integers preserve the sign-extension property. A few new instructions (ADD[I]W/SUBW/SxxW) are required for addition and shifts to ensure reasonable performance for 32-bit values.
----
[1] i.e. proceeded only by "This chapter describes RV64I [...] widens the integer registers and supported user address space to 64 bits"*
It seems that my first blog post submitted to Hacker News got de-promoted?
That sucks.
Also wouldn't be surprised if some of the extremely aggressive RISC-V fanboys I've seen around have flagged your post for your blasphemy against their Lord and Saviour of Chips, which also downranks the story.
You can email HN about it to get a more detailed explanation if you want.