Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: comp.arch
Subject: Re: rep movsb vs. simpler instructions for memcpy/memmove
Date: Thu, 13 Mar 2025 17:44:53 -0400
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <jwv8qp81urp.fsf-monnier+comp.arch@gnu.org>
References: <vpufbv$4qc5$1@dont-email.me> <vq4qav$1dksd$1@dont-email.me>
	<vq5dm2$1h3mg$5@dont-email.me>
	<2025Mar4.110420@mips.complang.tuwien.ac.at>
	<vq829a$232tl$6@dont-email.me>
	<2025Mar5.083636@mips.complang.tuwien.ac.at>
	<vqdljd$29f8f$2@paganini.bofh.team> <vqdrh9$3cdrc$1@dont-email.me>
	<vqqcm0$3l3i5$1@paganini.bofh.team>
	<2025Mar12.094228@mips.complang.tuwien.ac.at>
	<20250312114828.00003e99@yahoo.com>
	<2025Mar12.122836@mips.complang.tuwien.ac.at>
	<20250312140915.000010a8@yahoo.com>
	<2025Mar12.174636@mips.complang.tuwien.ac.at>
	<a296144c60c9774898235f505bc4c370@www.novabbs.org>
	<jwvy0x93vb5.fsf-monnier+comp.arch@gnu.org>
	<61cab9791f342672dcbd5dfd539cc5cc@www.novabbs.org>
	<jwv7c4s3n4d.fsf-monnier+comp.arch@gnu.org>
	<3104c2ab707086659d698a0377450527@www.novabbs.org>
	<jwvv7sc1zve.fsf-monnier+comp.arch@gnu.org>
	<5d1811bcd643246db941630e2e87f29b@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 13 Mar 2025 22:44:54 +0100 (CET)
Injection-Info: dont-email.me; posting-host="8b299a8a9f11694663a9643fc779ea27";
	logging-data="4144523"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX185h17wM/eUYJRvhEaJuVr+UXQ7DZnrmUg="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:LYS3FdMOYCHY/bzKNaD7ZaVHPk4=
	sha1:kH5Qs4eT5Oa7pg/VjFdDWJLUb4o=
Bytes: 3951

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