6 ms·

I compiled that code with slight modifications (needed an actual func1 function) with a cross-compiler I had laying around into actual executables: cross g++ v

I compiled that code with slight modifications (needed an actual func1 function) with a cross-compiler I had laying around into actual executables: cross g++ version 8.4.0 for aarch64: 13712 bytes native g++ version 11.3.0-3 for RV64GC: 13968 bytes ... but that includes a bunch of startup stuff, so that's not a good measure. Modifying the code to generate binary on godbolt: ARM64, 3816 bytes: https://godbolt.org/z/vn3de5nEc https://godbolt.org/z/vn3de5nEc RV64GC, 3226 bytes: https://godbolt.org/z/4ovMTaxo9 https://godbolt.org/z/4ovMTaxo9 So an 18% increase in code size for ARM 64-bit vs RISC-V 64-bit. As you can see in the generated code, there are 16-bit compressed instructions by default with the RV64GC binary.

inkyoto 4y ago
This is excellent, thank you. I was under the impression that the compressed instructions set required a dedicated compiler switch, and counted a number of instructions instead. Now that «X is 18% smaller than Y» is quantified, there is the circumstantial evidence, and it gives a clearer idea of the differences between two ISA's. Yet, it does not validate the absolutist and unquantifiable «awful code density» statement. I have also noted that compressed and uncompressed instructions are unevenly interleaved in the generated code, and occur in random sequences, i.e. addresses 0x10a60 ÷ 0x10a72 follow the 16-32-16-16-16-16-32-16 bit sequence whereas most other instructions follow 16-32 bit or 16-32-32 / 16-16-32 bit sequences. I wonder what performance penalty for the instruction decoding unit in hi-perf RISC-V cores is going to be for compressed vs uncompressed instructions code especially if the instruction being decoded spills over into the next L1 i-cache line (or, worse, into another memory page). RISC architectures are generally averse to misaligned memory access.

inkyoto 4y ago

This is excellent, thank you. I was under the impression that the compressed instructions set required a dedicated compiler switch, and counted a number of instructions instead. Now that «X is 18% smaller than Y» is quantified, there is the circumstantial evidence, and it gives a clearer idea of the differences between two ISA's. Yet, it does not validate the absolutist and unquantifiable «awful code density» statement. I have also noted that compressed and uncompressed instructions are unevenly interleaved in the generated code, and occur in random sequences, i.e. addresses 0x10a60 ÷ 0x10a72 follow the 16-32-16-16-16-16-32-16 bit sequence whereas most other instructions follow 16-32 bit or 16-32-32 / 16-16-32 bit sequences. I wonder what performance penalty for the instruction decoding unit in hi-perf RISC-V cores is going to be for compressed vs uncompressed instructions code especially if the instruction being decoded spills over into the next L1 i-cache line (or, worse, into another memory page). RISC architectures are generally averse to misaligned memory access.