Phil, no problem - interesting discussion ;-)
You are right - I am projecting supposed considerations into the IBM hardware engineers. Reverse-engineering their thought processes :-) Kind regards, Abe === On 04/08/2025 16:56, Phil Smith III wrote: > Sure, I see all those observations. But this: > >> 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. > …seems to be ascribing a motive without any actual evidence. Perhaps some > other aspect of instruction decoding in the millicode made putting the > variable part at the end. > > > > To be clear: I’m NOT trying to pick a fight; I think this is an intriguing > supposition, and certainly within the realm of possibility—the Z hardware > gang have always impressed me with most* of their decisions. I’m just not > seeing any actual evidence that “to prevent EX” was the motive (nor, of > course, that it wasn’t). > > > > ...phsiii > > > > *Maybe all—I’m just not willing to risk someone saying “C’mon, x was stupid” > and me having to say “Oh, right” :) > > > > From: Abe Kornelis <[email protected]> > Sent: Monday, August 4, 2025 4:38 AM > To: Phil Smith III <[email protected]>; [email protected] > Subject: Re: Execute-Type Instructions > > > > 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. >
