Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
initializing memory before/after main()
11 views
Skip to first unread message
alb
Feb 6, 2012, 4:42:53 AM2/6/12
to
Dear all,
I am using an Analog Devices DSP from the old days (ADSP21020) and the g21k
toolset (even though the VisualDSP would do exactly the same in this
respect).
When using the runtime header, the vendor provides three calls to setup the
hardware, the environment and the processor prior to the execution of the
main() program. The mechanism is very simple: the reset vector table looks
like this:
CALL ___lib_setup_hardware;
CALL ___lib_setup_processor;
CALL ___lib_setup_environment;
JUMP _main (DB);
When using the mem21k utility after linking (you can opt out in case you
need to use the loader utility ldr21k which produces a bootloader and takes
care of memory initialization), the segment seg_init will contain the
necessary information that is needed to configure the memory during the
___lib_setup_processor call.
Since my system has already a boot loader and the way is done is such that
to run my main() application it would copy it from flash and then jump to a
specific location, I have no way to perform the memory initialization before
my main() is called. What I still can do is to call ___lib_setup_processor
(and maybe the others as well) as first instruction(s) in my program. This
will lead to initializing the memory after the main() is called but before
any memory is used. I would like to know if there is any caveat with this
approach and if there's something I need to take care about that goes beyond
these library calls.
Certainly I may as well take care about memory initialization explicetely,
in my program, without any need to care about seg_init.
Any suggestions/ideas are appreciated.
Al
I am using an Analog Devices DSP from the old days (ADSP21020) and the g21k
toolset (even though the VisualDSP would do exactly the same in this
respect).
When using the runtime header, the vendor provides three calls to setup the
hardware, the environment and the processor prior to the execution of the
main() program. The mechanism is very simple: the reset vector table looks
like this:
CALL ___lib_setup_hardware;
CALL ___lib_setup_processor;
CALL ___lib_setup_environment;
JUMP _main (DB);
When using the mem21k utility after linking (you can opt out in case you
need to use the loader utility ldr21k which produces a bootloader and takes
care of memory initialization), the segment seg_init will contain the
necessary information that is needed to configure the memory during the
___lib_setup_processor call.
Since my system has already a boot loader and the way is done is such that
to run my main() application it would copy it from flash and then jump to a
specific location, I have no way to perform the memory initialization before
my main() is called. What I still can do is to call ___lib_setup_processor
(and maybe the others as well) as first instruction(s) in my program. This
will lead to initializing the memory after the main() is called but before
any memory is used. I would like to know if there is any caveat with this
approach and if there's something I need to take care about that goes beyond
these library calls.
Certainly I may as well take care about memory initialization explicetely,
in my program, without any need to care about seg_init.
Any suggestions/ideas are appreciated.
Al
FreeRTOS info
Feb 6, 2012, 9:34:35 AM2/6/12
to
setup and configured before main() is called - and then that none of the
initialisation functions you explicitly call from main() change the
stack configuration - or write over the stack frame that, by that point,
will already be in use by main().
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.
alb
Feb 6, 2012, 10:43:23 AM2/6/12
to
Dear Richard,
FreeRTOS info writes:
> On 06/02/2012 09:42, alb wrote:
[...]
loader which was running before the 'jump to main'. At this point, since
there's no need to go back to the loader I believe I can re-initialize the
stack from scratch with the lib_setup_environment call which should do the
job.
The beginning of my main will look like this then:
void main (void) {
SETUP_HWR(); // setup hardware (cache, irptl and memory banks)
SETUP_PRO(); // setup processor (registers, modes and memory)
SETUP_ENV(); // setup environment (stacks, errno, heaps, rand, interrupts
// exit and arguments)
...
}
Where SETUP_HWR/PRO/ENV are defines like:
#define SETUP_HWR() asm("CALL ___lib_setup_hardware;")
#define SETUP_PRO() asm("CALL ___lib_setup_processor;")
#define SETUP_ENV() asm("CALL ___lib_setup_environment;")
Even though the main is running, the stack should be empty, as well as the
heap, the registers and all the rest. Have I understood your concerns
correctly?
FreeRTOS info writes:
> On 06/02/2012 09:42, alb wrote:
>> Certainly I may as well take care about memory initialization
>> explicetely, in my program, without any need to care about seg_init.
>>
[...]
>> explicetely, in my program, without any need to care about seg_init.
>>
>
> As a minimum you must ensure the stack that main() is going to use is
> setup and configured before main() is called - and then that none of the
> initialisation functions you explicitly call from main() change the
> stack configuration - or write over the stack frame that, by that point,
> will already be in use by main().
At the moment the main is called I believe the stack is configured for the
> As a minimum you must ensure the stack that main() is going to use is
> setup and configured before main() is called - and then that none of the
> initialisation functions you explicitly call from main() change the
> stack configuration - or write over the stack frame that, by that point,
> will already be in use by main().
loader which was running before the 'jump to main'. At this point, since
there's no need to go back to the loader I believe I can re-initialize the
stack from scratch with the lib_setup_environment call which should do the
job.
The beginning of my main will look like this then:
void main (void) {
SETUP_HWR(); // setup hardware (cache, irptl and memory banks)
SETUP_PRO(); // setup processor (registers, modes and memory)
SETUP_ENV(); // setup environment (stacks, errno, heaps, rand, interrupts
// exit and arguments)
...
}
Where SETUP_HWR/PRO/ENV are defines like:
#define SETUP_HWR() asm("CALL ___lib_setup_hardware;")
#define SETUP_PRO() asm("CALL ___lib_setup_processor;")
#define SETUP_ENV() asm("CALL ___lib_setup_environment;")
Even though the main is running, the stack should be empty, as well as the
heap, the registers and all the rest. Have I understood your concerns
correctly?
Vladimir Vassilevsky
Feb 6, 2012, 11:22:57 AM2/6/12
to
alb wrote:
> Since my system has already a boot loader and the way is done is such
> that to run my main() application it would copy it from flash and then
> jump to a specific location, I have no way to perform the memory
> initialization before my main() is called. What I still can do is to
> call ___lib_setup_processor (and maybe the others as well) as first
> instruction(s) in my program. This will lead to initializing the memory
> after the main() is called but before any memory is used. I would like
> to know if there is any caveat with this approach and if there's
> something I need to take care about that goes beyond these library calls.
> Certainly I may as well take care about memory initialization
> explicetely, in my program, without any need to care about seg_init.
create unforeseen complications. The constructors of static objects must
be called before main(). The compiler optimizer might rearrange the
beginning of main() in unexpected way. The library initialization can
destroy the stack of main itself. The debugger might expect the
environment to be set up in a certain way before main(). A programmer
could edit out some cryptic calls.
> Any suggestions/ideas are appreciated.
Rewrite the startup code once forever so the initializations would be
called in prescribed manner.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
Tim Wescott
Feb 6, 2012, 11:38:57 AM2/6/12
to
does (even if occurs in the text after all the SETUP_xxx() functions)
then when you change the stack pointer those variable locations will be
toast. Depending on your optimizations, they may already have something
in them, too.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
alb
Feb 6, 2012, 11:40:08 AM2/6/12
to
Vladimir Vassilevsky writes:
[...]
and I wouldn't have done it if I had a choice. Unfortunately I don't have
any way to change the way the code jumps to the main. This part is written
in a protected area of the flash and cannot be changed.
I can say that from the assembly code produced by the compiler the first
three calls are as expected, no funny rearrengement and/or optimization.
If the static objects need to be constructed before the main is called then
I have no choice but avoiding the usage of static objects.
For what concerns the debugger the answer is easy, I don't use one (maybe
unwise, but not yet convinced).
Worries about a programmer editing out those details can be solved by
documentation and/or comments.
I don't want to defend the approach, my aim is to be aware of what are the
consequences and act accordingly.
>> Any suggestions/ideas are appreciated.
>
> Rewrite the startup code once forever so the initializations would be
> called in prescribed manner.
Well indeed I can think of an additional segment of code which can be
located in the place where the main was supposed to be and move the main
segment somewhere else. In this way I can call the initialization function
before the main is called (how about that).
[...]
>
> It is a bad idea to do initializations in non-standard way. It could
> create unforeseen complications. The constructors of static objects must
> be called before main(). The compiler optimizer might rearrange the
> beginning of main() in unexpected way. The library initialization can
> destroy the stack of main itself. The debugger might expect the
> environment to be set up in a certain way before main(). A programmer
> could edit out some cryptic calls.
>
I understand that doing initialization in non-standard way is very bad idea
> It is a bad idea to do initializations in non-standard way. It could
> create unforeseen complications. The constructors of static objects must
> be called before main(). The compiler optimizer might rearrange the
> beginning of main() in unexpected way. The library initialization can
> destroy the stack of main itself. The debugger might expect the
> environment to be set up in a certain way before main(). A programmer
> could edit out some cryptic calls.
>
and I wouldn't have done it if I had a choice. Unfortunately I don't have
any way to change the way the code jumps to the main. This part is written
in a protected area of the flash and cannot be changed.
I can say that from the assembly code produced by the compiler the first
three calls are as expected, no funny rearrengement and/or optimization.
If the static objects need to be constructed before the main is called then
I have no choice but avoiding the usage of static objects.
For what concerns the debugger the answer is easy, I don't use one (maybe
unwise, but not yet convinced).
Worries about a programmer editing out those details can be solved by
documentation and/or comments.
I don't want to defend the approach, my aim is to be aware of what are the
consequences and act accordingly.
>> Any suggestions/ideas are appreciated.
>
> Rewrite the startup code once forever so the initializations would be
> called in prescribed manner.
located in the place where the main was supposed to be and move the main
segment somewhere else. In this way I can call the initialization function
before the main is called (how about that).
Tim Wescott
Feb 6, 2012, 11:43:15 AM2/6/12
to
1: Fix your boot loader so that it either does the requisite setup, or so
that it calls a "pre_main" function that you write (in assembly) to do
the setup and call main.
2: Write main in assembly to do the "pre_main" function mentioned above.
3: Write main in C, but put _nothing_ into it except for those three
function calls you have mentioned.
1 is the right solution. 2 is a kludge. 3 is a really desperate kludge.
Tim Wescott
Feb 6, 2012, 3:15:25 PM2/6/12
to
startup code so that it's entry point is where the boot code jumps on
startup, and go from there.
--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?
Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
FreeRTOS info
Feb 7, 2012, 6:25:55 AM2/7/12
to
knowing what the environment expects. For example, ignoring the stack
pointer, where is the frame pointer pointing before main() calls another
function that is going to attempt to set up its own stack frame? What
happens when the compiler implementation changes? Etc.
Also take care about the implementation of your initialisation routines
- do they rely on anything? Some systems will set up a temporary
environment for the initialisation code, then scrub it before setting up
the environment for main().
All things considered, it might (probably will) work, but you would be
better off using functions as they are intended to be used, or writing
your own versions of them.
Tim Wescott
Feb 7, 2012, 11:52:04 AM2/7/12
to
0 new messages