RISC-V Code Size

Vivek you may have to reread what I wrote. Let me quote myself:

The criticism here is that the RISC-V designers have been too concerned with having a small instruction-set. That is after all one of the original RISC goals.

The claimed consequence of this is that a realistic program will require far more instructions to get stuff done, and thus consume more space in memory.

In other words I am well aware of the assumption that small instruction sets will cause the code to become larger. The thinking is that having more instructions, one can have specialized instructions replacing multiple simpler ones.

However the whole point I was making in the article is that by using code compression you undo that disadvantage. E.g. if you look at the CoreMark benchmark mentioned on page 7 of the RISC-V reader it shows the RISC-V implementation having about 10% fewer instruction than the ARM-32 program.

On page 9, they have a comparison of RISC-V with x86 and ARM in the SPEC CPU2006 benchmark. If you look code sizes relative to RISC-V with compressed instructions then, the most optimal ARM solution using Thumb2 compressed format is 99% of the RISC-V program using compressed instructions. Basically no difference.

Uncompressed RISC-V is 37% larger, while ARM-32 is 34% larger. Not a big difference given how tiny the RISC-V instruction set is. More remarkable is perhaps that x86–32 is 26% larger than RISC-V using compressed instructions.

For example compare the assembly to load/store a memory address into a register, in both ISAs

That is what I did. In many cases RISC-V can do this in two instructions which can be compressed into 32-bits. Hence no difference in size. At times you need 3 instructions but these can also be compressed, meaning you only got 50% more size.

Also you forget that RISC-V saves space in many other areas. Their branch instructions is half the size of x86 and ARM, since the compare and branch is done with one instruction.

RISC-V requires fewer instructions to be spent on memory access due to having twice as many registers as ARM-32. Also it has ABI conventions which means fewer registers need to be saved. Again reducing instruction count. Sure ARM-64 has same number of registers (32) as RISC-V but it offers no compressed instruction format and hence will lose out anyway.

The function arguments are usually stored on stack in practice. The convention is to store arguments first on stack, then call instruction saves return address.

That depends entirely on the calling convention. You are talking about the old Microsoft cdecl calling convention. fastcall calling convention and modern calling convention for x86–64 uses registers not stack: x86 calling conventions.

I remember what you describe from years ago when I was doing x86 assembly coding on a 486 on DOS. But things have changed a bit since then.

But I am not sure, if it can be used for something like Data center load

If you can use a crappy ISA like x86 or that purpose then there nothing stopping RISC-V from being used other than time and money.

Also the ISAs keep getting updated, and once there are enough number of devices in market, any updates in ISA need to take care for backward compatibility too, so that firmware running on old ISA, can easily be executed on updated one.

That is the whole point of RISC-V to make this easier than what has been the case up until now. With RISC-V you got extensions which you can check availability of in a register at runtime. You got a whole toolchain, compilers and everything designed around this idea of extensions.

Adding an extension doesn’t break old software. The problem is if you try to run new software on old hardware. But that has always been an issue, but will be less so on RISC-V as you can catch the use of unknown instructions. You could update the old hardware to add software emulation of new instructions. It will be setup from the start to trap and transfer control to OS for emulation of unknown instructions.