memcpy/memmove upwards vs downwards

[Colin Leroy-Mira]

Hi!
The doc indicates that memcpy() on overlapping blocks is undefined, and we should use memmove() for that instead. Very well.

But then, memmove has code to choose the upwards/downwoards copy order to avoid overlap issues, implements downwards, and for upwards, calls memcpy's internals.

I suggest that we move things around:

• make memcpy copy downwards, which is faster
• implement upwards in memmove, and call memcpy's downward internals if necessary

Would you fancy a PR doing that?

[Bob Andrews]

Sounds like a totally valid optimization to me - IF that doesn't mean that the code will be larger :)

[Colin Leroy-Mira]

Ah, well, the total code is not larger, but memcpy itself gets 29 bytes larger this way...

[clbr]

Changing the memcpy internal direction would break user code that expects a certain direction.

[clbr]

(yes, the direction is not guaranteed by the API etc, but it's still unadvisable to do changes like this for minor speedup)

[Bob Andrews]

Changing the memcpy internal direction would break user code that expects a certain direction.

Code doing that is simply broken

[Stefan]

(yes, the direction is not guaranteed by the API etc, but it's still unadvisable to do changes like this for minor speedup)

Remember, undefined behavior is a feature of C.

[Colin Leroy-Mira]

I tend to hope that cc65 users copying data over overlapping buffers are used enough to C to know they should use memmove.
the real question is, do you folks want +29 bytes for 5% speedup.

[Brad Smith]

I much more often find space a problem than speed on 6502, so that trade seems kind of a wash to me.

[Bob Andrews]

Sorry for no earlier feedback ...

anyhow, after thinking it over again, i agree that shorter code beats the slightly faster execution

[Colin Leroy-Mira]

Yep, everyone seemed to agree :)