On Monday, September 20, 2021 at 2:54:31 AM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Sunday, September 19, 2021 at 11:57:06 AM UTC-5, Thomas Koenig wrote:
> >> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> >> > Then Ulrich Drepper thought it was a good idea to use backwards
> >> > stride, and that code broke; and his really great idea was to make the
> >> > stride dependent on the CPU model at run-time. So it might test fine
> >> > on the original developer's machine, and break on a user's machine,
> >> > which is instruction-set compatible with the developer's machine, only
> >> > library-incompatible.
> ><
> >> Shared library-incompatible, to be exact. Welcome to shared library
> >> hell.
> ><
> > I missed this before::
> ><
> > Is the change in observed behavior because of some out-of-specification
> > use of shared library, or a change in the in-specification use of shared the
> > library?
<
> The first.
<
So, the new library changes the observed behavior of out-of-specification
use of the library. I have little sympathy.
>
> Using memcpy with overlapping arguments is undefined per the C
> standard.
<
Yes, which permits one to support::
#define memcpy memmove
or equivalent.

On Monday, September 20, 2021 at 2:52:34 AM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Sunday, September 19, 2021 at 5:38:51 PM UTC-5, Thomas Koenig wrote:
> >> MitchAlsup <Mitch...@aol.com> schrieb:
> >> > On Sunday, September 19, 2021 at 5:16:03 PM UTC-5, Thomas Koenig wrote:
> >> >> Stefan Monnier <mon...@iro.umontreal.ca> schrieb:
> >> >> >> There is no specification that a compiler writer could follow.
> >> >> >> The respective language standards are irrelevant. Past behavior
> >> >> >> is all that counts, and pointing out that his program is errnoneous
> >> >> >> is a no-no.
> >> >> >>
> >> >> >> The consequence is clear - compiler writers should stop fixing
> >> >> >> bugs because fixing a bug might change the observable behavior of
> >> >> >> existing programs, which is bad.
> >> >> >
> >> >> > I think Mitch had another conclusion which I would paraphrase as
> >> >> > "a serious API shouldn't have any `undefined` part".
> >> >> Mandatory bounds checking? Mandatory checking for -32768, with
> >> >> a specification what happens with a bounds overrun? Exact
> >> >> language specification of what happens if memory on the system
> >> >> runs out (i.e. no memory overcommit on Linux)?
> >> >>
> >> >> And even so, according to Linus T's definition, if code like
> >> >>
> >> >> int x[10];
> >> >> int a;
> >> >>
> >> >> ...
> >> >>
> >> >> x[10] = 42;
> >> >> assert (a == 42);
> >> >>
> >> >> ever "worked" on any system, it would have to be kept that way -
> >> >> mandating stack layout of variables, keeping a from being kept in
> >> >> a register etc.
> >> >>
> >> >> Is that really what people want?
> >> ><
> >> > No, people want that kind of stuff found at compile time.
> >> Not possible in the more general case, as you know.
> ><
> > ADA does not seem to have this problem. Perhaps because they actually care.
> You wrote "at compile time". Testing the correctnes of a program
> written in Turing-complete languge is the equivalent of solving
> the halting problem.
>
> Besides:
>
> Does Ada catch the equivalent of C's
>
> int x[10];
> int i;
> scanf ("%d", &i);
> x[i] = 42;
>
> at compile-time because x[i] might overflow?
<
nitpicking:
It is not x[i] that overlfows, it is i which is out-of-bounds WRT x's domain.
>
> At run-time is a different kettle of fish, of course. Even so,
> how does Ada guarantee that there is no overcommitment of memory
> on Linux, the OOM killer comes along and kills the process?
<
This is another halting problem (all over again).

On Monday, September 20, 2021 at 6:41:03 AM UTC-5, Michael S wrote:
> On Monday, September 20, 2021 at 10:52:34 AM UTC+3, Thomas Koenig wrote:
> > MitchAlsup <Mitch...@aol.com> schrieb:
> > > On Sunday, September 19, 2021 at 5:38:51 PM UTC-5, Thomas Koenig wrote:
> > >> MitchAlsup <Mitch...@aol.com> schrieb:
> > >> > On Sunday, September 19, 2021 at 5:16:03 PM UTC-5, Thomas Koenig wrote:
> > >> >> Stefan Monnier <mon...@iro.umontreal.ca> schrieb:
> > >> >> >> There is no specification that a compiler writer could follow.
> > >> >> >> The respective language standards are irrelevant. Past behavior
> > >> >> >> is all that counts, and pointing out that his program is errnoneous
> > >> >> >> is a no-no.
> > >> >> >>
> > >> >> >> The consequence is clear - compiler writers should stop fixing
> > >> >> >> bugs because fixing a bug might change the observable behavior of
> > >> >> >> existing programs, which is bad.
> > >> >> >
> > >> >> > I think Mitch had another conclusion which I would paraphrase as
> > >> >> > "a serious API shouldn't have any `undefined` part".
> > >> >> Mandatory bounds checking? Mandatory checking for -32768, with
> > >> >> a specification what happens with a bounds overrun? Exact
> > >> >> language specification of what happens if memory on the system
> > >> >> runs out (i.e. no memory overcommit on Linux)?
> > >> >>
> > >> >> And even so, according to Linus T's definition, if code like
> > >> >>
> > >> >> int x[10];
> > >> >> int a;
> > >> >>
> > >> >> ...
> > >> >>
> > >> >> x[10] = 42;
> > >> >> assert (a == 42);
> > >> >>
> > >> >> ever "worked" on any system, it would have to be kept that way -
> > >> >> mandating stack layout of variables, keeping a from being kept in
> > >> >> a register etc.
> > >> >>
> > >> >> Is that really what people want?
> > >> ><
> > >> > No, people want that kind of stuff found at compile time.
> > >> Not possible in the more general case, as you know.
> > ><
> > > ADA does not seem to have this problem. Perhaps because they actually care.
> > You wrote "at compile time". Testing the correctnes of a program
> > written in Turing-complete languge is the equivalent of solving
> > the halting problem.
> >
> > Besides:
> >
> > Does Ada catch the equivalent of C's
> >
> > int x[10];
> > int i;
> > scanf ("%d", &i);
> > x[i] = 42;
> >
> > at compile-time because x[i] might overflow?
> >
> > At run-time is a different kettle of fish, of course. Even so,
> > how does Ada guarantee that there is no overcommitment of memory
> > on Linux, the OOM killer comes along and kills the process?
> I think, that's not what Mitch meant.
> Seems like he meant that in Ada compiler can guarantee, in compile time, that code below never prints Hello.
> So, there is no chance that code that relies on printing hello would be ever shipped.
<
Just to be sure, it is part of the ADA language that subscript ranges are checked.
Only if the compiler can guarantee that the subscript is never out of bounds is
the check removed.
>
> int x[10];
> int a=41;
> int i;
> scanf ("%d", &i);
> x[i] = 42;
> if (a==42) printf("Hello\n");

