Why going to all that trouble? Just initialize explicitly all the static
variables in your code, even the ones that will be zero. It's the clean way
to code anyhow, even though most of the C compilers will do it for you
during the startup routine.

Just my opinion on the subject,
Roland
-----Original Message-----
From: sks_dsp [mailto:s...@yahoo.com]
Sent: Montag, 23. Februar 2004 22:25
To: c...@yahoogroups.com
Subject: [code-comp] Re: Uninitialized gloabal variables.Hello,

I think, but am not sure, that telling the linker command file to
fill the .bss with zeros will result in a large .cinit section and
perhaps a large .hex file.

I am not extremely familiar with 67xx, however, assuming it is
similar to the 55x, and 54x families I can tell you a method which
may work (it is a bit of work and gets to down to the nitty gritty).

The C generated code creates initialization tables that are part of
the .cinit section only for those variables that are explicity auto-
initialized (as pointed out in the posting below). The C-init
section is typically read by a part of boot.asm. You need to modify
boot.asm (or whatever file is doing the cinit stuff on the 67) and
include a code fragment just before the c-init stuff that will fill
the entire .bss section with 0. The start and end address of
the .bss section will need to be known (I think these are standard
symbols or you can create them using the linker command file so they
appear in global variable space). Again, I know I've done something
like this once before, but can't find the exact example.

Now, however, as I write this, I realize that the 67xx is a floating
point device, so we don't know if a variable should be initialized to
floating point 0.0 or integer 0. So it is a bit more complicated.

Hmmm, sorry I wasn't more help. Over the years I've grown accustomed
to automatically initializing "read first" variables within the
variable declaration OR initializing large data blocks dynamically
and initializing them to zero within the memALLOC function.

Another programming style that I've grown to use is to have
an "Initialization" function associated with any module or "object
constructor" that uses for loops to initialize any large buffer space
to zeros (again to avoid large .cinit sections)

Hope this helps somehow.

-Shawn--- In c...@yahoogroups.com, Andrew Nesterov
wrote:
>
> Damien,
>
> A short excerpt from
> CCS->Help->Code Genration Tools Online Documentation->
> Optimizing C/C++ Compiler Tools->Run-TimeEnvironment->
> Initialization->Automatic Initialization of Variables
> says
>
> "Note: In ISO C, global and static variables that are not explicitly
> initialized are set to 0 before program execution. The C6000 C/C++
> compiler does not perform any preinitialization of uninitialized
> variables. Explicitly initialize any variable that must have an
> initial value of 0."
>
> and
>
> "Another method is to set a fill value of 0 in the linker control map
> for the .bss section."
>
> This might be considered as a bug or as a feature, similar to C6000
> calling conventions that differ from the standard, but I agree that
> otherwise portable code is not in fact portable in this case.
>
> --
> Andrew
>
> > Date: Tue, 10 Feb 2004 15:58:36 +0100
> > From: Damien Piguet
> > Subject: Uninitialized gloabal variables.
> >
> > Hello all CCS gurus!
> >
> > When, using CCS, we upload a program that contains initialized and
> > uninitialized global variables to the DSP and start it, the
> > initialized variables contain the expected values but the
> > uninitialized variables contain random values instead of zero.
> >
> > Is it possibles to have these uninitialized global variables set to
> > zero by the startup code or is there an issue with this?
> >
> > We noticed that in example code such as
> > "examples\dsk6711\bios\audio", global variables are explicitly
> > initialized to 0. Is it a bug workaround?
> >
> > Our target is C6711 and we are using Code Composer Studio version
> > 2.20.
>

_____________________________________

I agree, that is the most straightforward way for variables of small dimension. 

 

I was trying to cover the issues that may arise for larger variables.

 

For variables of larger dimension, initializing when the variable is declared has some drawbacks.

 

Consider an input buffer to an FIR filter:

 

#define N_ORD (256)

int myInputBuffer[N_ORD];

 

In this case, it would be tedious to enter myInputBuffer[N_ORD]={0,0,0,0, etc}.

Also in doing this, the size of the .cinit section will increase by 256 words.  Increasing the .cinit section causes the overall size of the program to go up.

