Back in the 1990s I was using an inline
EX_ME MVC DEST(*-*),SOURCE
EX R0,EX_ME
because our per4mans guys said branching around the MVC cost more than
moving the 1st byte twice, while storing the MVC elsewhere might slow data
cacheing.
I expect any optimisations from the old days that are still worth it have
been kept and there will some fresh ones.
Last I heard was when MVCL and CLCL had been improved to beat multiple MVC
and CLC in most cases.
But surely these differences are very small, compared with choice of
compiler, algorithm and so on?
Roops
On Tue, 19 Aug 2025, 20:38 Tony Thigpen, <t...@vse2pdf.com> wrote:
> 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
>
>
