Playing around with assembly language on a RISC CPU is pretty fun, because there's only a few instructions to keep track of. Assembly language is like a puzzle game, with discrete values for the size and runtime of every instruction, making it easy to compare execution strategies and choose the best one. Something like AMD64 has so many instructions that it's difficult to figure out when to use each specific variation, let alone what resources they use. RISC, on the other hand makes everything straightforward.
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.
> 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.
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.
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?
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.
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.
Playing around with assembly language on a RISC CPU is pretty fun, because there's only a few instructions to keep track of. Assembly language is like a puzzle game, with discrete values for the size and runtime of every instruction, making it easy to compare execution strategies and choose the best one. Something like AMD64 has so many instructions that it's difficult to figure out when to use each specific variation, let alone what resources they use. RISC, on the other hand makes everything straightforward.
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.
> 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.
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.
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?
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.
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.
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.
Everything RISC-V is kewl.