Deutsch   English   Français   Italiano  
<da4425767126d007bf500614635d30d3@www.novabbs.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!2.eu.feeder.erje.net!feeder.erje.net!news.quux.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Thu, 12 Sep 2024 17:57:52 +0000
Organization: Rocksolid Light
Message-ID: <da4425767126d007bf500614635d30d3@www.novabbs.org>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <17d615c6a9e70e9fabe1721c55cfa176@www.novabbs.org> <86v7zep35n.fsf@linuxsc.com> <20240902180903.000035ee@yahoo.com> <vb7ank$3d0c5$1@dont-email.me> <20240903190928.00002f92@yahoo.com> <vb7idh$3e2af$1@dont-email.me> <86seufo11j.fsf@linuxsc.com> <vba6qa$3u4jc$1@dont-email.me> <1246395e530759ac79805e45b3830d8f@www.novabbs.org> <8634m9lga1.fsf@linuxsc.com> <2024Sep9.090725@mips.complang.tuwien.ac.at> <86y13xf2c9.fsf@linuxsc.com> <2024Sep12.162042@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1811527"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$Wgch4raqfPTEuSrFIh1blei0CUjhcHrWCqSuHzvUAjOlfu33H03DS
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 2851
Lines: 40

On Thu, 12 Sep 2024 14:20:42 +0000, Anton Ertl wrote:

> That's clever, but for usage in glibc or the like the clunky version
> is the preferred one: memmove() is usually called through the dynamic
> linking mechanism, and which implementation is actually called is
> selected based on the hardware that it runs on (what does it do when
> the program is linked statically?).  There seem to be quite a few
> memmove() (and __memmove_chk()) implementations in glibc-2.36 on
> AMD64:
>
> __memmove_chk
> __memmove_sse2_unaligned_erms
> __memmove_chk
> __memmove_chk_erms
> __memmove_chk_evex_unaligned
> __memmove_chk_avx_unaligned
> __memmove_chk_ssse3
> __memmove_chk_sse2_unaligned
> __memmove_erms
> __memmove_avx512_unaligned
> __memmove_evex_unaligned
> __memmove_evex_unaligned_erms
> __memmove_avx_unaligned
> __memmove_avx_unaligned_erms
> __memmove_avx_unaligned_rtm
> __memmove_ssse3
> __memmove_sse2_unaligned
> __memmove_chk_sse2_unaligned_erms
> __memmove_chk_avx512_no_vzeroupper
> __memmove_chk_avx512_unaligned
> __memmove_chk_avx512_unaligned_erms
> __memmove_chk_evex_unaligned_erms
> __memmove_chk_avx_unaligned_erms
> __memmove_chk_avx_unaligned_rtm
> __memmove_chk_avx_unaligned_erms_rtm
> __memmove_avx512_no_vzeroupper
> __memmove_avx512_unaligned_erms
> __memmove_avx_unaligned_erms_rtm

All of these compile to the MM instruction in My 66000,
including the memcpy() variants.