avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3


From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3
Date: Thu, 13 Oct 2011 18:44:15 +0200
User-agent: Thunderbird 2.0.0.24 (X11/20100302)

Boyapati, Anitha schrieb:
> Hi All,
> 
> I have couple of comments on this patch, which I think are important
> discussing with the avr-gcc community.
> 
> Comment - 1: 
> 
> Has any one verified prologue for functions using global variables? I
> think this patch generates incorrect prologue for such cases.
> 
> int global;
> void func(int p)
> {
>  p=global++;
> }
> 
> int main()
> {
>    int local=42;
>    func(local);
> }
> 
> 
> Code Generated for func() -
> 
> 00000228 <func>:
>  228:   cf 93           push    r28
>  22a:   df 93           push    r29
> 
>  22c:   00 d0           rcall   .+0             ; 0x22e <func+0x6>
>  22e:   0f 92           push    r0
> <<<<
> 
>  230:   cd b7           in      r28, 0x3d       ; FP = SP
>  232:   de b7           in      r29, 0x3e       
>  234:   8b 83           std     Y+3, r24        ; store 'local' to 'p'
>  236:   9c 83           std     Y+4, r25         
>  ...
> 
> Read the code between ">>>>  <<<<" and notice that 3/4 bytes (3 bytes
> for Megas, 4 for Xmegas) have been allocated on stack instead of 2.

I don't see that for trunk. The following test case

void func (int);

void bar (void)
{
    int volatile local = 42;
    func (local);
}

generates prologue with -Os -mmcu=avr6:

        push r28         ;  15  pushqi1/1       [length = 1]
        push r29         ;  16  pushqi1/1       [length = 1]
         ; SP -= 2       ;  20  *addhi3_sp_R    [length = 2]
        push __zero_reg__
        push __zero_reg__
        in r28,__SP_L__  ;  21  *movhi/8        [length = 2]
        in r29,__SP_H__
        /* prologue: function */
        /* frame size = 2 */
        /* stack size = 4 */

and with -Os -mmcu=avr4:

        push r28         ;  15  pushqi1/1       [length = 1]
        push r29         ;  16  pushqi1/1       [length = 1]
         ; SP -= 2       ;  20  *addhi3_sp_R    [length = 1]
        rcall .
        in r28,__SP_L__  ;  21  *movhi/8        [length = 2]
        in r29,__SP_H__
        /* prologue: function */
        /* frame size = 2 */
        /* stack size = 4 */

So it's as expected. Likewise without volatile + -O0.

> Comment -2:
> 
> I think this patch severely affects the step in/step out feature of
> debugger like AVR Studio (here after referred to as AS). AS depends on
> 'rcall'/'ret' instruction sequences to recognize a function call and
> step into. If a matching 'ret' is not found, the debugger gets confused.
> Currently, the problem is worked around but has much lower performance.

The debugger has to cope with that. There are two ways of doing that:

1) Analysing the prologue and knowing what sequences the compiler might
   generate.

2) Using debug information. avr-gcc attaches respective FRAME_RELATED
   debug information (don't know what the dwarf equivalent is) to
   respective prologue instructions.

> Also it is misleading to use 'rcall' for purposes it is not meant for
> (like stack allocation). In my opinion, the hack is not desirable by
> default. I would therefore recommend making it optional using a switch
> like 'mrcall'.
> 
> Thoughts?

You will still run into trouble because there may be function without return
(no-return functions or tail-calls) or functions with multiple RETs.

And I don't see a point in making prologue generation even more complex to
support non-smartness of some tool.

> 
> Anitha
> 

I am completely in line with Eric: Your debugger will have to get smarter and
not the compiler get dumb again.

Johann




reply via email to

[Prev in Thread] Current Thread [Next in Thread]