On Monday, September 20, 2021 at 7:17:28 AM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Sunday, September 19, 2021 at 2:20:16 PM UTC-5, EricP wrote:
> >> MitchAlsup wrote:
> >>> On Sunday, September 19, 2021 at 11:19:10 AM UTC-5, EricP wrote:
> >>>> MOVC3 accepts arbitrary registers to specify the length in bytes,
> >>> <
> >>> Could the length be provided by an immediate ? If not why ?
> >> Yes.
> > <
> > Then how is MOVC3 interruptable ?
> > I can see setting FirstPartDone, and updating the address pointers,
> > but how does one update the constant ? Or is this why R0..R5 get consumed
> > in the execution of MOVC3 ?
>
> In order to perform an interruptible, overlap-safe, MOVC3 (MemMove)
> that after completion leaves the source and dest address registers
> pointing at the next bytes to be read and written, requires they
> save 4 data items: the start or current source and dest addresses,
> the original buffer size, and the current copied count.
>
> PSW.FPD First Part Done flag is normally clear.
>
> At MOVC3 instruction start it copies the args into R0..R5 then
> sets PSW.FPD and does not increment the program counter.
> R0,R1 = len1,addr1 R2,R3 = len2,addr2 R4,R5 = len3,addr3
>
> After that it uses temp regs until lengths = 0 then
> clear PSW.FPD and increments PC.
>
> On interrupt or exception R0..R5 are updated for changes and
> the non-incremented PC and PSW are saved on stack.
> On Return From Interrupt the PC & PSW is restored and it re-fetches the
> MOVC instruction. It checks the PSW.FPD and finds it set so skips
> copying args into R0..R5, just uses them as is.
<
I would just like to note:: this is a bad implementation--there are HW
implementations where the memmove is packaged up and shipped
over to the cache section, where there are no SW visible registers, to
be carried out as (1× or 2×) wide as the cache access path per cycle.
>
> There are details like auto-increment of arg registers that are
> likely also controlled by PSW.FPD too as the source args must be
> evaluated serially and copied before execution of the MOVC starts
> in case there are arg register or memory dependencies.
<
As done in VAX, MOVC3 is microcode of a vectorizable loop.
>
> So the instruction args must be evaluated, serially, once at the start
> and not again as you might be MOVC'ing over top of some args that use
> auto-increment double indirect addressing (with byte overlaps).
<
I have even less sympathy for trashing your arguments to an instruction
IN that instructions (than for misusing memcpy)
>
> Of course the whole thing could have been simplified if they had
> just defined that the string instruction args are in registers R0..R5.
> But that would not be the VAX way.
<
Which is why it died out !! (Hint:: there is a lesson to be learned here.)

On Monday, September 20, 2021 at 7:53:36 AM UTC-5, Terje Mathisen wrote:
> Michael S wrote:
> > On Monday, September 20, 2021 at 11:13:14 AM UTC+3, David Brown wrote:
> >> Any programmer who does that
> >> should, of course, be fired - their job is to read the minds of every
> >> third-rate coder out there and figure out what that person /meant/ to
> >> write, with a total disregard for the efficiency of code written by
> >> people who know what they are doing.
> >>
> >> Still, in this particular case I do understand that there are so many
> >> cases where people have got this wrong, and used memcpy when they meant
> >> memmove,
> >
> > I am afraid, it's worse.
> > Those people used memcpy() when they meant
> > for (int i=0; i < len, ++i) ((char*)dst)[i]=((char*)src)[i];
> > And they were relying on replication effect in case when src < dst < src+len.
> No, they were like me who read many years ago that the code above is
> _exactly_ how memcpy() is supposed to work.
<
That was true in 1983, but not in 1993.
You can still get that behavior using::
my_memcpy(char *dst, char *src, int len){}
You just cannot rely on the portable library function any more.
>
> I.e. the pointer-based version below is more or less the definition from
> my textbooks (modulo void vs char, return value etc):
>
> void memcpy(char *dst, char *src, int len)
> {
> while (len--) *dst++ = *src++;
> }
>
> This would be in the same chapter as strcpy() where the loop would be
> soemthing like:
>
> do { char c = *dst++ = *src++; } while (c);
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On Mon, 20 Sep 2021 07:56:31 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

>George Neuner <gneuner2@comcast.net> schrieb:
>> On Sun, 19 Sep 2021 13:28:10 -0700 (PDT), MitchAlsup
>><MitchAlsup@aol.com> wrote:
>>
>>>We can conclude from this that "computer science" is not science--it fails
>>>to learn form its own past.
>>
>> A good rule of thumb to keep in mind is that anything that calls
>> itself "science" probably isn’t.
>> -- John R. Searle
>
>In numerical analysis, optimization means finding a minimizer
>for some objective function. In compilation, optimization means
>running some series of passes & declaring victory. The definition
>from numerical analysis seems more rigorous.
>
> -- Keith Cooper

+1 8-)

