50% more OPCODES for the P1+

tonyp12

Though there is talk about eliminate some of the hardly ever used opcodes, I think they should stay as signed math will be used more often now on this new more powerful P1+

Opcodes are allotted 6bits (64 possible) and then there is the NR bit that change some of these to what is a useful secondary use of the same opcode.

I propose that all opcodes that use the NR moves to the lower 32 opcode slots and the NR bit behave just as before.

On opcodes 32-63, as they all have bit6 set it will trigger a gate logic that NR bit is now part of a 7bit long Opcode.

This should simply extra logic needed to do this and you now have an extra 32 opcodes and the compiler will not allow to manually set the wr/nr flag on these.

Dave Hein

I suggested something like that earlier yesterday, but I didn't get a response to it. I'm sure Chip will find someway to fit in the new instructions.

cgracey

I'm thinking now that we'll do what we did in the Prop2 and get rid of the R (result) bit, as we may need the space. I think the GETNIB/SETNIB and GETBYTE/SETBYTE instructions are pretty important to facilitate I/O above the LSB's. They take some space, though.

Cluso99

I have always been able to getby using long masks and ANDN/OR/XOR OUTA,<mask> for I/O.
There are quite a few instructions where NR is desirable. In P2 we were able to test bits that overcome some oof these uses. TARG also solved some NR uses.

ozpropdev

TARG's benefit was two fold.
Not only was it a good NR replacement (result to junk register) it added a 3rd operand to the mix.

cgracey

ozpropdev wrote: »

TARG's benefit was two fold.
Not only was it a good NR replacement (result to junk register) it added a 3rd operand to the mix.

It's very small, so we may be able to add it back in.