Treating every programming task like a speed run challenge isn't particularly productive, so playing around with it theoretically doesn't provide a useful skill, but for the tasks where resource usage does matter that much, hand written Assembly language really does shine.
Once your CPU has pipelining and out-of-order execution (which they will, of speed is an issue), that easy gets out, no matter what instruction set your CPU uses.
Fast code also often needs to be adjusted depending on the size and timing of various caches. That’s no different with RISC-V.
I also expect that RISC-V will have warts in its instruction set, if it doesn’t already have them.
For example, there’s the idea of instruction fusion, where the CPU treats a pair of instructions as a single one. If you’re writing assembler, whether your specific CPU fuses an instruction pair can affect what the fastest code is.
Personally I would be more interested in a fully orthogonal instruction set like 68k but without the insane addressing modes and a better binary format.
RISC-V seems equally bad in this regard.
1. Save the linker script as hello.ld
2. Run 'riscv64-linux-gnu-ld -T hello.ld --no-dynamic-linker -m elf64lriscv -static -nostdlib -s -o hello hello.o' to generate the binary.
You can now run objdump to view the elf.
sylware•4w ago
sylware•3w ago