Deutsch English Français Italiano |
<66367d71cd660901f986ff6ddc0df362@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 18:11:39 +0000 Organization: Rocksolid Light Message-ID: <66367d71cd660901f986ff6ddc0df362@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> <da4425767126d007bf500614635d30d3@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="1813033"; 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$6/bOHiRCJd3oaj5bZ5Zo7eD7E9IbKuaxuAWe4rvNySlhTb/iTqaLS X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 3111 Lines: 45 On Thu, 12 Sep 2024 17:57:52 +0000, MitchAlsup1 wrote: > 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. But the list above is a symptom of not providing the right abstract to memmove() in ISA to begin with.