STARTUP.A51 & INIT.A51 FILE INFO

The C standard specifies that any global variable which does not have an initializer is initialized to zero. There are several loops, one for each memory space (idata, pdata, xdata, etc), in the STARTUP.A51 file that zero out all of the memory. This code implements the requirement of the C spec that uninitialized variables are zero.

The compiler takes all of the explicit static initializers and puts them into the code (ROM) area. INIT.A51 copies this region of initialized data to RAM. INIT.A51 implements the C standard feature for initializing global variables.

If you omit INIT.A51 from your build, then any program which relies on static initializers will not work correctly. You will have to write code that explicitly initiazes variables the way you want them.

For example, this code will fail miserably if you omit INIT.A51

U8 lookup[8] = { 7, 6, 5, 4, 3, 2, 1, 0 };

void main (void)
    {
    ...
    translated = lookup[input];
    ...
    }

You'll find in practice that lookup is all zeros (thanks to STARTUP.A51), and not the lookup values you expect. You can omit INIT.A51, but then you have to write code to make sure the variable gets initialized, like this:

U8 lookup[8];
...
void LookupInit (void)
    {
    U8 data i;

    for (i = 0; i < 8; ++i)
        {
        lookup[i] = 7 - i;
        }
    } // LookupInit

...
void main (void)
    {
    LookupInit();

    translated = lookup[input]; // works only after call to LookupInit();
    }

At some point it will take more code to initialize everything "manually" than it would have to let INIT.A51 copy it all in one block. On the other hand, you might need to be able to initialize a variable on demand, so that you have to write this code anyway. Also, using the initializer means you really have two copies of the value in your total address space (one in code memory for the source for INIT.A51, and one in data memory where the variable actually lives).

If you omit the initialization loops in STARTUP.A51, then any program which relies on a variable being initialized to zero will not work correctly. The memory will have whatever random values it powers up with.

If your program initializes all values before they are used by some other means, then you don't need either the code in INIT.A51 or the initialization loops in STARTUP.A51. You will risk bugs every time someone writes code expecting the system to conform to the full C specification and initialize their variables for them per spec. Programmers notoriously forget to initialize their variables. On the other hand, a default value of zero doesn't mean the program will work right anyway. The specification for all variables being initialized to zero is not a security measure, but just a convenience for the prorammer.

In my case, INIT.A51 didn't help me much because my system has to be able to re-initialize itself without rebooting. Constants I leave in code space. So there weren't any practical uses for initializers that weren't redundant with other parts of the code.

Initializing large chunks of RAM to zero, on the other hand, cost me many calls to memset, and so it was cheaper to keep STARTUP.A51's loops for that purpose. (Some variables still have to get reset to zero while operating, and so there are still some memset()s.) But the extra boot time isn't important in my case, and the net code size is smaller.

The C standard specifies that any global variable which does not have an initializer is initialized to zero. There are several loops, one for each memory space (idata, pdata, xdata, etc), in the STARTUP.A51 file that zero out all of the memory. This code implements the requirement of the C spec that uninitialized variables are zero.

The compiler takes all of the explicit static initializers and puts them into the code (ROM) area. INIT.A51 copies this region of initialized data to RAM. INIT.A51 implements the C standard feature for initializing global variables.

If you omit INIT.A51 from your build, then any program which relies on static initializers will not work correctly. You will have to write code that explicitly initiazes variables the way you want them.

For example, this code will fail miserably if you omit INIT.A51

U8 lookup[8] = { 7, 6, 5, 4, 3, 2, 1, 0 };

void main (void)
    {
    ...
    translated = lookup[input];
    ...
    }

You'll find in practice that lookup is all zeros (thanks to STARTUP.A51), and not the lookup values you expect. You can omit INIT.A51, but then you have to write code to make sure the variable gets initialized, like this:

U8 lookup[8];
...
void LookupInit (void)
    {
    U8 data i;

    for (i = 0; i < 8; ++i)
        {
        lookup[i] = 7 - i;
        }
    } // LookupInit

...
void main (void)
    {
    LookupInit();

    translated = lookup[input]; // works only after call to LookupInit();
    }

At some point it will take more code to initialize everything "manually" than it would have to let INIT.A51 copy it all in one block. On the other hand, you might need to be able to initialize a variable on demand, so that you have to write this code anyway. Also, using the initializer means you really have two copies of the value in your total address space (one in code memory for the source for INIT.A51, and one in data memory where the variable actually lives).

If you omit the initialization loops in STARTUP.A51, then any program which relies on a variable being initialized to zero will not work correctly. The memory will have whatever random values it powers up with.

If your program initializes all values before they are used by some other means, then you don't need either the code in INIT.A51 or the initialization loops in STARTUP.A51. You will risk bugs every time someone writes code expecting the system to conform to the full C specification and initialize their variables for them per spec. Programmers notoriously forget to initialize their variables. On the other hand, a default value of zero doesn't mean the program will work right anyway. The specification for all variables being initialized to zero is not a security measure, but just a convenience for the prorammer.

In my case, INIT.A51 didn't help me much because my system has to be able to re-initialize itself without rebooting. Constants I leave in code space. So there weren't any practical uses for initializers that weren't redundant with other parts of the code.

Initializing large chunks of RAM to zero, on the other hand, cost me many calls to memset, and so it was cheaper to keep STARTUP.A51's loops for that purpose. (Some variables still have to get reset to zero while operating, and so there are still some memset()s.) But the extra boot time isn't important in my case, and the net code size is smaller.