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

MitchAlsup1 [2025-03-13 20:59:26] wrote:

On Thu, 13 Mar 2025 19:53:25 +0000, Stefan Monnier wrote:

How does MM avoid those complexities?

>
Compiler only produces MM and MS where the memory is known to be
contiguous, and My 66000 universal address space is 64-bits in width
for each kind of address space, so no MM can cross such a boundary
(unless the GuestOS is aiming a gun at its feet mucking with the
PTEs).

What is `MS`?
Isn't it also the case in `rep movsb`?
At least assuming an OS like Linux?

My 66000 happens to know that memory space changes will not happen
in the middle of these kinds of things (including vectorized Loops).

How does it know?

4 × 64-bit PASs
1 × 64-bit VAS

Sorry, I think you went too fast, you lost me here.  I'm just a poor
compiler guy with a side-interest in computer architecture.

Presumably the needs that MTRRs satisfy can also be satisfied in My
66000, so I guess what I'm missing here is how My 66000's solution is
different from the amd64/i386 one and how that ends up providing MM with
a guarantee that it doesn't need to care?

It seems to me, there might still be cases where a My 66000 system might
want to copy bytes between a network card buffer and DRAM, so while
I don't expect the cachability of either source or destination to change
in the middle of an MM operation (and I similarly would be fine with
a `rep movsb` that becomes slow if this ever happens), I do expect MM
operations to transfer data between areas that don't have the
same cachability.

The compiler uses MM for copying one chunk of virtually contiguous
memory to another chunk of vcm.
Compiler would not do this if there is any non-contiguousness. So, from
VAS, the access is well defined and compactly described.

In which way does this not also apply to `rep movsb`?

During the performance of MM, a change in address space can fault
the performance allowing somebody more privileged to investigate.

What do you mean by "change in address space"?


        Stefan