Path: ...!2.eu.feeder.erje.net!feeder.erje.net!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 09 Sep 2024 06:41:15 -0700
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <86h6apj66c.fsf@linuxsc.com>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <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> <86seufo11j.fsf@linuxsc.com> <vba6qa$3u4jc$1@dont-email.me> <1246395e530759ac79805e45b3830d8f@www.novabbs.org> <8634m9lga1.fsf@linuxsc.com> <vbmb3h$2bfqh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 09 Sep 2024 15:41:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2550a8cb929efdfde26bde1f2c6c70c6";
	logging-data="2550486"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+CbIuPLGTw34VsSNm/7go0qAWUF6YqTZo="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:VI6ng7q7O/WsFDlRQs6OqipMEhY=
	sha1:7c6NtwAnStl5etWdsGq1p6W7Y5I=
Bytes: 3123

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Tim Rentsch wrote:
>
>> mitchalsup@aol.com (MitchAlsup1) writes:

[...]

>>> Memmove() is always appropriate unless you are doing something
>>> nefarious.
>>>
>>> So:
>>> # define memcpy memomve
>>
>> Incidentally, if one wants to do this, it's advisable to write
>>
>>    #undef  memcpy
>>
>> before the #define of memcpy.
>
> What really worries me is that I've been told (and shown in
> godbolt) that memcpy() can be magic, i.e the ocmpiler is allowed
> to make it NOP when I use it to move data between an integer and
> float variable:
>
> float invsqrt(float x)
> {
>   ...
>   int32_t ix = *(int32_t *) &x;
>
> is deprecated, instead do something like this:
>
>   int32_t ix;
>   memcpy(&ix, &x, sizeof(ix));
>
> and the compiler will see that x and ix can share the same
> register.
>
> I don't suppose memmove() can be dependent upon to do the same?

In such cases I almost always use unions rather than memcpy()
or memmove():

   float
   invsqrt(float x){
      int32_t ix = (union {float f; int32_t i32;}){ x } .i32;
      // ...
   }

No need for addresses, aliasing concerns, or any stdlib.h
functions.  And typically the unioning/deunioning produces
no generated code.

Of course it helps to have an appropriate union type predefined;
here I wrote it inline to make the example self-contained.