i'm... i'm might try starting a risc-v implementation tomorrow :? i've had a "success" and i'm riding the high
risc-v uses a register for return addresses rather than pushing the return address to the stack (kinda like ARM's LR), i like that and it seems easier to implement in hardware
i see why people love the risc-v ISA, it's so great
glad risc-v doesn't have delay slots, because (i think) that kinda locks you into being pipelined which i'd probably struggle to implement; that being said it probably means that a pipelined RV processor is slightly harder to impl, having to cancel a partially processed instrn
i can't find a definition of "precise" and what it means for a trap to be precise or imprecise?? or am i misreading this
in love with the long and extensive "why did we make this decision" commentary in the spec, it's great
so rn i'm thinking i'll tackle:
- rv32i only
- aligned loads/stores only -> 32-bit data bus (bad for small but good for simple & theoretical 1cy instr fetch)
- probably either ignoring or halting on traps
- no fancy optimisations
and then build on that, time/effort permitting
- rv32i only
- aligned loads/stores only -> 32-bit data bus (bad for small but good for simple & theoretical 1cy instr fetch)
- probably either ignoring or halting on traps
- no fancy optimisations
and then build on that, time/effort permitting
"i'll implement mov first" - me, forgetting `mov xa, xb` is a pseudo op for `add xa, xb, 0`
memory bus handshake: 3 cycles
instruction decode: 0.5 cycles
result writeback: 0.5 cycles
someone help me my performance is dying
instruction decode: 0.5 cycles
result writeback: 0.5 cycles
someone help me my performance is dying
not a clue how i made that mistake, consequence was jumps just shot themselves into ~0x7FFF_FFFF which is very far from the org of 0x0000_0000
hold up, it knows `a` is at address 0x18 when i do a `jal`, but when i try using %hi and %lo it suddenly thinks it's at address 0?
i literally just implemented jal/jalr and forgot jal's pc relative and jalr isn't... so it doesn't know `a` is at address 0x18, it's just converting the pc relative offset to a section offset for display
thought an `.org` directive was enough, might have to mess with objcopy

i just want command line arguments, i cbf with a linker script
this is where i go "hmm, maybe schematic capture *would* be better than verilog" which i think is a good sign (despite being wrong) - means i'm thinking in hardware rather than software which is GOOD
was a little confused by this pmux cell, but it's a one-hot select signal and therefore the A value should never be selected (since it's selected if S == 0)
somewhere in here is a lesson about not writing barrel shifters (and not running yosys' `show` after a techmap pass) - a highlight reel
not sure what was better, adding an instruction decode stage to the control FSM like i did, or not-pretty logic to allow the comb logic that does instruction decoding to source from either the bus data or the instruction register (depending on the state)
former is a bit lazy and wastes a clock cycle
now wondering if a 32-bit wide bus was a mistake, because STORE instructions will require both a read and a write
actually implemented lb and lh correctly now, wasn't sign extending before but `l[bh]u?` do what they should now (lw being 32-bit never needed sign extension :P)
should have studied AXI-Lite a little more, write strobe can select a byte. uncomfortable with the fact that it can be ignored though?
side note: what's the better alternative to M/S as terminology for the role of the participants in an interface like this?