On 20/09/2021 15:21, EricP wrote:
> David Brown wrote:
>> On 19/09/2021 19:50, EricP wrote:
>>> MitchAlsup wrote:
>>>> On Sunday, September 19, 2021 at 7:14:52 AM UTC-5, Anton Ertl wrote:
>>>>> Unfortunately, that's not sufficient to get rid of memcpy(); we
>>>>> tried, but the library incompatibility problem outlined above
>>>>> persisted. IIRC gcc produces calls to memcpy() when you copy some
>>>>> structs or somesuch.
>>>> <
>>>> Yes but !!
>>>> <
>>>> a structure assignment: s1 = s2; is never in a position where s1 and
>>>> s2 overlap; and therefore nobody cares which direction, or how wide,
>>>> any
>>>> data transfer happens to be.
>>> An array of S's can be shifting elements with overlapping slices.
>>>
>>> If s1 and s2 are structs in different areas of a union and passed
>>> to a subroutine void DoCopy (struct S *s1, struct S *s2);
>>>
>>>   union
>>>   {  struct S s1;
>>>      struct
>>>      {  int  i;
>>>         struct S s2;
>>>      } foo;
>>>   } u;
>>>
>>> DoCopy cannot prove its args do not overlap so should use memmove.
>>>
>>
>> I think there is a subtle point here.
>>
>> I did some testing with:
>>
>>
>> struct S { int a; int b[103]; };
>>
>>   union
>>   {  struct S s1;
>>      struct
>>      {  int  i;
>>         struct S s2;
>>      } foo;
>>   } u;
>>
>> void foo1(void) {
>>     u.s1 = u.foo.s2;
>> }
>>
>> void foo2(void) {
>>     u.foo.s2 = u.s1;
>> }
>>
>> void DoCopy (struct S *s1, struct S *s2) {
>>     *s1 = *s2;
>> }
>>
>>
>> Testing with gcc and clang shows that they both use memcpy (or a "rep
>> movsq" sequence on x86 that I /think/ assumes there is no overlap - but
>> I am not an expert on x86 assembly).
>>
>> It's not often that the gcc folk are wrong about this kind of thing.
>> (Overly pedantic or unhelpful, perhaps, but not wrong.)  It's even rarer
>> for both gcc and clang to be wrong.
>>
>>
>> I believe the answer is in the C standards, 6.5.16.1p3, regarding the
>> semantics of the assignment operator:
>>
>> """
>> If the value being stored in an object is read from another object that
>> overlaps in any way the storage of the first object, then the overlap
>> shall be exact and the two objects shall have qualified or unqualified
>> versions of a compatible type; otherwise, the behavior is undefined.
>> """
>>
>> So if you have "s1 = s2", then either they do not overlap at all, or
>> they are the same object (in which case memcpy will still be fine in
>> practice).
>
> Try it with -fno-strict-aliasing.

It makes no difference (which is not a surprise, since it is not an
aliasing issue - the types of s1 and s2 are the same).

> It should switch to the equivalent of memove which would test
> if (source_addr < dest_addr) and CLD/STD clear/set the direction flag
> before REP MOVSQ.

I'm sorry, my x86 assembly is not advanced enough to have a good
understanding of the "rep mov" stuff, so I could easily misinterpret
here. Just use <https://godbolt.org> and pick a different gcc target -
for many non-x86 devices, you get a call to memcpy.

>
> From what I've read, Linux and other OS's must compile
> with -fno-strict-aliasing to function as programmers intended.
>
> Most of my applications would too if my MS compiler
> didn't assume this anyway.
>

Are you /sure/ MSVC assumes no strict aliasing? Is it clearly
documented as a feature? A lot of people assume MSVC has wrapping
signed integer arithmetic, and they are wrong about that - it simply has
weak optimisation in some areas. (In the case of signed integer
arithmetic, they document that they do /not/ have guaranteed wrapping
semantics.)

Anyway, it is not an aliasing matter. And MSVC for ARM generates calls
to memcpy for the test code. (Though for MSVC, the same vendor controls
the compiler and the library - they /could/ have internal documentation
noting that their memcpy implementation works like memmove.)

On 20/09/2021 16:13, Michael S wrote:
> On Monday, September 20, 2021 at 4:53:34 PM UTC+3, EricP wrote:
>> Michael S wrote:
>>> On Monday, September 20, 2021 at 1:40:03 PM UTC+3, David Brown wrote:
>>>> On 20/09/2021 12:18, Michael S wrote:
>>>>> On Monday, September 20, 2021 at 11:13:14 AM UTC+3, David Brown wrote:
>>>>>>
>>>>>> Still, in this particular case I do understand that there are so many
>>>>>> cases where people have got this wrong, and used memcpy when they meant
>>>>>> memmove,
>>>>> I am afraid, it's worse.
>>>>> Those people used memcpy() when they meant
>>>>> for (int i=0; i < len, ++i) ((char*)dst)[i]=((char*)src)[i];
>>>>> And they were relying on replication effect in case when src < dst < src+len.
>>>>>
>>>> That is what memmove is for. Memmove works even if the source and
>>>> destination overlap.
>>>
>>> No, memmove has no replication effect that they wanted.
>> The definition in the C12 standard says
>>
>> "The memmove function copies n characters from the object pointed to
>> by s2 into the object pointed to by s1. Copying takes place as if
>> the n characters from the object pointed to by s2 are first copied
>> into a temporary array of n characters that does not overlap the
>> objects pointed to by s1 and s2, and then the n characters from the
>> temporary array are copied into the object pointed to by s1."
>>
>> That definition would seem to explicitly *exclude* replication.
>>
>
> That what I said above. David Brown undoubtedly knows it as well.
>

Yes. I had just misunderstood your post - sorry for the confusion, and
I hope my reply cleared it up.

>> Is there any implementation of memmove that actually works by
>> using a temp array for overlap? Certainly the REP MOVS don't do this.

Thomas Koenig <tkoenig@netcologne.de> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>Just to get the general philosphy behind Linus T's reasoning.
>>>
>>>A compiler change that introduces a bug in a user program is bad.
>>>It does not matter if the program relied on an implementation
>>>detail not specified either by the compiler or the standard, or
>>>if another compiler or another architecture does this differently.
>>>
>>>Did I sum that up correctly?
>>
>> Correct.
>>
>>>There is no specification that a compiler writer could follow.
>>>The respective language standards are irrelevant. Past behavior
>>>is all that counts, and pointing out that his program is errnoneous
>>>is a no-no.
>>
>> Correct.
>
>You subsccibe to "language standards are irrelevant"?

In those places where a standard does not specify anything (as the C
standard does for undefined behaviour), they certainly are. Isn't
that obvious?

>Just one question: Is there a clear specification anywhere that,
>in your opinion, compiler writers should adhere to, some sort of
>additional standard document (approved by whom?) that clearly,
>explicitly and unabiguously defines the areas left undefined by
>the C standard?

