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

breaking down instruction formats

"i'll implement mov first" - me, forgetting `mov xa, xb` is a pseudo op for `add xa, xb, 0`

we technically just executed an instruction?

6 luis, why not

wooah

blazing along at 4 clock cycles per instruction

memory bus handshake: 3 cycles
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

grr

conditional branches all seem to work!!

woahhhhh!!!

old pc logic left, new pc logic right, preeeeetty sure 1 adder is better than 4

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

when was the last time a computer told you your code was incomprehsible

heyo LOAD opcode is go

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?