search

Memotech-Bill / PicoBB

BBC BASIC for Raspberry Pi Pico
zlib License
32 stars 4 forks source link

SYS "memcpy" no longer working #14

Closed rtrussell closed 1 year ago

rtrussell commented 1 year ago

SYS "memcpy"... is now reporting "No such system call". It used to work - it's needed by the picowav.bbc example program - but seems to have gone AWOL.

I've updated all the other Console Mode editions to v0.42, but this issue is preventing me from updating the Pico build.

Memotech-Bill commented 1 year ago

Functions in the Pico SDK are explicitly included in the list available via SYS by scanning the header files from the SDK.

However functions from the C library are only included in the SYS list if they are used in the compilation of Pico itself. The included function names are generated by scanning the build map. It appears that the compiler has optimised out all calls to memcpy, so it no longer appears in the map and is not available to SYS.

However memmove is included and therefore available. memmove has exactly the same signature as memcpy and also has the advantage that it supports copying overlapping memory regions. I suggest that you change memcpy to memmove.

rtrussell commented 1 year ago

I suggest that you change memcpy to memmove.

OK, I'll do that (reluctantly) but there's no way of knowing who else might have used memcpy in their programs. It's a very unfortunate regression.

Memotech-Bill commented 1 year ago

It is not practical to include the entire C library in SYS. Therefore the question is how to decide which functions to include. The decision was made to just include references to those functions which are in the code anyway. This can result in inconsistencies, with one function (such as memmove) being included while another related one (such as memcpy) is not. The included functions can also vary across different builds (console or GUI) and across different versions (in time).

The other option would be to have a frozen list of which C library routines are included. That still leaves the problem of how to generate this list. If it was just generated from one particular build and then preserved for all time it would still leave the issue of being potentially inconsistent as to which routines are included or excluded.