+1 for Jonathan's reply. It can be more subtle that which is the best instruction. If you think of the MVC as a microprogram not an instruction there is logic like At a high level
- Go and get the storage into the processor cache - this can be slow - Execute the instruction It is hard for the end user to know where the time is spent ( IBM has tooling which tells it) Or in more detail - Map the virtual address to a real page - Is the page in real storage ? no go and page it in - Is the 256 cache line in my processor's cache ? - No go and get it and lock it... it may have to wait if another processor has the cache block r/w - Is the cache line with the =64PL4'0' in my processor's cache - no go and get it - Now move the data - release locks on cache line In my performance work, the second time round a loop was always much faster than the first time. There is an instruction to tell the processor to go and make this storage available - a sort of cache preload instruction. You do other instructions... perhaps 10-20 then execute your instruction. This can minimise the "Go and get the storage into the processor cache" How are you measuring the time spent in this code? Colin On Sun, 30 Nov 2025 at 09:54, Jonathan Scott < [email protected]> wrote: > Overlapping MVC where the overlap is not just 1 byte is likely to be much > slower than an ordinary MVC, as it is less likely to be handled in an > optimised way. > > I think the fastest solution would be one ordinary MVC per 256 bytes, > something like the following (using the same literal in both cases to avoid > needing a second one, even though the second move is less than 256 bytes): > MVC P1(256),=64PL4'0' > MVC P1+256(104*4-256),=64PL4'0' > > I had an ASSERT macro to verify assembly-time assumptions, so I'd add > something like ASSERT L'P1,EQ,4 in this case. If you don't have an > equivalent macro, you can at least use this: > DC 0SL2(L'P1-4,4-L'P1) Verify assumption that L'P1 is 4 > > [I'm retired now so the above is all from memory and has not been tested]. > > Jonathan Scott >
