On Sun, 3 Apr 2022 at 12:30, Dan Greiner <[email protected]> wrote: [...] > What you might want to consider is the cost of totally trashing your data > cache with all of stuff you're copying. > To minimize that cache trashing, read up on the special pad characters for > MVCL and MVCLE. When these > instructions are not performing padding (which would be the case for an > address-space copy), pad character X'B0' > indicates that there is no immediate intent to use the data, thus the cache > can be bypassed.
I've wondered about the interaction between these magic pad values and the Next Instruction Access Intent (NIAI) instruction. It seems to me that NIAI code 3 "the corresponding operand of the next-sequential instruction will not be accessed as an instruction operand by subsequent instructions" if applied to the destination operand of MVCL[E] would also be advising the CPU that it shouldn't bring the data into the cache. What if these hints are contradictory? I would guess that the MVCL[E] magic padding would override that aspect of NIAI, but perhaps an NIAI code on the source operand could still provide useful info. Then there's the persistence (or not) of the NIAI hint over a long MVCL with interruptions. While the PofO does say that an interruption between the NIAI and the next instruction effectively cancels the NIAI, it's unclear about a long running MVCL with interruptions. I imagine that too would toss the hint. And upon a CC 3 from MVCLE, one could presumably branch back to the NIAI instead of to the MVCLE, thus redoing the hint. Tony H.
