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
