I would dearly love to replace some of the Keil library functions that are used by intrinsics, such as ?C?COPY, which is called by memcpy (and by other things). My current goal is to generate runtime errors on certain types of copies, but replacement would be useful for other purposes. I've actually written my own implementation of ?C?COPY, which works fine. The inline instructions are still emitted by the compiler and my version is linked. However, I'm concerned about compatibility with future compiler releases. I'm supposing that the interface can't change, because this would break older libraries, which could be third party. But other library functionality may depend on something internal to the Keil ?C?COPY implementation, or may do so in future. For my current purposes, I'm thinking of patching the entry to the Keil ?C?COPY after the code is built, to call my checking routine. This only requires that the interface doesn't change. Has anyone else tried anything like this? Any comments on my assumption that the interface can't change? PS - I know I can acheive my ends by writing my own memcpy and redefining memcpy() with a macro, but then heaps more code will be generated, because the calls will be far less efficient, without the special parameter passing.
Wow! I replaced ?C?COPY, ?C?MOVE and ?C?MEMSET, implementing only the cases I need and saved approx 256 bytes. I could actually get quite a bit more back, but I kept the code fairly similar to the Keil versions in case I need to reimplement some of it. I completely disassembled the library code and the only worrying things I found were - There seems to be a redundant instruction in ?C?COPY, which hints at a separate entry point. I kept the replacement code logically consistent with this possibility. The PDATA<->XDATA memmove cases do not cater for overlap, though this is possible, at least in hardware terms. Maybe the compiler prevents this? The CODE->XDATA case caters for overlap. This must be possible on some architectures, though certainly not in our case.
saved approx 256 bytes. great, now for the full story: what happened to execution time? Erik
Identical - I just removed the cases that I don't use - like PDATA<->XDATA copies etc. And looking at the code, I could slightly increase the execution speed using less space if I wanted to.