I'm curious to see how you'll handle instruction encoding as the machine gets more capable. Will you be able to fit everything into those upper 4 bits? I didn't think so at first glance, but the more I think about it the easier it seems. Shame the encoding isn't friendly to operations with immediates though.
My current plan is to use bits 0..3 and 12..15 to indicate the opcode. Instructions with immediates only use bits 0..3 and reserve all combinations of 12..15 where the immediate value is. In a sense that'll make immediate instructions have the opcode space cost of 16 regular instructions. 😅 I'm also thinking about using bits 4..7 and 8..11 for the encoding: since register address 0 is unused, it can be used to indicate that an op doesn't usr a reg, and thus use it to distinguish it from others.
Very cool. I was curious about what that spare bit in the instruction was being saved for. Even more curious about how you're going to add more instructions now we've run out of bits. My initial idea was to create an instruction tree so that bits 0..1 tell us what part of the CPU to use PC->[00], register->[01], ALU->[10], IO->[11] then use 2..3 to tell that part what we want it to do eg. PC-nxt, reg-cpy, ALU-div, etc. Although now I'm not sure that would be enough especially given the wide number of functions the ALU is going to need (4math, 4logic, 7shift) 😮 Also, one quick suggestion, it might be an idea to add the traditional "x" before the hex values as both decimal and hex values sometimes appear as decimals. It's easy to distinguish when you have A-F in the hex value, but when it's only got 0-9 it can be difficult to differentiate.
Creating an instruction tree is a very clever idea. That will combine very well with some lightweight instruction decoding: a few bits of the instruction could indicate which functional unit is responsible for executing it (bits 0..1 are a good fit), and the instruction decoder could then derive the op2_is_imm, alu_enable, ALU/PC opcode, etc. from that.
Me too 🙈. It would probably be good to switch to backplane PCBs early on, and just do re-spins of those when the wiring changes. Many things will be fairly stable anyway.
Where do you purchase the 8 segment LED bar graphs? I’ve been searching for them for quite some time and usually only find 10 segments at the minimum, and only red in color.
I think I got mine on AliExpress. You have to search a bit, but I found a seller that sold 8bit variants in blue, red, and green, something like 20 or 30 pieces on one styrofoam pad each.
love your videos, this is good stuff. one question tho why not use the alu itself as the selecter for move vs alu?, set RD1 to have no output and use pulldown resistors to avoid floating pins, 0 + RD2 = RD2
Thanks 🙂! Using the ALU for moves is a great idea. That would save the two buffers added in this video, and you could do away with the MV opcode. RISC-V does a similar thing: the canonical way is to use the "zero" register with an ADD operation "add rd, rs, zero". The reason why I went with an explicit MV and the buffers is two-fold: 1) After the ALU I'll likely add a few more functional units (MUL, DIV, special regs, etc.) which all want to write to the regfile through their own buffers. ALU and move are easy first steps to establish the pattern. 2) Once we move to out-of-order execution, registers will store operation IDs for results currently under computation. A dedicated move instruction can simply copy this ID from one reg to another very cheaply, and once the result is computed both registers will store it. If the move went through the ALU it would occupy an entry in the reservation station until the result is computed, which is more expensive. There are also certain move elimination schemes that are easier to do with a dedicated move. Your suggestion still applies though: RISC-V and x86 both detect move-like ops and (add rd, rs, zero) and handle them separately. It just requires a bit more work during instruction decoding.
@@fabianschuiki i am really excited about the episodes when it comes to things like out of order execution. Your Videos are really very good and high quality. Superb. I can't wait to see the next part(s).
