Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: rep movsb vs. simpler instructions for memcpy/memmove
Date: Fri, 14 Mar 2025 12:52:02 +0100
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <vr1593$18dvk$1@dont-email.me>
References: <vpufbv$4qc5$1@dont-email.me> <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>
 <20250313225516.00004206@yahoo.com> <5jIAP.61128$Xq5f.38323@fx38.iad>
 <20250314001619.000004fa@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 14 Mar 2025 12:52:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="8993eb1896165c77447adf8e2b75772f";
	logging-data="1325044"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19aYmKJUKJWN8W1EIURmtG7IN/HPRFJeOpFVLEi6QbCmA=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101
 Firefox/128.0 SeaMonkey/2.53.20
Cancel-Lock: sha1:rK0G9py7IjCJhqGePaDb87Fa3iY=
In-Reply-To: <20250314001619.000004fa@yahoo.com>
Bytes: 3544

Michael S wrote:
> On Thu, 13 Mar 2025 21:42:25 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
> 
>> Michael S <already5chosen@yahoo.com> writes:
>>> 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.
>>
>> Although mostly done with DMA controllers in these modern times
>> to offload from the CPU.
>>
> 
> For up to few hundreds bytes it would be slower. For few thousands byte
> it could be faster at transfer level, but data ends up in the wrong
> place in the memory hierarchy, too far away from the ultimate consumer,
> so still slower from the "full job done" perspective.
> And CPU time that you "saved" by offload is almost always just uselessly
> wasted in idle loop.
> 
>>>   
>>>> Using MTRRs one can switch the kind of memory
>>>> to and from point in the middle of a REP MOVs.
>>>
>>> How exactly?
>>
>> The REP MOV straddles the boundary between two MTRRs.
>>
> 
> Crossing boundary that way can typically be predicted far in advance,
> so not really big problem.
> I think, Mitch had something less mundane in mind.

Yeah, I read it as some other core modifying the relevant MTTRs in the 
middle of the ongoing block move.

The solution seems somewhat obvious, i.e any modification of an MTTR 
which is involved in the move wil cause a hw interrupt. Upon restarting 
the remainder of the move, the new MTTR rules apply?

The alternative would be to specify that any block move is atomic as 
seen from the MTTR rules, i.e the update(s) only apply after the move 
has finished?

Terje


-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"