I have been reading through this from the bottom and hadn't seen
any mention of the following:
At one shop I was in as a developer, we had a macro that would EX
an MVC so that it would be variable.
We had a macro that depended on execution time arithmetic to do x
MVCs and end with an EX of an MVC to take the place of an MVCL.
We found that it was faster to do 4 MVCs than an MVCL. So if the
length to be moved was greater than 1024 bytes, we did the MVCL,
otherwise....
OTOH, at the last shop I was in, B and NOP instructions were
modified by EX to make them NOP or B. And it seemed like this was
the STD way to handle logic for switching from processing one
type of record to another.
So here is the question for the hard core types: With z/Arch,
might this cause a processor stall because of a cache line of
code having been changed since that line was fetched? And how
much of a delay could this cause?
-- Regards,
Steve Thompson
Make Mainframes Great Again
They use far less Electricity than Clouds and can do more work
On 8/4/2025 2:04 PM, Dan Greiner wrote:
As to my original query, I was wondering to what extent anyone might use EX (or
EXRL) to alter the actual target instruction. Yves gave an intriguing reply
where a value of 0, 1, or 2 in the R1 field of EX could alter its target
instruction from SAM24, SAM31, or SAM64. In this case, it's clever and
efficient. However, perhaps a more understandable technique might be to use EX
with an index register that identified the actual instruction to be executed.
The CPU designers have a long love/hate relationship with execute-type
instructions (tending towards hate). As to whether they and the architects
envisioned that EX could be used to modify the target opcode ... undoubtedly
they did. Perhaps they could have designed it such that if the R1 field
modified a target opcode, an exception could be recognized ... but they didn't.
I'm just trying to understand whether anyone (other than Yves) actually uses
this.
As to the history of opcodes stretching beyond the first 8 bits: the original
S/360 architecture had about 150 instructions defined, so there was room for
another 100-or-so one byte opcodes to be defined without going beyond one byte.
The first instance of opcodes creeping beyond bits 0-7 of the instruction
showed up later in the S/360 architecture. Originally, the HALT IO (HIO)
instruction was defined as opcode 9E hex, with bits 8-15 reserved. Its opcode
was subsequently redefined as 9E00 hex, and HALT DEVICE (HDV) was defined as
9E01 hex.
It wasn't until the S/370 architecture (circa 1970) that major infestation of
bits 8-15 occurred with the advent of the RRE-, S-, SSE-format instructions.
The vast majority of these were privileged or semi-privileged instructions,
with a few exceptions like SET SYSTEM MASK (SSM), STORE CLOCK (STCK), and TEST
AND SET (TS) that were unprivileged. (SSM and TS were reclassified to S format
from their original SI format in S/360).
370/XA (circa 1983) introduced the E-format instruction – an instruction format
with just 16 bits of opcode and nothing else – for the UPDATE TREE (UPT)
instruction (as if UPT was going to be coded so frequently that it warranted a
special format to save code space ... not the brightest architecture IMHO).
Somewhere between ESA/370 and ESA/390, the immediate-and-relative-instruction
facility came along that introduced the RIL format in which the opcode was
split between bits 0-7 and 12-15. This provided significant enhancements with
relative (to the PSW instruction address) storage operands and 16-bit immediate
operands.
A bit later in the ESA/390 time frame came the RXE and RXF formats, a 6-byte instruction
where the opcode was split between the first and last byte (i.e., bits 0-7 and 40-47).
These were used for binary floating point instructions and for some z/Architecture ops
that were retrofit to ESA/390. Also in later ESA/390 time frame came RSE and RSL formats
with similar opcode split. These provided such "features" as COMPARE LOGICAL
LONG UNICODE (CLCLU), MOVE LONG UNICODE (MVCLU), and ROTATE LEFT SINGLE LOGICAL (RLL).
z/Architecture flooded the architecture with gobs more instructions in which
the opcode extended beyond bits 0-7. For a great overview of the instruction
formats, see Figure 5-1 in the latest PoO.
-- Regards,
Steve Thompson
Make Mainframes Great Again They use far less Electricity than
Clouds and can do more work
