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: Boyapati, Anitha
Subject: Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3
Date: Thu, 13 Oct 2011 15:55:18 +0800

Oops! I forgot to add the link to the original conversation on avr-gcc
ml dated 2006.

http://lists.gnu.org/archive/html/avr-gcc-list/2006-08/msg00043.html

>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden On
>Behalf Of Boyapati, Anitha
>Sent: Thursday, October 13, 2011 1:18 PM
>To: address@hidden
>Subject: Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3
>
>
>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.
>
>
>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.
>
>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?
>
>
>Anitha
>
>
>
>
>
>
>
>
>
>=======================================================================
>
>From:  Anatoly Sokolov
>Subject:       Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3
>Date:  Sun, 20 Aug 2006 14:29:46 +0400
>
>
>Hello.
>
> Attached is modifed Andy Hutchinson patch that changes AVR GCC to use
>RTL
>prologue/epilogue generation.
> Original patch: http://gcc.gnu.org/ml/gcc/2005-03/msg00923.html
>
> This pach is for GCC 4.2.
>
>Main difference:
>The order of instructions in a prologue (and epilogue) of interrupt
>handler
>functions is changed from:
>   push __tmp_reg__
>   in __tmp_reg__,__SREG__
>   push __tmp_reg__
>   push __zero_reg__
>   clr __zero_reg__
>....
>to old order:
>   push    __zero_reg__
>   push    __tmp_reg__
>   in      __tmp_reg__, __SREG__
>   push    __tmp_reg__
>   clr     __zero_reg__
>....
>
>The GDB uses the second variant as a pattern, for a finding of body of
>function.
>
> Anatoly.
>
>
>_______________________________________________
>AVR-GCC-list mailing list
>address@hidden
>https://lists.nongnu.org/mailman/listinfo/avr-gcc-list



reply via email to

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