This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Large memcpy

We are using Keil C-51 V7.06.

There is a structure defined:

typedef struct
{
  unsigned char address_bus_h;
  unsigned char address_bus_l;
  unsigned char data_bus;
}instbus_raw_t;

Using three simple lines to copy the structure to another it enlarges code by 9 bytes, but this is not an elegant solution:

instbus_raw.address_bus_h = instbus_raw_local.address_bus_h;
instbus_raw.address_bus_l = instbus_raw_local.address_bus_l;
instbus_raw.data_bus = instbus_raw_local.data_bus;

Using the normal library function memcpy
blows up the code by 300 bytes!

memcpy(&instbus_raw,&instbus_raw_local,sizeof(instbus_raw_t));

Using an own function my_memcpy the code increases by 167 bytes:

void *(my_memcpy)(void *s1, const void *s2, size_t n)
{
  char *su1 = (char *)s1;
  const char *su2 = (const char *)s2;

  for (; 0 < n; --n)
    *su1++ = *su2++;
  return (s1);
}

my_memcpy(&instbus_raw,&instbus_raw_local,sizeof(struct instbus_raw_t));

In a project with a little chip of 2k Flash, 300 bytes for copying few bytes are considerable!

Does anyone remarking same effects with library functions wasting resources?

Regards Peter

Parents
  • Ah, yes, sometime I just cannot helpmyself from getting into assembler... In fact, the C version could probably be slightly improved by using

        do
        {
        ...
        }while(--n != 0);
    
    In which case, I dare say the compiler code would be identical to my assembler.

    It is a pity that the compiler rules for passing parameters do not allow for two generic pointers and a count entirely in registers. This is quite a common requirement and the C51 compiler itself seems to be able to override these rules.

    Given that there are miriad ways of implementing memcpy() and other string.h functions, it would be very helpful for implementors to be able to write their own string.h libraries by having access to C51's special parameter passing rules. My guess is that this would not be too dificult to do, though it may require the addition of a new keyword to indicate use of the special parameter passing rules to the compiler. Such a facility could make a substantial difference to code size (as well as speed) and this could be very significant in the case of small applications.

    Implementors could choose between large and fast functions or slow but compact. Also, such functions could then easily be made reenterant.

    I have started a new thread on the subject of copying structures(): http://www.keil.com/forum/docs/thread4380.asp#msg18741

Reply
  • Ah, yes, sometime I just cannot helpmyself from getting into assembler... In fact, the C version could probably be slightly improved by using

        do
        {
        ...
        }while(--n != 0);
    
    In which case, I dare say the compiler code would be identical to my assembler.

    It is a pity that the compiler rules for passing parameters do not allow for two generic pointers and a count entirely in registers. This is quite a common requirement and the C51 compiler itself seems to be able to override these rules.

    Given that there are miriad ways of implementing memcpy() and other string.h functions, it would be very helpful for implementors to be able to write their own string.h libraries by having access to C51's special parameter passing rules. My guess is that this would not be too dificult to do, though it may require the addition of a new keyword to indicate use of the special parameter passing rules to the compiler. Such a facility could make a substantial difference to code size (as well as speed) and this could be very significant in the case of small applications.

    Implementors could choose between large and fast functions or slow but compact. Also, such functions could then easily be made reenterant.

    I have started a new thread on the subject of copying structures(): http://www.keil.com/forum/docs/thread4380.asp#msg18741

Children
No data