Hi Tony, thank you for pointing that out. I misread Steve's text.
Apologies for the confusion. Wishing you all great programming days! Abe === On 19/08/2025 21:38, Tony Thigpen 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 >
