This memo discusses changes which presently are not incorporated and, furthermore, are unlikely ever to be incorporated in the Dragon opcode set. However, I think these ideas are good enough that I have recorded them for possible future consideration.

The RRR format opcodes are poorly coded because the aux bit is only useful in 1 of the 2 states of aOpt, bOpt, and cOpt and because writing the 12 constants is of negligible value operationally (since they can be initialized with SIP), and Mesa will use at least 9 of the 12 registers only for constants. For this reason, it is worth considering some tighter way of encoding these 16 bits to provide additional functionality.

This section discusses three different ways these 16 bits can be used more effectively:

A fourth possibility is to encode current options in only 15 bits so that the 16th bit of the RRR format can indicate inversion of the Rb ALU input; this would allow the RSUB, RVSUB, RUSUB, and RLSUB opcodes to be eliminated because these functions can be carried out with RADD, RVADD, RUADD, and RLADD, respectively; and it would allow (Ra xor Rb'), (Ra and Rb'), and (Ra or Rb') operations to be manufactured from RXOR, RAND, and ROR. However, I haven't found a pleasing encoding for this.

The first sample encoding enlarges the number of registers by adding 12 more registers which can be directly referenced from LocalRegs or the stack; these registers can be either additional LocalRegs or GlobalRegs. In addition, 4 AuxRegs are converted into constants. It works as follows: There are 4 groups of 16 registers each; aOpt, bOpt, and cOpt fields are 4 bits each and select the particular register in a group, leaving 4 extra bits to control the register group used for each operand. There are 4 x 4 x 4 = 64 combinations of register groups for the three operands, which somehow must be thinned to 16 combinations for encoding with 4 bits. Eliminating all constant writing removes 16 possibilities; 26 more are eliminated by preventing simultaneous use of {L, X} with {A}, a restriction applicable to the current RRR format. Then 22 remaining combinations are encodable with the old RRR format. These are shown below.

Eliminating the {A, L, X} op C combinations saves 5 more, as marked in the table; this costs something only when subtract is used because all other RRR operations can symmetrically use C op {A, L, X}, and in the case of subtract, it costs something only when -C is not also a constant. Planned constants are 0, 1, 2, 3, 4, -2, -1, 100000B, and 20000000000B, using 9 of the 12 registers; since 0 = -0 and 20000000000B = -20000000000B, the only constants whose negatives are not present are 3, 4, and 100000B. Hence, for constants so far defined, lost possibilities are {A, L, X} - {3, 4, and 100000B}; these lost combinations seem less valuable than the additional registers. One final operation has to be eliminated, so I picked A ← C op C below; so long as 0 is kept in one AuxReg, A ← C is still possible, at the cost of reducing the number of useful AuxRegs to 11.

The {L, X} ← C op C combinations also have possibilities for modification. These are useful for {L, X} ← C; and a few other interesting constants can be made from C op C (e.g., 8, 7, 6, 5, -4, and -3). Since C op C is the only instance where C appears in the Rb term, it would be possible to use an entirely different set of constant values for C in the Rb term. For example, it would be possible to treat these 4 bits literally as the values 0, 8, 16, 32, ..., 120 (i.e., feed the Rb field shifted left 3 bit positions directly into the Rb data path). Then in conjunction with the additional stored constant 5 for Ra, all values in [-122..125) could be constructed with C op C, allowing {L, X} ← almost any small constant.

With this proposal, the low-order 4 bit register displacements for the Ra, Rb, and Rc register addresses come directly from the opcode fields (ignored on stack options), while the high-order base register (L, X, or A) can be selected according to the output of a 4-input, 6-output PLA.

Since the RJB and QR formats have a 6-bit field to identify any register, they have no difficulty adapting to the above proposal.

Here is a second sample encoding which modifies the old RRR format to allow intermixing AuxRegs and LocalRegs and to convert 4 AuxRegs into constants. {L, A} op C is ruled out as in the previous proposal, so {L, A} — {3, 4, 5, 100000b, and 6 more unspecified constants} are impossible with this variation. Also, note the way in which the range of small constants which can be loaded into A and L registers has been increased:

Then 0 op C2C3 can be used to generate [-255..+255] and C op C1 can extend this range to [-378..381]; these constants can be loaded directly into any AuxReg or LocalReg.

As mentioned in the first RRR change proposal above, additional registers addressable in RRR format do not create a major problem for either RJB or QR format because a full 6-bit field can be used to address any register. Furthermore, the selection by Rs of const0, const1, [S], or [S]- seems fairly reasonable for both RJB and QR format.

However, automatic use of [S] as the destination register in QR format seems questionable; this makes sense only when either the Rs or Rb argument is also [S]. Consider the following:

Also note const0 op [S] = [S] op const0 and const1 op [S] = [S] op const1 for all operations except subtract, so there is little utility in either of these forms. Consequently, the 2-bit Rs field is essentially wasted in QR format, where the only sensible case is [S] ← [S] op AnyReg.

Here is a better interpretation (though still not very good):

With this change [S+1] ← const0 op AnyReg can be used with QOR to push any register onto the stack; since one-byte load opcodes exist for the local registers and the first 8 constants, this saves 1 byte whenever an AuxReg or one of the last 4 constants is pushed. However, negation of the register at [S] is lost.