Hi Phil, I have not been part of the process - I must infer from the outside. Dan Greiner probably knows more - but I doubt that he would comment on things internal to IBM.
Here's what I observe: - The old vector facility had A4xx opcodes where the second byte of the opcode was the second byte of the instruction. - Instructions in the B2xx, B3xx, B9xx ranges (mostly formats S/RRE/RRF) are structured likewise. - Instructions in the E5xx range (mostly SSE/SIL formats) same pattern. At some point IBM must have come to realize that an EX of any of these instructions would modify the opcode, rather than its parameters. But being able to modify parameters/operands on the flight has much broader applicability than the ability to alter the opcode of the instruction. Newer sets of extended instructions are structured differently: - E3xx (RXY format) has the second byte of the opcode in the last byte of the instruction. - E6xx/E7xx (new vector facility) again has the second byte of the opcode in the last byte of the instruction. - EBxx (SIY/RSY formats) and ECxx (RIE/RRS/RIS formats) same again. - EDxx (RXE/RXF/RXY/RSL formats) again. The S/RRE/SSE formats were introduced with S/370. This corresponds with my first block above, where the A4xx, B2xx/B3xx/B9xx, and E5xx instruction ranges are mentioned with the two bytes of the opcode occupying the first 16 bytes of the instruction. The PoP for ESA/390 (I have no copy of the 370/XA PoP) defines RXE / RXF / RSE / RSL formats which all have the second byte of the opcode in the last byte of the instruction, freeing up the second byte for either two registers, or a length code. Much more useful as a target for modification when using EX. The new vector facility is even newer. It also follows the 'newer' pattern. Which is apparently here to stay - including (most) new developments. Someone came to the conclusion that this (somewhat counter-intuitive) implementation provides more value to customers, and to IBM developers of operating system logic and compilers. As to 'moving' the second byte of the opcode: no of course that cannot be done for existing instructions as that would break compatibility. It is for 'newer' (i.e. s/370 and later) that the second byte of all new opcodes is 'moved' from the second byte to the last one. It is placed in the last byte of the instruction rather than in the second, as IBM used to do with S/360. From an architectural point of view I regard that as a move. If you look at individual instructions, obviously, no move is discernible - nor will it ever be. (although IBM might opt to concoct 'replacements' for instructions with the 'old' format that would use opcodes in the 'newer' ranges so as to have the operands in a format that is more amenable to a fruitful use of EX/EXRL instructions) Kind regards, Abe === On 03/08/2025 22:45, Phil Smith III wrote: > Abe Kornelis wrote, in part: >> 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. > Cite? Not ridiculous or impossible, I just find it hard to believe that IBM > would bother. >