Also, if using the auto-init, when changing the filter order with the #define, you'll have to go back an manually change the number of entries in the {0,0,0 etc} part.

 

So those are the points to consider.  I totally agree that the method outlined in which boot.asm is modified is extremely complicated.

 

As I indicated, my prefered method is to use an "initialization" routine associated with a module (or object) which can use for loops (or memset( ) calls) to clear out large buffers and the like:

 

void FiltInit(void)

{

   for (k=0;k<N_ORD;k++)

   {

       myInputBuffer[k]=0;

   }   

}

 

Best Regards,

 

-Shawn

r...@crypto.ch wrote:

Why going to all that trouble? Just initialize explicitly all the static
variables in your code, even the ones that will be zero. It's the clean way
to code anyhow, even though most of the C compilers will do it for you
during the startup routine.

Just my opinion on the subject,
Roland
-----Original Message-----
From: sks_dsp [mailto:s...@yahoo.com]
Sent: Montag, 23. Februar 2004 22:25
To: c...@yahoogroups.com
Subject: [code-comp] Re: Uninitialized gloabal variables.Hello,

I think, but am not sure, that telling the linker command file to
fill the .bss with zeros will result in a large .cinit section and
perhaps a large .hex file.

I am not extremely familiar with 67xx, however, assuming it is
similar to the 55x, and 54x families I can tell you a method which
may work (it is a bit of work and gets to down to the nitty gritty).

The C generated code creates initialization tables that are part of
the .cinit section only for those variables that are explicity auto-
initialized (as pointed out in the posting below). The C-init
section is typically read by a part of boot.asm. You need to modify
boot.asm (or whatever file is doing the cinit stuff on the 67) and
include a code fragment just before the c-init stuff that will fill
the entire .bss section with 0. The start and end address of
the .bss section will need to be known (I think these are standard
symbols or you can create them using the linker command file so they
appear in global variable space). Again, I know I've done something
like this once before, but can't find the exact example.

Now, however, as I write this, I realize that the 67xx is a floating
point device, so we don't know if a variable should be initialized to
floating point 0.0 or integer 0. So it is a bit more complicated.

Hmmm, sorry I wasn't more help. Over the years I've grown accustomed
to automatically initializing "read first" variables within the
variable declaration OR initializing large data blocks dynamically
and initializing them to zero within the memALLOC function.

Another programming style that I've grown to use is to have
an "Initialization" function associated with any module or "object
constructor" that uses for loops to initialize any large buffer space
to zeros (again to avoid large .cinit sections)

Hope this helps somehow.

-Shawn--- In c...@yahoogroups.com, Andrew Nesterov
wrote:
>
> Damien,
>
> A short excerpt from
> CCS->Help->Code Genration Tools Online Documentation->
> Optimizing C/C++ Compiler Tools->Run-TimeEnvironment->
> Initialization->Automatic Initialization of Variables
> says
>
> "Note: In ISO C, global and static variables that are not explicitly
> initialized are set to 0 before program execution. The C6000 C/C++
> compiler does not perform any preinitialization of uninitialized
> variables. Explicitly initialize any variable that must have an
> initial value of 0."
>
> and
>
> "Another method is to set a fill value of 0 in the linker control map
> for the .bss section."
>
> This might be considered as a bug or as a feature, similar to C6000
> calling conventions that differ from the standard, but I agree that
> otherwise portable code is not in fact portable in this case.
>
> --
> Andrew
>
> > Date: Tue, 10 Feb 2004 15:58:36 +0100
> > From: Damien Piguet
> > Subject: Uninitialized gloabal variables.
> >
> > Hello all CCS gurus!
> >
> > When, using CCS, we upload a program that contains initialized and
> > uninitialized global variables to the DSP and start it, the
> > initialized variables contain the expected values but the
> > uninitialized variables contain random values instead of zero.
> >
> > Is it possibles to have these uninitialized global variables set to
> > zero by the startup code or is there an issue with this?
> >
> > We noticed that in example code such as
> > "examples\dsk6711\bios\audio", global variables are explicitly
> > initialized to 0. Is it a bug workaround?
> >
> > Our target is C6711 and we are using Code Composer Studio version
> > 2.20.
>

_____________________________________

---