Hi Dan, I've long been aware that IBM moved the second byte of extended opcodes from the second byte to the last byte of the instruction for that very reason.
And no - I've never used it. I'd probably have coded a test and a branch to be able to code the correct instruction so as to have clearer code. The 'worst' I ever did was an EX of an SVC where the SVC number had to be obtained from a PARMLIB member. The worst I ever saw (not my code!) was an XOR to flip an AH to a SH and vice versa in a program that printed a report across two columns. Kind regards, Abe === On 02/08/2025 06:56, Keith Moe wrote: > I have to hide a store CPU ID instruction in my pre-retirement days. > > Keith > > Sent from an iPhone > >> On Aug 1, 2025, at 23:34, Dan Greiner <dan_grei...@att.net> wrote: >> >> As is well known to subscribers of the Assembler List, the EXECUTE >> instruction (EX) – and the (relatively) new variant of EXECUTE RELATIVE LONG >> (EXRL) – provide an extremely powerful means of altering the behavior of a >> target instruction by ORing the contents of a the rightmost bits of the >> first operand of the execute-type instruction into bits 8-15 of the target >> instruction. Common uses include modifying the length(s) of an SS-format >> instruction, the register(s), mask, or immediate field of RR, RX, SI, and >> many other formats of instructions (it is also sufficiently complex that it >> drives CPU designers slightly nuts). >> >> One reason an execute-type instruction is particularly tricky is that >> certain instruction formats contain part of the operation code in bits 8-15, >> thus the actual target instruction executed may not be that which appears in >> the memory. This can occur when the target instruction format is IE, RI, >> RIL, RRD, RRE, RRF, S, SIL, SSE, and SSF. >> >> My question is (aside from IBM diagnostics) does anybody actually exploit >> this sort of chicanery/guile/subterfuge in their code?
