Deutsch English Français Italiano |
<vb7ms3$3epie$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Terje Mathisen <terje.mathisen@tmsw.no> Newsgroups: comp.arch Subject: Re: Computer architects leaving Intel... Date: Tue, 3 Sep 2024 21:08:50 +0200 Organization: A noiseless patient Spider Lines: 50 Message-ID: <vb7ms3$3epie$1@dont-email.me> References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me> <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me> <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me> <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me> <vb2hir$1ju7q$1@dont-email.me> <8lcadjhnlcj5se1hrmo232viiccjk5alu4@4ax.com> <vb3k0m$1rth7$1@dont-email.me> <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> <ljp1noFdbt2U2@mid.individual.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 03 Sep 2024 21:08:51 +0200 (CEST) Injection-Info: dont-email.me; posting-host="f05a5d1bbdc6ef5b61535a1922778e45"; logging-data="3630670"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/op9ptln5NGrEWS2BgZXoZFEU/gnxn4kEft03ebTAMoQ==" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.18.2 Cancel-Lock: sha1:w+lqsrgqNLpABBx9KE3n+WxpVG8= In-Reply-To: <ljp1noFdbt2U2@mid.individual.net> Bytes: 3557 Niklas Holsti wrote: > On 2024-09-03 20:52, Terje Mathisen wrote: >> Michael S wrote: >>> On Tue, 3 Sep 2024 17:41:40 +0200 >>> Terje Mathisen <terje.mathisen@tmsw.no> wrote: >>> >>>> Michael S wrote: >>>>> 3 years ago Terje Mathisen wrote that many years ago he read that >>>>> behaviour of memcpy() with overlappped src/dst was defined. >>>>> https://groups.google.com/g/comp.arch/c/rSk8c7Urd_Y/m/ZWEG5V1KAQAJ >>>>> Mitch Alsup answered "That was true in 1983". >>>>> So, two people of different age living in different parts of the >>>>> world are telling the same story. May be, there exist old popular >>>>> book that said that it was defined? >>>> >>>> It probably wasn't written in the official C standard, which I >>>> couldn't have afforded to buy/read, but in a compiler runtime doc? >>>> >>>> Specifying that it would always copy from beginning to end of the >>>> source buffer, in increasing address order meant that it was >>>> guaranteed safe when used to compact buffers. >>>> >>> >>> What is "compact buffers" ? >> >> Assume a buffer consisting of records of some type, some of them >> marked as deleted. Iterating over them while removing the gaps means >> that you are always copying to a destination lower in memory, right? > > > Only if you iterate in order of increasing memory address, which is not > the only possibility. > Obviously so, I really didn't think that needed to be stated. :-( uint8_t buffer[1000] memcpy(buffer + 0, buffer + 10, 100) OK? This is the memcpy() version which the original 8086 REP MOVSB was designed for, long before alternative code turned out to be faster in some circumstances. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"