Lots of adverbs. Probably more than necessary. Anyway, the document
you should read (although it's not quite what you are asking for) is

http://www.complang.tuwien.ac.at/papers/ertl17kps.pdf

>Or is it restricted to the bugs that Linus Torvalds and yourself
>find irritating?

Are you so out of arguments that you have to resort to personal
attacks?

>>>The consequence is clear - compiler writers should stop fixing
>>>bugs because fixing a bug might change the observable behavior of
>>>existing programs, which is bad.
>>
>> Somehow you took a wrong turn here. The issue is not whether it *might*
>> change the observable behaviour
>
>Trivially, any wrong-code bug changes observable behavior.
>
>>(that's Bedenkentraeger thinking), but
>> whether it *does*, and whether the user experiences that as regression.
>
>Users complain about compiler bugs all the time. Sometimes they
>are right, most of the time they are not.
>
>> Note that Linux bugs are fixed all the time, despite the "We don't
>> break userspace" rule in Linux.
>
>We are talking compilers here.

What makes you think that there is a fundamental difference in this
area between a programming language and the API of an OS? OS
standards also leave some things undefined.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Thomas Koenig <tkoenig@netcologne.de> writes:
>Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>And even so, according to Linus T's definition, if code like
>
> int x[10];
> int a;
>
>...
>
> x[10] = 42;
> assert (a == 42);
>
>ever "worked" on any system, it would have to be kept that way -
>mandating stack layout of variables, keeping a from being kept in
>a register etc.
>
>Is that really what people want?

Is it? Do you have a bug report with that?

Instead of putting up straw men, better discuss real issues. We have
been discussing memcpy() and the regression introduced by the glibc
maintainers. This regression could be fixed easily with a
close-to-zero performance impact.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Michael S <already5chosen@yahoo.com> writes:
>On Monday, September 20, 2021 at 11:13:14 AM UTC+3, David Brown wrote:
>> Still, in this particular case I do understand that there are so many
>> cases where people have got this wrong, and used memcpy when they meant
>> memmove,
>
>I am afraid, it's worse.
>Those people used memcpy() when they meant
>for (int i=0; i < len, ++i) ((char*)dst)[i]=((char*)src)[i];
>And they were relying on replication effect in case when src < dst < src+len.

Which case are you talking about? The problems I read about were
eventually resolved by giving old binaries memmove() when they asked
for memcpy(). The result worked, so they were obviously not relying
on the replication effect. Also, I dimly remember that it was about
corrupted sound on some CPUs; I really don't see how the replication
effect would help here. On the contrary, I expect corrupted sounds
from the replication effect. So my guess is that they were copying to
overlapping lower addresses, which worked as intended (like memmove())
with a forward-stride memcpy(), but got unintended replication with
backward-stride memcpy().

I also doubt that the earlier glibc had implemented memcpy() to behave
like the code you posted (maybe very early, but not in the 2000s).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Michael S <already5chosen@yahoo.com> writes:
>IMHO, the main issue is that memcpy instruction can't start until at least two out of three pieces of the puzzle,
>i.e src and count, are in place. In practice, in order to reduce complexity, implementation will likely wait for dst, too.
>On the other hand, load+store based fixed-length copy needs only src to initiate loads.

Given that count is a constant in the cases we are discussing here, it
is available early, so at least in that respect both approaches just
have to wait for src.

I guess with count available as immediate value, a sufficiently
capable front end can produce a sequence of microinstructuons at least
as good as the compiler you have in mind (but better tuned for the
architecture and microarchitecture). At least in theory; the story of
REP MOVSB has not made me optimisitic about such things.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

EricP <ThatWouldBeTelling@thevillage.com> writes:

> Michael S wrote:
>> On Monday, September 20, 2021 at 1:40:03 PM UTC+3, David Brown wrote:
>>> On 20/09/2021 12:18, Michael S wrote:
>>>> On Monday, September 20, 2021 at 11:13:14 AM UTC+3, David Brown
>>>> wrote:
>>>>>
>>>>> Still, in this particular case I do understand that there are so
>>>>> many cases where people have got this wrong, and used memcpy when
>>>>> they meant memmove,
>>>> I am afraid, it's worse. Those people used memcpy() when they
>>>> meant for (int i=0; i < len, ++i) ((char*)dst)[i]=((char*)src)[i];
>>>> And they were relying on replication effect in case when src < dst
>>>> < src+len.
>>>>
>>> That is what memmove is for. Memmove works even if the source and
>>> destination overlap.
>>
>> No, memmove has no replication effect that they wanted.
>
> The definition in the C12 standard says
>
> "The memmove function copies n characters from the object pointed to
> by s2 into the object pointed to by s1. Copying takes place as if
> the n characters from the object pointed to by s2 are first copied
> into a temporary array of n characters that does not overlap the
> objects pointed to by s1 and s2, and then the n characters from the
> temporary array are copied into the object pointed to by s1."
>
> That definition would seem to explicitly *exclude* replication.
>
> Is there any implementation of memmove that actually works by
> using a temp array for overlap? Certainly the REP MOVS don't do this.

One time I got an out of memory error on a big memmove on Borland C. I
probably picked up some bad "not invented here" habits from that
experience.

On Monday, September 20, 2021 at 5:36:15 PM UTC-5, Josh Vanderhoof wrote:
> EricP <ThatWould...@thevillage.com> writes:
>
> > Michael S wrote:
> >> On Monday, September 20, 2021 at 1:40:03 PM UTC+3, David Brown wrote:
> >>> On 20/09/2021 12:18, Michael S wrote:
> >>>> On Monday, September 20, 2021 at 11:13:14 AM UTC+3, David Brown
> >>>> wrote:
> >>>>>
> >>>>> Still, in this particular case I do understand that there are so
> >>>>> many cases where people have got this wrong, and used memcpy when
> >>>>> they meant memmove,
> >>>> I am afraid, it's worse. Those people used memcpy() when they
> >>>> meant for (int i=0; i < len, ++i) ((char*)dst)[i]=((char*)src)[i];
> >>>> And they were relying on replication effect in case when src < dst
> >>>> < src+len.
> >>>>
> >>> That is what memmove is for. Memmove works even if the source and
> >>> destination overlap.
> >>
> >> No, memmove has no replication effect that they wanted.
> >
> > The definition in the C12 standard says
> >
> > "The memmove function copies n characters from the object pointed to
> > by s2 into the object pointed to by s1. Copying takes place as if
> > the n characters from the object pointed to by s2 are first copied
> > into a temporary array of n characters that does not overlap the
> > objects pointed to by s1 and s2, and then the n characters from the
> > temporary array are copied into the object pointed to by s1."
> >
> > That definition would seem to explicitly *exclude* replication.
> >
> > Is there any implementation of memmove that actually works by
> > using a temp array for overlap? Certainly the REP MOVS don't do this.
<
One can obtain this semantic by using registers as the buffer.
<
Also not MVC in S/360 is memcpy not memmove--and while in this day and age
I consider this a mistake, it very well have been a deliberate choice by the S/360
architecture team. The ASM manual shows moving a zero character MVI into
the starting location of a buffer and using MVC to replicate the zero, smearing
it across the whole.
<
> One time I got an out of memory error on a big memmove on Borland C. I
> probably picked up some bad "not invented here" habits from that
> experience.

On 9/20/2021 6:01 PM, MitchAlsup wrote:
> On Monday, September 20, 2021 at 5:36:15 PM UTC-5, Josh Vanderhoof wrote:
>> EricP <ThatWould...@thevillage.com> writes:
>>
>>> Michael S wrote:
>>>> On Monday, September 20, 2021 at 1:40:03 PM UTC+3, David Brown wrote:
>>>>> On 20/09/2021 12:18, Michael S wrote:
>>>>>> On Monday, September 20, 2021 at 11:13:14 AM UTC+3, David Brown
>>>>>> wrote:
>>>>>>>
>>>>>>> Still, in this particular case I do understand that there are so
>>>>>>> many cases where people have got this wrong, and used memcpy when
>>>>>>> they meant memmove,
>>>>>> I am afraid, it's worse. Those people used memcpy() when they
>>>>>> meant for (int i=0; i < len, ++i) ((char*)dst)[i]=((char*)src)[i];
>>>>>> And they were relying on replication effect in case when src < dst
>>>>>> < src+len.
>>>>>>
>>>>> That is what memmove is for. Memmove works even if the source and
>>>>> destination overlap.
>>>>
>>>> No, memmove has no replication effect that they wanted.
>>>
>>> The definition in the C12 standard says
>>>
>>> "The memmove function copies n characters from the object pointed to
>>> by s2 into the object pointed to by s1. Copying takes place as if
>>> the n characters from the object pointed to by s2 are first copied
>>> into a temporary array of n characters that does not overlap the
>>> objects pointed to by s1 and s2, and then the n characters from the
>>> temporary array are copied into the object pointed to by s1."
>>>
>>> That definition would seem to explicitly *exclude* replication.
>>>
>>> Is there any implementation of memmove that actually works by
>>> using a temp array for overlap? Certainly the REP MOVS don't do this.
> <
> One can obtain this semantic by using registers as the buffer.
> <
> Also not MVC in S/360 is memcpy not memmove--and while in this day and age
> I consider this a mistake, it very well have been a deliberate choice by the S/360
> architecture team. The ASM manual shows moving a zero character MVI into
> the starting location of a buffer and using MVC to replicate the zero, smearing
> it across the whole.

When I was taught S/360 assembler in the early 1970s, I was taught that
the way to define a print line buffer was 132 bytes preceded by a
constant EBCDIC space/blank character. That way, you could do an MVC to
set the print line to all blanks. I was too new/young to question it.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Thomas Koenig [2021-09-20 07:53:04] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>>>> No, people want that kind of stuff found at compile time.
>>> Not possible in the more general case, as you know.
>> Of course it's possible. You just have to design your language
>> accordingly, but lots of languages have solved most of those problems
>> (tho many have introduced others).
> Not at compile-time (which is what Mitch wrote above).

Yes, AFAIK many languages eliminate the problem altogether, so they
reject such problematic code at compile time.

Stefan

> You wrote "at compile time". Testing the correctnes of a program
> written in Turing-complete languge is the equivalent of solving
> the halting problem.

No it's not. Type checking is the typical example, which lots and lots
of compilers perform quite reliably without bumping into the halting
problem, even though those languages are Turing complete.

All you need to check the correctness of a program is to ask someone to
give you a proof of that correctness and then you simply check
the proof. In the case of static typing, the "proof" is obtained from
the type annotations and checking the proof is called "type checking".

Similarly, it's easy to check that a program halts by asking someone to
give you a proof that it does and then checking the proof.

The key, as you can see, is to reject the programs for which you can't
check the proof.

Stefan

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>> You wrote "at compile time". Testing the correctnes of a program
>> written in Turing-complete languge is the equivalent of solving
>> the halting problem.
>
> No it's not. Type checking is the typical example, which lots and lots
> of compilers perform quite reliably without bumping into the halting
> problem, even though those languages are Turing complete.

That is only a small sliver of overall correctness.

> All you need to check the correctness of a program is to ask someone to
> give you a proof of that correctness and then you simply check
> the proof.

"Simply" is the wrong word here, I think...

Just one minor example: Linear equation solvers are a field where
there are actually lots of proofs about convergence and so on,
but these are typically over the field of real, numbers, not
computer floating-point numbers.

So, insisting your method would remove most existing CFD codes.

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>Just to get the general philosphy behind Linus T's reasoning.
>>>>
>>>>A compiler change that introduces a bug in a user program is bad.
>>>>It does not matter if the program relied on an implementation
>>>>detail not specified either by the compiler or the standard, or
>>>>if another compiler or another architecture does this differently.
>>>>
>>>>Did I sum that up correctly?
>>>
>>> Correct.
>>>
>>>>There is no specification that a compiler writer could follow.
>>>>The respective language standards are irrelevant. Past behavior
>>>>is all that counts, and pointing out that his program is errnoneous
>>>>is a no-no.
>>>
>>> Correct.
>>
>>You subsccibe to "language standards are irrelevant"?
>
> In those places where a standard does not specify anything (as the C
> standard does for undefined behaviour), they certainly are. Isn't
> that obvious?
>
>>Just one question: Is there a clear specification anywhere that,
>>in your opinion, compiler writers should adhere to, some sort of
>>additional standard document (approved by whom?) that clearly,
>>explicitly and unabiguously defines the areas left undefined by
>>the C standard?
>
> Lots of adverbs. Probably more than necessary. Anyway, the document
> you should read (although it's not quite what you are asking for) is
>
> http://www.complang.tuwien.ac.at/papers/ertl17kps.pdf

Has that paper actually been peer-reviewed and published?
It certainly uses some rather inflammatory terminology,
which might hinder its acceptance.

However, even if it is published, such a document changes nothing.

If you actually wanted to achieve anything, you would have to
write up a paper for WG14 for an expanded set of guarantees on C,
which would then be up for discussion for inclusion in the next
standard.

If you say "Oh, but it wouldn't be accepted anyway" then you
already have your answer.

>>Or is it restricted to the bugs that Linus Torvalds and yourself
>>find irritating?
>
> Are you so out of arguments that you have to resort to personal
> attacks?

Clearly not, because I didn't write a personal attack above.

Maybe something more according to your sensibilities...

The Linux man page for memcpy states

The memcpy() function copies n bytes from memory area src
to memory area dest. The memory areas must not overlap.
Use memmove(3) if the memory areas do overlap.

The OpenBSD man page for memcpy states

The memcpy() function copies len bytes from buffer src to
buffer dst. If the two buffers may overlap, memmove(3)
must be used instead.

Something more exotic (nowadays): The Solaris manpage for memypc
states:

The memcpy() function copies n bytes from memory area
s2 to s1. It returns s1. If copying takes place between
objects that overlap, the behavior is undefined.

Not reading the manpage for a function that is used is a rather
stupid mistake. I am not surprised that this occurred in Flash,
which is a close contender for the prize of being worst-written
piece of software ever (which is why it was removed from any
browser that I know).

Now, you suggest that the errors of incompetent programmers should
be papered over. However, which errors? There has to be some
selection criteria, and the choice of just which errors to accept
has to be based on something. You have your preference, Linus T has
his prefrence, and that seems to be what you were advocating.
I have other preferences (unsurprisingly).

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>>And even so, according to Linus T's definition, if code like
>>
>> int x[10];
>> int a;
>>
>>...
>>
>> x[10] = 42;
>> assert (a == 42);
>>
>>ever "worked" on any system, it would have to be kept that way -
>>mandating stack layout of variables, keeping a from being kept in
>>a register etc.
>>
>>Is that really what people want?
>
> Is it? Do you have a bug report with that?

I can write one up in a minute, if you prefer.

I assume you would not take it seriously, but that's the question:
If you advocate for no user-observable change, which bug reports
would you take seriously and which ones would not you not take
seriously?

> Instead of putting up straw men,

Just pointing out the consequences of what was advocated.

> better discuss real issues. We have
> been discussing memcpy() and the regression introduced by the glibc
> maintainers. This regression could be fixed easily with a
> close-to-zero performance impact.

Not a regression.

There is another point to this. If an interface comes with
additional guarantees not proscribed by the standard, then the
software relying on the extra guarantees is not portable to
other systems where those extra guarantees do not apply.

This is a Bad Thing (TM).

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:

> When I was taught S/360 assembler in the early 1970s, I was taught that
> the way to define a print line buffer was 132 bytes preceded by a
> constant EBCDIC space/blank character. That way, you could do an MVC to
> set the print line to all blanks. I was too new/young to question it.

A blank was also a standard "new line" control characters for
printers. "+" was overstrike, and "1" was a new page.

David Brown wrote:
> On 20/09/2021 15:21, EricP wrote:
>> David Brown wrote:
>>> On 19/09/2021 19:50, EricP wrote:
>>>> MitchAlsup wrote:
>>>>> On Sunday, September 19, 2021 at 7:14:52 AM UTC-5, Anton Ertl wrote:
>>>>>> Unfortunately, that's not sufficient to get rid of memcpy(); we
>>>>>> tried, but the library incompatibility problem outlined above
>>>>>> persisted. IIRC gcc produces calls to memcpy() when you copy some
>>>>>> structs or somesuch.
>>>>> <
>>>>> Yes but !!
>>>>> <
>>>>> a structure assignment: s1 = s2; is never in a position where s1 and
>>>>> s2 overlap; and therefore nobody cares which direction, or how wide,
>>>>> any
>>>>> data transfer happens to be.
>>>> An array of S's can be shifting elements with overlapping slices.
>>>>
>>>> If s1 and s2 are structs in different areas of a union and passed
>>>> to a subroutine void DoCopy (struct S *s1, struct S *s2);
>>>>
>>>> union
>>>> { struct S s1;
>>>> struct
>>>> { int i;
>>>> struct S s2;
>>>> } foo;
>>>> } u;
>>>>
>>>> DoCopy cannot prove its args do not overlap so should use memmove.
>>>>
>>> I think there is a subtle point here.
>>>
>>> I did some testing with:
>>>
>>>
>>> struct S { int a; int b[103]; };
>>>
>>> union
>>> { struct S s1;
>>> struct
>>> { int i;
>>> struct S s2;
>>> } foo;
>>> } u;
>>>
>>> void foo1(void) {
>>> u.s1 = u.foo.s2;
>>> }
>>>
>>> void foo2(void) {
>>> u.foo.s2 = u.s1;
>>> }
>>>
>>> void DoCopy (struct S *s1, struct S *s2) {
>>> *s1 = *s2;
>>> }
>>>
>>>
>>> Testing with gcc and clang shows that they both use memcpy (or a "rep
>>> movsq" sequence on x86 that I /think/ assumes there is no overlap - but
>>> I am not an expert on x86 assembly).
>>>
>>> It's not often that the gcc folk are wrong about this kind of thing.
>>> (Overly pedantic or unhelpful, perhaps, but not wrong.) It's even rarer
>>> for both gcc and clang to be wrong.
>>>
>>>
>>> I believe the answer is in the C standards, 6.5.16.1p3, regarding the
>>> semantics of the assignment operator:
>>>
>>> """
>>> If the value being stored in an object is read from another object that
>>> overlaps in any way the storage of the first object, then the overlap
>>> shall be exact and the two objects shall have qualified or unqualified
>>> versions of a compatible type; otherwise, the behavior is undefined.
>>> """
>>>
>>> So if you have "s1 = s2", then either they do not overlap at all, or
>>> they are the same object (in which case memcpy will still be fine in
>>> practice).
>> Try it with -fno-strict-aliasing.
>
> It makes no difference (which is not a surprise, since it is not an
> aliasing issue - the types of s1 and s2 are the same).
>
>> It should switch to the equivalent of memove which would test
>> if (source_addr < dest_addr) and CLD/STD clear/set the direction flag
>> before REP MOVSQ.
>
> I'm sorry, my x86 assembly is not advanced enough to have a good
> understanding of the "rep mov" stuff, so I could easily misinterpret
> here. Just use <https://godbolt.org> and pick a different gcc target -
> for many non-x86 devices, you get a call to memcpy.
>
>> From what I've read, Linux and other OS's must compile
>> with -fno-strict-aliasing to function as programmers intended.
>>
>> Most of my applications would too if my MS compiler
>> didn't assume this anyway.
>>
>
> Are you /sure/ MSVC assumes no strict aliasing? Is it clearly
> documented as a feature? A lot of people assume MSVC has wrapping
> signed integer arithmetic, and they are wrong about that - it simply has
> weak optimisation in some areas. (In the case of signed integer
> arithmetic, they document that they do /not/ have guaranteed wrapping
> semantics.)

My MS documentation says similar to K&R (remember, MS is C-89),
that one can cast between pointers, and between pointer and int.

And like the C standards it does not say that one can actually use
a pointer after a cast, but its restrictions are based on alignment
or size mismatch.

From my Visual Studio documentation:

Conversions to and from Pointer Types:
"A pointer to one type of value can be converted to a pointer to a
different type. However, the result may be undefined because of the
alignment requirements and sizes of different types in storage.
A pointer to an object can be converted to a pointer to an object
whose type requires less or equally strict storage alignment,
and back again without change."

*HOWEVER* the MS documentation has many examples of where casting
between types is a necessary part of the API design.
A routine may return a handle which is an unsigned long,
and document that the handle is actually a pointer to 'blah'.

The entire Windows kernel and all drivers depends on being able to cast
a pointer to one data type into a pointer to a different type, with the
onus of getting restrictions like alignment correct on the programmer.

The classic example is from the device driver programming guide,
on managing linked lists of objects. The C macro
CONTAINING_RECORD(Address,Type,Field)
is passed an Address, a data struct Type contains that address,
and the Field in that Type that is that address.
CONTAINING_RECORD subtracts from Address the byte offset of the Field
and returns a pointer to Type.

I use the same techniques for handling objects that are members
of multiple linked lists, trees, index tables, etc. when needed.

The following is from the driver programmers guide
(it's their naming convention, not mine):

typedef struct {
// driver-defined members
.
.
. SINGLE_LIST_ENTRY SingleListEntry;

// other driver-defined members
.
.
.
} XXX_ENTRY;

We can push an entry onto a single linked list by

PushEntryList(&ListHead, &myObject->SingleListEntry);

Note that it puts the address of the field in the middle of its struct
on the list. We can pop that entry back off the list and convert it
back to a pointer to myObject with:

PopXxxEntry(PSINGLE_LIST_ENTRY ListHead, PXXX_ENTRY Entry)
{
PSINGLE_LIST_ENTRY SingleListEntry;

SingleListEntry = PopEntryList(ListHead);
return CONTAINING_RECORD(SingleListEntry, XXX_ENTRY, SingleListEntry);
}

The above pops an entry, a pointer to a SINGLE_LIST_ENTRY,
off a circular single linked list. That pointer is actually the
address of a field named SingleListEntry in type XXX_ENTRY.
The macro CONTAINING_RECORD subtracts the field offset to SingleListEntry.
It returns a pointer to XXX_ENTRY.

When combined with other techniques to validate data types,
validity check markers on all major data types, it is very reliable
(I have never had any programming errors using it).

This technique is used throughout the WinNT OS, so if the compiler
stopped allowing pointer casts between types, MS won't have a product
to sell or any drivers.

==============

The switch from signed ints that wrap to linear they can get away
with because their products aren't fundamentally dependent on it.
And as far as I know MS never said they wrapped signed ints so
suddenly switching so non wrapping wouldn't bother them.
Besides, they have never shows much hesitancy to abandon customers.
After 25 years of actively promoting inline assembler in C,
they suddenly dropped it on x64, and it was tough-titties to
everyone who had inline assembler.

> Anyway, it is not an aliasing matter. And MSVC for ARM generates calls
> to memcpy for the test code. (Though for MSVC, the same vendor controls
> the compiler and the library - they /could/ have internal documentation
> noting that their memcpy implementation works like memmove.)

In my original example, the compilers' alias detection should see that the
union S changes the offset and understand that those objects MAY overlap.
It cannot prove that they do not overlap so it must assume they might
(and in this case it should _know_ that they overlap).

David Brown wrote:
> On 20/09/2021 15:21, EricP wrote:
>> David Brown wrote:
>>> On 19/09/2021 19:50, EricP wrote:
>>>> MitchAlsup wrote:
>>>>> On Sunday, September 19, 2021 at 7:14:52 AM UTC-5, Anton Ertl wrote:
>>>>>> Unfortunately, that's not sufficient to get rid of memcpy(); we
>>>>>> tried, but the library incompatibility problem outlined above
>>>>>> persisted. IIRC gcc produces calls to memcpy() when you copy some
>>>>>> structs or somesuch.
>>>>> <
>>>>> Yes but !!
>>>>> <
>>>>> a structure assignment: s1 = s2; is never in a position where s1 and
>>>>> s2 overlap; and therefore nobody cares which direction, or how wide,
>>>>> any
>>>>> data transfer happens to be.
>>>> An array of S's can be shifting elements with overlapping slices.
>>>>
>>>> If s1 and s2 are structs in different areas of a union and passed
>>>> to a subroutine void DoCopy (struct S *s1, struct S *s2);
>>>>
>>>> union
>>>> { struct S s1;
>>>> struct
>>>> { int i;
>>>> struct S s2;
>>>> } foo;
>>>> } u;
>>>>
>>>> DoCopy cannot prove its args do not overlap so should use memmove.
>>>>
>>> I think there is a subtle point here.
>>>
>>> I did some testing with:
>>>
>>>
>>> struct S { int a; int b[103]; };
>>>
>>> union
>>> { struct S s1;
>>> struct
>>> { int i;
>>> struct S s2;
>>> } foo;
>>> } u;
>>>
>>> void foo1(void) {
>>> u.s1 = u.foo.s2;
>>> }
>>>
>>> void foo2(void) {
>>> u.foo.s2 = u.s1;
>>> }
>>>
>>> void DoCopy (struct S *s1, struct S *s2) {
>>> *s1 = *s2;
>>> }
>>>
>>>
>>> Testing with gcc and clang shows that they both use memcpy (or a "rep
>>> movsq" sequence on x86 that I /think/ assumes there is no overlap - but
>>> I am not an expert on x86 assembly).
>>>
>>> It's not often that the gcc folk are wrong about this kind of thing.
>>> (Overly pedantic or unhelpful, perhaps, but not wrong.) It's even rarer
>>> for both gcc and clang to be wrong.
>>>
>>>
>>> I believe the answer is in the C standards, 6.5.16.1p3, regarding the
>>> semantics of the assignment operator:
>>>
>>> """
>>> If the value being stored in an object is read from another object that
>>> overlaps in any way the storage of the first object, then the overlap
>>> shall be exact and the two objects shall have qualified or unqualified
>>> versions of a compatible type; otherwise, the behavior is undefined.
>>> """
>>>
>>> So if you have "s1 = s2", then either they do not overlap at all, or
>>> they are the same object (in which case memcpy will still be fine in
>>> practice).
>> Try it with -fno-strict-aliasing.
>
> It makes no difference (which is not a surprise, since it is not an
> aliasing issue - the types of s1 and s2 are the same).

I changed this slightly and made the first field a char so it won't
align nicely and compiled on MSVC with struct packing of 1 byte /Zp1
so it won't pad the fields and tried it on Godbolt MSVC v19.latest
with various optimizations -O2 -Ob3 -Ze -Zp1 -W4 -Tc

#include <memory.h>

struct S { char a; int b[103]; };

union
{ struct S s1;
struct
{ char i;
struct S s2;
} foo;
} u;

void foo1(void) {
u.s1 = u.foo.s2;
}

void foo2(void) {
u.foo.s2 = u.s1;
}

void DoCopy1 (struct S *s1, struct S *s2) {
*s1 = *s2;
}

void DoCopy2 (struct S *s1, struct S *s2) {
memcpy (s1, s2, sizeof(struct S));
}

void DoCopy3 (void *v1, void *v2) {
char *c1;
struct S *s1, *s2;
c1 = (char*) v1;
s1 = (struct S*) c1;
s2 = (struct S*) v2;
*s1 = *s2;
}

void DoCopy4 (struct S *s1, struct S *s2) {
memmove (s1, s2, sizeof(struct S));
}

- For MS compiler, no matter what options I tried, the assembler for
DoCopy1, DoCopy2, DoCopy3 are always identical and the same as
foo1 and foo2.

- For foo1, foo2, DoCopy1, DoCopy2, DoCopy3 it always assumes the
structs are not overlapped and either generates a memcpy as
REP MOVSB
with no direction test, so forward only,
or an inline move sequence using XMM registers,
again ignoring the byte offset overlap.

- For DoCopy4 it generates a jump to memmove library routine.

Bottom line: MS VC compiler is ignoring all memory aliasing,
even in a union where it should know that it overlaps,
and generating moves that assume no overlap.

I see reference on StackOverflow that MS removed the compile option
Assume No aliasing /Oa in VS 2008 and replaced it with
__declspec(restrict) and __declspec(noalias) directives.

Optimization best practices
https://docs.microsoft.com/en-us/cpp/build/optimization-best-practices?view=msvc-160

It seems they think that it should assume memory aliasing unless
explicitly told not to, though it does not appear to function that way.

I don't know why this hasn't broken all Win32, kernel and driver code.

On Monday, September 20, 2021 at 9:34:00 PM UTC+3, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >IMHO, the main issue is that memcpy instruction can't start until at least two out of three pieces of the puzzle,
> >i.e src and count, are in place. In practice, in order to reduce complexity, implementation will likely wait for dst, too.
> >On the other hand, load+store based fixed-length copy needs only src to initiate loads.
> Given that count is a constant in the cases we are discussing here, it
> is available early, so at least in that respect both approaches just
> have to wait for src.
>
> I guess with count available as immediate value, a sufficiently
> capable front end can produce a sequence of microinstructuons at least
> as good as the compiler you have in mind (but better tuned for the
> architecture and microarchitecture). At least in theory; the story of
> REP MOVSB has not made me optimisitic about such things.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Yes, if count is immediate value, then good HW implementation could be as fast as inlined loads+stores even for small counts and aligned src/dst.
For non-aligned src/dst there is a potential to make it faster than loads+stores.

But in discussion about we were talking about count in register, like on x86 and, likely, on ARMv9, rather than about count as immediate value, which, if I am not mistaken, is available on S/360 (limited to 256B ?) since very beginning, but I am not aware on it being available on other popular architectures.

On Tuesday, September 21, 2021 at 11:52:39 AM UTC-5, Michael S wrote:
> On Monday, September 20, 2021 at 9:34:00 PM UTC+3, Anton Ertl wrote:
> > Michael S <already...@yahoo.com> writes:
> > >IMHO, the main issue is that memcpy instruction can't start until at least two out of three pieces of the puzzle,
> > >i.e src and count, are in place. In practice, in order to reduce complexity, implementation will likely wait for dst, too.
> > >On the other hand, load+store based fixed-length copy needs only src to initiate loads.
> > Given that count is a constant in the cases we are discussing here, it
> > is available early, so at least in that respect both approaches just
> > have to wait for src.
> >
> > I guess with count available as immediate value, a sufficiently
> > capable front end can produce a sequence of microinstructuons at least
> > as good as the compiler you have in mind (but better tuned for the
> > architecture and microarchitecture). At least in theory; the story of
> > REP MOVSB has not made me optimisitic about such things.
> > - anton
> > --
> > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
> Yes, if count is immediate value, then good HW implementation could be as fast as inlined loads+stores even for small counts and aligned src/dst.
<
The integer ADD function unit does not know whether the second operand came from a register
or came from an immediate. Why should the MM function unit know if the length was constant or
variable ? It seems to me this makes ZERO difference over at the function unit.
<
> For non-aligned src/dst there is a potential to make it faster than loads+stores.
<
Because one can reutilize the misalignedness of a first LD/STwith the misalignedness
of a second LD/ST. and save cycles. This is a great reason MM should not be done with
individual instructions--but places the burden on HW to never screw this up (like many
seem to have done).
>
> But in discussion about we were talking about count in register, like on x86 and, likely, on ARMv9, rather than about count as immediate value, which, if I am not mistaken, is available on S/360 (limited to 256B ?) since very beginning, but I am not aware on it being available on other popular architectures.
<
S/360 is memcpy
We have been arguing that the proper thing to build in HW is memmove and let memcpy have
lower performance.