5 ms·

Not much to disagree with there. ARMv3 is not bad. They'd got the flags out of the PC. A bit annoying to have only (IIRC) the "Single Data Transfer" format for

Not much to disagree with there. ARMv3 is not bad. They'd got the flags out of the PC. A bit annoying to have only (IIRC) the "Single Data Transfer" format for load/store of words or zero-extended bytes. No halfword, and no sign-extended byte. That's pretty much the instruction count difference to RV32I right there, as that has uniform W, H, HU, B, BU handling -- and with the same choice of offsets in all cases, unlike ARM. I might prefer ARMv4 because of that e.g. ARM7TDMI, but ignoring Thumb. But it does add instruction encoding complexity. Reading hex dumps -- it's never going to be easy to make hand readable/writable instruction formats in hex when you have 5 bit register fields. I've sometimes thought about doing a hex-friendly RV32E custom encoding. PUSH/POP multiple is handy for function entry/exit, but the A32 asm syntax for it isn't very friendly. Thumb is better in that regard. RISC-V lets you write functions that set up the stack frame and save ra and s0-sN by using an alternative return address register (traditionally x5), and similarly functions to restore the registers and return. GCC even comes with these functions (total 96 bytes of code last time I looked) and uses them if you give the -msave-restore option. That cuts down function length a lot.

kragen 3y ago
oh hey, i didn't know gcc shipped with the save-restore millicode and an option to use it, that's cool! with .syntax unified you have a fairly friendly push/pop multiple syntax, whether you're using thumb or not agreed about the instruction encoding complexity over rv32i and about halfwords and signed bytes. the arm7 datasheet includes example sequences for, among other things, loading halfwords, division, and an lfsr, but that kind of detour is exactly the kind of thing that adds potentially unintentional difficulty to classwork rv32i also has more instructions than armv3 because it has shift instructions, while armv3 has optional shifts or rotates in most instructions, which certainly isn't a reduction in complexity with respect to risc-v maybe you could make a base32 word dumper using 0123456789abcdefghijklmnopqrstuv? won't help much with the standard risc-v instruction encoding... and once you're swizzling split immediate fields around, you might as well write a disassembler an octal-friendly rv32c custom encoding might be more achievable. this is vaguely related to graham smecher's "minimax" implementation of risc-v, where the hardware only implements the two-operand compressed instruction set plus a few extra instructions, and uncompressed instructions trap to microcode. or millicode, i guess

kragen 3y ago

oh hey, i didn't know gcc shipped with the save-restore millicode and an option to use it, that's cool! with .syntax unified you have a fairly friendly push/pop multiple syntax, whether you're using thumb or not agreed about the instruction encoding complexity over rv32i and about halfwords and signed bytes. the arm7 datasheet includes example sequences for, among other things, loading halfwords, division, and an lfsr, but that kind of detour is exactly the kind of thing that adds potentially unintentional difficulty to classwork rv32i also has more instructions than armv3 because it has shift instructions, while armv3 has optional shifts or rotates in most instructions, which certainly isn't a reduction in complexity with respect to risc-v maybe you could make a base32 word dumper using 0123456789abcdefghijklmnopqrstuv? won't help much with the standard risc-v instruction encoding... and once you're swizzling split immediate fields around, you might as well write a disassembler an octal-friendly rv32c custom encoding might be more achievable. this is vaguely related to graham smecher's "minimax" implementation of risc-v, where the hardware only implements the two-operand compressed instruction set plus a few extra instructions, and uncompressed instructions trap to microcode. or millicode, i guess