Possible bug in memory initialization?

[eugenebrooks]

In ifi_startup.c, the routine _do_cinit() has some static variables defined with:
<<<<<<<<<<<<
_do_cinit (void)
{
/* we'll make the assumption in the following code that these statics
* will be allocated into the same bank.
*/
static short long prom;
static unsigned short curr_byte;
static unsigned short curr_entry;
static short long data_ptr;
>>>>>>>>>>>>

This is followed by a bunch of asm statements that are used to initialize static/extern memory locations. Since we have had lots of problems with static memory not behaving like it was initialized properly, I am wondering if the stated assumption in the comment, that the four static variables are allocated in the same bank, might not be valid, depending on just how much static memory is allocated in other files.

Can anyone shed some light on this issue?

[Mike Betts]

Doc,

Are you saying that explicit or implicit initializations are corrupted?

I have seen no issues with explicit initializations and have strongly advised everyone who cares to listen to avoid them.

JMHO.

Mike

[eugenebrooks]

Originally Posted by Mike Betts

Doc,

Are you saying that explicit or implicit initializations are corrupted?

I have seen no issues with explicit initializations and have strongly advised everyone who cares to listen to avoid them.

JMHO.

Mike

Mike, I don't think that there is any need to re-visit the thread you point to here, I don't disagree with the view you posted there. My question is whether or not the assumption that the variables in the routine in question are allocated in the same section can ever be violated...

[Mike Bortfeldt]

I have never seen a problem with variable initialization that wasn't my own fault (mainly not recognizing how the compiler will sometimes cast constants). But as for your question, I would say that the assumption is true. Since the compiler places all static uninitilized variables within a file in the same UDATA section (assuming you don't use a #pragma statement to change that) the compiler/linker would generate a section error if it overflows a single DATABANK since a single UDATA section must fit within a single DATABANK. That being said, if you've modified the linker file so that a single DATABANK spans multiple memory banks, then I suppose it would be possible for the same bank assumption to be false.

You should also be able to check the .map file to verify that all the variables have been placed in the same bank.

Mike