Abe,
I did not see anything in Steve's post that indicated truly 'modifying
instructions', just the use of EX which does not technically modify the
instruction. (His wording may have been poor, but he explicitly said 'by
EX'.)
Tony Thigpen
Abe Kornelis wrote on 8/19/25 3:31 PM:
Steve, all,
I am familiar with that coding technique.
It changes instructions in storage, if that code
happens to be in the I-cache, there is invalidation.
I'm not sure whether that affects just the line,
it could be the entire I-cache.
The pipeline may get flushed, I'm not sure.
It might vary from one processor generation
to the next.
I'd say: change habit - allocate a flag bit or byte.
Leave your code alone. Treat as read-only.
Kind regards,
Abe Kornelis
==========
On 19/08/2025 20:52, Steve Thompson wrote:
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
