TonyB, those are great ideas! They have never occurred to me before. I wish they would have, earlier.
That would free up a lot of space, all right. It really wouldn't be that much to make such a change, but the bigger problem is that we probably don't have the logic budget to make good use of all that space. We are pretty heavy on logic, as it is. At this point, less disruption is probably best. This line of thinking is important for the future, though.
Would the changed opcode map
a) run as fast as, or faster than, the current one ?
b) have no more logic consumed?
It is not a bad idea to have reserved opcode space, even if on this version, no logic is attached.
Other MCUs have done that, and then future versions can keep binary compatible, but super-set.
This change would add logic to the instruction decoding, but not that much. It probably wouldn't impact Fmax timing.
I don't want to do it, though, because it adds another ripple into the architecture and will make the tools more complex, given where they probably are, due to the long-standing 9-bit S field.
Chip, thanks for the positive comments on my idea. If it could be of some use in a later version of the P2 then that would be great.
Wouldn't S be just the same 9-bit field as now? I've assumed that S[8:5] are don't care and it won't matter that they are encoding bits when #S instructions are executing.
Programmers who write self-modifying code would have to ensure that S[8:5] are correct for the intended instruction. This is the only difference I can think of at assembler level.
Rather than being a drawback, this could be thought of as a new feature. ALTS could change not only how many bits are rotated, for example, but also change the rotate to a shift.
I get a positive vibe from this. For the nay-sayers, there is already examples of this in other areas of the map - namely JMP and CALLx. CALL in particular has ten separate, unaliased, opcodes for that one function.
Comments
Chip, thanks for the positive comments on my idea. If it could be of some use in a later version of the P2 then that would be great.
Wouldn't S be just the same 9-bit field as now? I've assumed that S[8:5] are don't care and it won't matter that they are encoding bits when #S instructions are executing.
Programmers who write self-modifying code would have to ensure that S[8:5] are correct for the intended instruction. This is the only difference I can think of at assembler level.
Rather than being a drawback, this could be thought of as a new feature. ALTS could change not only how many bits are rotated, for example, but also change the rotate to a shift.