Can functions modify register 'r0' or not?

[Lin Nan]

Hi all,

In my code, I found that the global interrupts is disabled after one
function is called. By reading the assembly code I found that this
function uses register 'r0' to save the global interrupts in the
prologue and restore it in the end.  One of the functions been called
in this function modified the register 'r0' and caused this problem.

I wonder whether or 'r0' can be clobbered in functions. If so, why
register 'r0' is used to save the global interrupts in that function.

THX


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Stu Bell]

AVR-LibC FAQ #13:
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage

R0 is a temp register, available for use in any function.  The compiler
gurus will know if it needs to be pushed at the beginning of the
function and restored at the end.

My guess is that you are doing something funky with an Interrupt Service
Routine, but that's just a guess.  Perhaps you can post the code you
think is bad.

Best regards,

Stu Bell
DataPlay (DPHI, Inc.)

 

> -----Original Message-----
> On Behalf Of xiaonanln@...
>
> Hi all,
>
> In my code, I found that the global interrupts is disabled
> after one function is called. By reading the assembly code I
> found that this function uses register 'r0' to save the
> global interrupts in the prologue and restore it in the end.  
> One of the functions been called in this function modified
> the register 'r0' and caused this problem.
>
> I wonder whether or 'r0' can be clobbered in functions. If
> so, why register 'r0' is used to save the global interrupts
> in that function.
>
> THX

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Andy H-2]

r0 is scratch register. Only ISR have to save it - since it may interrupt usage as scratch.
Normal functions or inline assembler do not r0 contents. The contents of r0 are not assumed to remain outside a single RTL statement (-which ultimately translates to 1 or more assembly instructions). So the lifetime of r0 is quite limited.

If r0 is used in assembler, the code must be in one block. Otherwise intervening C RTL may well overwrite it.

Interrupts are pushed on stack by prolog and restored afterwards. r0 is used as temporary for this process. That is to avoid using some other register that would then need to be saved prior to use.

Andy

----------------------------------------------
Sent from my Dingleberry wired device.

-----Original Message-----
From: Stu Bell <sbell@...>
To: xiaonanln@...; avr-gcc-list <avr-gcc-list@...>
Sent: Tue, Aug 18, 2009 10:09 am
Subject: RE: [avr-gcc-list] Can functions modify register 'r0' or not?

AVR-LibC FAQ #13:

http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage



R0 is a temp register, available for use in any function.  The compiler

gurus will know if it needs to be pushed at the beginning of the

function and restored at the end.



My guess is that you are doing something funky with an Interrupt Service

Routine, but that's just a guess.  Perhaps you can post the code you

think is bad.



Best regards, 



Stu Bell 

DataPlay (DPHI, Inc.) 



 



> -----Original Message-----

> On Behalf Of xiaonanln@...

> 

> Hi all,

> 

> In my code, I found that the global interrupts is disabled 

> after one function is called. By reading the assembly code I 

> found that this function uses register 'r0' to save the 

> global interrupts in the prologue and restore it in the end.  

> One of the functions been called in this function modified 

> the register 'r0' and caused this problem.

> 

> I wonder whether or 'r0' can be clobbered in functions. If 

> so, why register 'r0' is used to save the global interrupts 

> in that function.

> 

> THX





_______________________________________________

AVR-GCC-list mailing list

AVR-GCC-list@...

http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Parthasaradhi Nayani]

Hello all,
I have just started testing an XMEGA64 chip and I find a peculiar problem when I use sprintf. Following are the environment/specs:

XMEGA64 running at 32MHz (using the internal freq generator)
USART on PC0, operating at 115K BAUD.
One timer in port D being used in compare capture mode.

The program is a very simple one. At start, 8000H, (let me call this CCAVAL) is written into the compare register and this generates a frequency on pin OC0A. Usart receive is interrupt driven. When a new value for CCAVAL is sent through the serial port, main loop converts the value and writes to the compare register. This should change the frequency of the square wave on OC0A. To test the vaule being written to ccaval is being sent back to PC and this is where the peculiar problem is noticed. We are using sprintf function to conver the binary value of ccaval and then sending it PC through another function. When
we use a global buffer in sprintf, the program behaves erratically. The timer stops for some time and then starts with the new value. However if use a local buffer in sprintf then everything works fine. Example code given below

char globalbuf[20];

sprintf (globalbuf,"%05u\r\n",ccaval);  // problem. globalbuf defined outside main.

sprintf (localbuf,"%05u\r\n", ccaval); // no problem. everything works fine.

Can some one point me to the mistake we are making? or is this a problem with GCC? Thank you.

Regards
Nayani P

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Steven Michalske]

This message got buried in a thread, because you used a reply to a previous message from the list.

It's poor manners to hijack threads, and can cause some users not to reply.

not much in terms of help though,   writing up a quick, complete test case may help us help you.

is globalbuf accessed anywhere in the ISR functions??

Steve

On Aug 19, 2009, at 4:02 AM, Parthasaradhi Nayani wrote:

Hello all,
I have just started testing an XMEGA64 chip and I find a peculiar problem when I use sprintf. Following are the environment/specs:

XMEGA64 running at 32MHz (using the internal freq generator)
USART on PC0, operating at 115K BAUD.
One timer in port D being used in compare capture mode.

The program is a very simple one. At start, 8000H, (let me call this CCAVAL) is written into the compare register and this generates a frequency on pin OC0A. Usart receive is interrupt driven. When a new value for CCAVAL is sent through the serial port, main loop converts the value and writes to the compare register. This should change the frequency of the square wave on OC0A. To test the vaule being written to ccaval is being sent back to PC and this is where the peculiar problem is noticed. We are using sprintf function to conver the binary value of ccaval and then sending it PC through another function. When
we use a global buffer in sprintf, the program behaves erratically. The timer stops for some time and then starts with the new value. However if use a local buffer in sprintf then everything works fine. Example code given below

char globalbuf[20];

sprintf (globalbuf,"%05u\r\n",ccaval);  // problem. globalbuf defined outside main.

sprintf (localbuf,"%05u\r\n", ccaval); // no problem. everything works fine.

Can some one point me to the mistake we are making? or is this a problem with GCC? Thank you.

Regards
Nayani P

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[David Kelly]

On Wed, Aug 19, 2009 at 02:23:10PM -0700, Steven Michalske wrote:
> This message got buried in a thread, because you used a reply to a  
> previous message from the list.
>
> It's poor manners to hijack threads, and can cause some users not to  
> reply.

Same applies to top-post without trim.

--
David Kelly N4HHE, dkelly@...
========================================================================
Whom computers would destroy, they must first drive mad.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Parthasaradhi Nayani]

Hello All,
Just not to enter a wrong address, I copy the address or clear the message and write new one. My apologies for inadvertently doing so. I am creating a new thread with a different heading. Thanks.

Nayani




--- On Thu, 8/20/09, David Kelly <dkelly@...> wrote:

From: David Kelly <dkelly@...>
Subject: Re: [avr-gcc-list] Xmega support
To: "Steven Michalske" <smichalske@...>
Cc: "avr-gcc-list" <avr-gcc-list@...>
Date: Thursday, August 20, 2009, 3:11 AM

On Wed, Aug 19, 2009 at 02:23:10PM -0700, Steven Michalske wrote:
> This message got buried in a thread, because you used a reply to a 
> previous message from the list.
>
> It's poor manners to hijack threads, and can cause some users not to 
> reply.

Same applies to top-post without trim.

--
David Kelly N4HHE, dkelly@...
========================================================================
Whom computers would destroy, they must first drive mad.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list