+1 I love these discussions. As an engineer I love trying to outguess the hardware's cache algorithms. I love the idea of using two immediate instructions to initialize a fullword rather than using a storage reference.
But from a practical point of view, I could not agree more with @Colin. Further, unless the code in question is executed millions of times per day it will take years to get back the CPU time you devoted to the re-assembly. And if you should introduce a bug, you are never going to get that troubleshooting time back. Charles -----Original Message----- From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf Of Colin Paice Sent: Saturday, August 23, 2025 8:34 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Execute-Type Instructions Few people should be looking at the instruction level that is being discussed. You are more likely to get performance benefits from higher up the stack. For example, our code used an IMS bridge exit. Like all good programmers we allocated storage for our usage, did the work and then freed the storage. This showed up as a hot spot 1) because of enqueue on the storage request - and 2) the (small)cost of the storage requests. We fixed this by passing in a block of storage for the routine to use - so we allocated it once, and used it millions of times. We had a global block with a pointer to the next free trace slot. The code to update this involved compare and swap. With 8 CPU's there was a lot of contention. We gave each TCB their own trace area and this contention just disappeared. One customer did the same DB2 SQL query in every CICS program - just to check a system wide flag. It was pointed out this request was done 10,000 times a second. They changed this checking a bit in a global block, and deferred the need to upgrade their CPUs. So yes, look at the instruction level ... but do not forget what you are trying to do. Remember there used to be discussions on *How many angels can dance on the head of a pin?* Colin
