Re: rep movsb vs. simpler instructions for memcpy/memmove

On Thu, 13 Mar 2025 19:35:33 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

 
And they have "So Many" extra burdens, such as when from is MMI/O
space access and to is cache coherent, and all sorts of other self
imposed problems.

This case is pretty useful in practice.

Using MTRRs one can switch the kind of memory
to and from point in the middle of a REP MOVs.

How exactly?

All of which do no-
thing to make optimality easier.
 
So, at a certain point in time, designers punt. If all competing
parties punt, nobody is put asunder.
 

I have no experience implementing such an instruction, but I find
it odd that such a "cosmetic detail" would have such an profound
impact on the performance of an instruction.  Can't they just
"macroexpand" it during decoding into two instructions (one which
copies the bytes without modifying the pointers, and then one which
just adjusts the pointers)? 

 
My 66000 happens to know that memory space changes will not happen
in the middle of these kinds of things (including vectorized Loops).
My compilers don't create such problems for HW to solve. {That is;
the truly horrific x86 optimality problems don't exist.}
>

How high are you aiming?
How many bytes per clock when source and destination do not overlap
and both reside in L1D$ ?
How many bytes when one side in L1D$ and another in L2$?

If the answer is less than 50 in the first case and less than 30 in the
2nd case then your are aiming uninterestingly low.

You may choose differently.

>
        Stefan