3 Sep
2014
3 Sep
'14
3:04 a.m.
On 09/02/2014 07:10 PM, John Wilson wrote:
So instead you either maintain the modified opcode in
a variable, or
else keep a pointer to one of three different constant opcodes, and
issue XCT/EX/etc. using that variable (or pointer) when the time comes.
So your main code path is never touched, but you can substitute the
correct opcode as needed.
In processors with very small instruction sets (no, I wouldn't call the
S/360 one), it can be very useful.
Consider for example the 8x300 (Signetics) bipolar microcontroller. 3
bits in the instruction for the opcode:
MOV (move) ADD, AND, XOR, XMIT (sort of a move immediate), NZT (jump if
not zero, XEC and JMP. What's useful about the XEC is that it could
take external data and use it to perform a sort of "computed GOTO".
Remember that the instruction store for this chip is in bipolar PROM--no
instruction modification in memory. Or you could use a computed target
address to perform a single instruction or jump.
Here's a hypothetical example. Suppose you're on an 8080 (not Z80)
MPU--and suppose you need to perform an IN or an OUT to a computed I/O
port. Well, IN and OUT take an immediate value as the target I/O address.
This means that you either (a) create a table of IN and OUT to every
possible I/O address, following each IN or OUT with a RET and then
simulating a computed CALL into the table. Clumsy, but if you can't
modify instructions (execute out of RAM), that's pretty much your only
choice. If the 8080 would have had an "execute" instruction that could
modify the second byte of any instruction, that would have meant that
you didn't have resort to clumsy schemes as already described.
--Chuck