Closed catageek closed 9 years ago
So, n = opcode >> 6
. Well there is not instructions with the problematic opcode, so I find unnecessary put now these restriction. But if we made a TR32X0 cpus with instructions (with FPU or something) that use these problematic opcodes, then this restriction would be necessary.
Semi-offtopic, but Zardoz I think adding new CPUs with integrated FPUs would be a mistake.
There is a physical restriction preventing to execute properly a P3 instruction with embedded immediate Rn when the opcode is between 0xC0 et 0xFF.
This is not an affirmation, this is a proposal.
The reason why I would like this to become official is that the sign extension of an immediate does not work when the first byte is between 0xC0 and 0xFF.
The real reason why this is needed is that the number of bits to extend is computed using the 2 first bits of this byte. Let's call n this value. For P0 and P1 we have n=0, P2 will give n=1 and P3 will give n=2 or 3.
The number of bits to extend is then d = n * 4 + 10. (we don't care about P0 since there is no Rn)
The problem is that it does not work with n=3. I could not find a simple way to get rid of this case, unless using another register and at least 3 operations. this is expensive.
Fortunately, there is still no instruction using this opcode, so there is nothing to redefine, but we must keep in mind that these instructions will load Rn from a register or from the next word. Perfect place for a floating point instruction set ;-)