On Thursday 23 October 2008 07:25, Joerg Wunsch wrote:
> > On gcc 4.2.3 it was possible to use something like
> >
> > -minit-stack="xOS+xOSstackShift"
>
> While -minit-stack used to be documented (but deprecated, as you
> already noticed), the option to perform calculations in its value was
> never documented at all.
I think i have to disagree here. Indeed, it was never stated that you
could perform calculations as such, but it is a "natural" consequence
of the fact that symbols (xOS) are allowed. The only thing i do by setting
.set xOSstackShift, 10
inside the code is adding a constant to an address (indeed, anything
more compilcated is bound to fail).
Now, what i don't understand (gcc4.3.2) is the following. If i set
-Wl,--defsym=__stack=xOS
on the command line this works well and the address of xOS is
used to initialize the stack. So symbols are allowed there.
If i place (somewhere, for example in main) inside the code the instructions
asm(".global __stack \n\t ");
asm(".set __stack, 0xF4 \n\t ");
also this functions as expected. The stack gets initalized with 0xF4.
If I however put a symbol there, like
asm(".global __stack \n\t ");
asm(".set __stack, xOS \n\t ");
it does not work (the stack gets initialized to its default value),
although i am certain the symbol xOS was defined on that spot. Why?
> Historically, the stack has been initialized twice, once in the
> startup code of the library, and another one at the entry of main().
> -minit-stack only affected the latter, while the symbol __stack has
> always been used for both.
>
> On the course of making main() a normal function (according to the
> standard, it's OK to call main() recursively), one of the steps
> necessary was to remove the (pointless) stack initialization at the
> beginning of main().
Which is an improvement indeed.
My point is that, i used to be able to intialize the stack at the end
of some array (although an awkward trick was needed). With only
__stack (with the current characteristics) at my disposal, i don't
seem to have that possibility any more.
Or am i missing somthing very obvious?
Ruud
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
