Opcodes that can be repurposed

[sparr]

This is not a bug and not yet a feature request, more intended as discussion and preparation for expansion if the author or any other folks looking at this project want to collaborate on this part.

The existing code already fits exr, exw, j*, cmp, not, sll, slr, rll, rlr, hlt, and add/sub/or/and imm into some of the gaps where the larger opcode patterns would be meaningless or close. I am looking at the instruction set and opcode list and considering where more instructions can be squeezed in. Akin to my previous post, I apologize in advance if I've gotten anything wrong. I've started putting together the parts list to build a version of this computer, but it's going to be a while before I have hardware to play on.

Here are my notes:

load $x [$out] is already repurposed for $a and $b. The other 5 destination registers are ripe for the taking, at no cost.

move $x $x is a nop. It's so nop that nop maps to move $a $a, and so could all of them. Since move imm, imm is already reclaimed and we need to keep one to cover all of them, this would open up 6 opcodes at no cost.

move $out $x isn't valid because the output register is write-only. This would open up 7 opcodes (6 if you already got one from the previous line).

and/or $x $x sets zf if $x is 0, clears cf. I think that add 0 $x would do the same, at the cost of 1 step. This would open up 8 opcodes.

stor $x, [$pc] is a quandary. The readme for the project says program memory (HL, bytes 0x100 to 0x1FF, I think?) isn't writable, but I don't see that implemented in the current schematic. If it works, it could only write to the next instruction to be executed, which seems of very limited use. I suspect this can be given up to gain 4 more opcodes.

load $x, [$pc] seems only slightly more useful. Reading only the next instruction from program memory might enable some specific clever trick, but I don't see it. I'd also give this up for 4 more opcodes.

sub $x $x sets $x to 0, sets zf, clears cf. I think that cmp $x; ldi $x 0 does the same for $b/$c/$d, and ldi $a 0; cmp 0 for $a, at the expense of one byte of code and 3 clock cycles. This would open up 3-4 opcodes.

That's about 20-35 opcodes available for additional instructions depending on priorities. I have ideas for what to do with them, but that's probably a subject for another discussion. Whether there's agreement or not on what to do with them, it would be useful to have some agreement on which existing opcodes to repurpose, for maximum compatibility between programs in the future. My preference would be to start at the top of this list.