Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Stefan Monnier 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: References: <2025Mar4.110420@mips.complang.tuwien.ac.at> <2025Mar5.083636@mips.complang.tuwien.ac.at> <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> <61cab9791f342672dcbd5dfd539cc5cc@www.novabbs.org> <3104c2ab707086659d698a0377450527@www.novabbs.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