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

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

MitchAlsup1 [2025-03-13 19:35:33] wrote:
[...]

On Thu, 13 Mar 2025 16:43:07 +0000, Stefan Monnier wrote:

What is different about MM compared to `rep movsb`

[...]

But they never really "tried all that hard" to make them
continuously Optimal.

>
But is there a reason to presume an implementer of My 66000 would have
the luxury of putting more efforts into making MM "optimal" than Intel
put
into making `rep movsb`?

In one place we worked, there was a life sized plastic turtle (1-ft
and 2 pounds). Any the engineer who made the least amount of forward
progress every week was assigned the turtle at the corner of his/her
cubicle.
We found this "motivating"
And then there would be "me" assessing their accomplishments and
making fast MM and MS a priority goal to "him".

And they have "So Many" extra burdens,

>
Ah, now you seem to be getting to the kind of answer I was looking for.
>

such as when from is MMI/O space access and to is cache coherent, and
all sorts of other self imposed problems. Using MTRRs one can switch
the kind of memory to and from point in the middle of a REP MOVs.
All of which do nothing to make optimality easier.

>
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).

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
And how the compiler selects using MM or MS.
So, the compiler and Guest OS have to both make different mistakes that
is then not caught by Hypervisor translation tables.

                    Is it because the ISA just says "don't do that" (I
guess MM would then signal an error if it happens?), or is there some
underlying difference to the way the semantics/cachability of memory
pages is specified which makes it impossible to specify a memory range
to MM where the semantics changes partways?
>

My compilers don't create such problems for HW to solve. {That is;
the truly horrific x86 optimality problems don't exist.}

>
How do compilers getting in the picture?  I thought they were basically
ignorant of such subtleties of memory caching, as controlled by MTRRs.

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.
During the performance of MM, a change in address space can fault
the performance allowing somebody more privileged to investigate.

>
>
        Stefan