I have been going over the Op Code summary and I have a few thoughts and questions, in case another tweek of the P2 occurs before the February shuttle run...
JMPRET & JMPRETD
1. Could instruction codes for JMPRET & JMPRETD be swaped? Reason: Maintain P1 opcode compatibility where possible. Alternately, they could share the same "010111" opcode utilising the carry bit C=1=JMPRETD, freeing up an op code inthe process (see 6. below)
CMPSUB & SUBR
2. Could instruction codes for CMPSUB & SUBR be swapped? Reason: Maintain P1 opcode compatibility for CMPSUB (although R=0 is now used for additional instructions). Alternately, they could share the same op code "111000" utilising R=1=CMPSUB and R=0=SUBR. (also see below).
CMPSUB, SUBR, INCMOD, DECMOD & SETINDx, FIXINDx, CFGPINS, WAITVID
3. SETINDx, FIXINDx, CFGPINS & WAITVID could possibly all be combined into a 1/2 instruction with R=0 or 1 instruction with R=0/1, and utilising Z & C bits to decode. Reason: This would permit CMPSUB, SUBR, INCMOD & DECMOD to utilise the NR bits (as for most instructions). (see below to find a new op code)
Other possibilities could be...
3A. CMPSUB & SUBR could share the opcode "111000" with R=1 for CMPSUB and R=0 for SUBR (i.e. NR not possible with these instructions)
3B. INCMOD & DECMOD could share the opcode "111001" with R=1 for INCMOD and R=0 for DECMOD (i.e. NR not possible with these instructions)
IJZ, IJZD, IJNZ, IJNZD & DJZ, DJZD, DJNZ, DJNZD
4. These instructions all have the NR option but no WZ or WZ option. Would WZ be more useful than NR for these instructions ??? (It's a question because I am not sure - perhaps both would be nice and therefore utilise extra op codes that could be freed up below)
JP, JPD, JNP, JND
5. If these were able to have a separate op code, then could R be repurposed to provide a [#]D option too (as in the #n option used in op code "000011" instructions)? Would this therefore be possible... JP #D,#S ???
Possible instruction combinations to free up some op codes...
6. (See 1. above.) Share op code "010111" utilising C=1=JMPRETD (Note: The D versions of IJxx, DJxx, TJxx & JxPx already utlise the C bit for the Delayed versions of these instructions - this change would provide consistency).
MOVS, MOVD, MOVI
7. In P1 these instructions have C undefined. "C" could therefore be used to combine two of these instructions into 1 opcode. I cannot really see much for the "R" bit so it could be repurposed as another decode bit, permitting all 3 instructions to share the one op code and leaves the possibility of a later instruction such as perhaps MOVC (moves the 4 CCCC bits) or MOVO (moves 14 bits b31:b18) or similar.
8. In P1 the "R" bit is always =0. Therefore "R" could be utilised permitting these instructions to share an op code.
9. This instruction may be able to share another op code as Z/C/R are possibly useless. Perhaps CFGPINS or WAITVID ???
I think that almost all of these are simple verilog changes. Of course I could be completely wrong.
Possible new instruction...
10. Previously I asked if it would be possible to add an instruction to shift right 9 places from b26, leaving b31-b27 untouched, and b26-b18 set to 0. I use this in fast vector decoding (in my faster spin interpreter, and heater uses it in ZiCog) by having 3 cog instruction vectors and 5 top bits for various flags. It would be useful to also have the Z flag set according to the result of the bits b26-b0. Could this instuction be a subset of SHR where S or #S =%xxx100000. Currently, only the last 5 bits are tested and would/should? result in no shifting. By utilising a setting of >>32 an extra special instruction could be added. This is what I am trying to replace in P1 instructions...
MOV t1,Vector 'make copy
AND Vector,hF8000000 'extract top 5 bits for later
AND t1,h3FFFF WZ 'leaves D & S bits, sets Z flag
OR Vector,t1 'add back in D & S bits