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 12:43:07 -0400
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <jwv7c4s3n4d.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>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 13 Mar 2025 17:43:07 +0100 (CET)
Injection-Info: dont-email.me; posting-host="8b299a8a9f11694663a9643fc779ea27";
	logging-data="3670332"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19lMU1HtWlDskG+P7Z31WcHh/YaiZg1Dtk="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:3eZpPX8hCVM6CbhCaToBQJfYBtU=
	sha1:1d/5zS7VfdjiAcU7CegH7bi0Kew=
Bytes: 2426

>> What is different about MM compared to `rep movsb`
> MM does not modify the pointers. MM keeps its current index,
> thus the compiler can use the Rf pointer multiple times.
>> that you can confidently state that it will always be optimal?
> Compared to the explosion in memmove() subroutine, yes.

Are you suggesting that what prevents Intel to make `rep movsb` optimal
is the fact that it modifies its pointers?

I have no experience implementing such an instruction, but I find it odd
that such a "cosmetic detail" would have such an profound impact on the
performance of an instruction.  Can't they just "macroexpand" it during
decoding into two instructions (one which copies the bytes without
modifying the pointers, and then one which just adjusts the pointers)?


        Stefan