Bare metal programming with RISC-V guide (2023)(popovicu.com)
popovicu.com
Bare metal programming with RISC-V guide (2023)
https://popovicu.com/posts/bare-metal-programming-risc-v/
11 comments
> making it easy to compare execution strategies and choose the best one
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.
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.
Pretty much this, in superscalar, OoO, uOP era with branch predictors the whole RISC vs CISC debate is just matter of amount of silicon used for decoders on die.
Playing around with 68k assembly is actually much more fun. These days all the logic is absolutely dwarfed by caches in terms of chip area. This means using RISC does not really make as much sense today as it did in the 80s. That's why the most popular architectures are still CISC (assuming ARM64 can not really be called RISC).
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.
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.
Playing around with assembly on a RISC machine is fun but that's only because RISC CPUs are the only ones where you do actually know the runtime of every instruction. The problem with amd64 is not that there are so many instructions (…just don't use the weird ones) but that the normal ones are optimized in ways that make writing assembly with them difficult if you want to understand why something performs the way it does.
Hmm, can we make a MTG style card game with Assembly instructions? RISC is a faster deck with smaller but quicker cards, CISC has heavy hitters but warms up late etc. AVX-512 comes into game and vector arithmetics the bazinga out of the enemies?
I surely did not find fun programming MIPS vs 68000/80x86, given how limited the Assembly and macro Assemblers were.
RISC-V seems equally bad in this regard.
RISC-V seems equally bad in this regard.
Makes me wish for a version of Zachtronics' TIS-100 that uses real assembly on RISC-V :)
Good fun, but the command for the linker step is missing. For those following along (like me):
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.
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.
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.