[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] __udivmodsi4 uses r1
From: |
Bruce D. Lightner |
Subject: |
Re: [avr-gcc-list] __udivmodsi4 uses r1 |
Date: |
Tue, 08 Mar 2005 11:40:02 -0800 |
User-agent: |
Mozilla Thunderbird 0.5 (Windows/20040207) |
Lin Gu wrote:
Hi,
I find that __udivmodsi4 (implemented in libgcc.S) uses r1
to store a non-zero value. Is there a specific reason for this?
This usage somehow breaks one of my programs which assume
r1 is always zero. Though it's easy to fix my program, I am wondering
why here r1 is used this way.
Cheers,
lin
--
Lin Gu
University of Virginia
This is *not* a problem providing "r1" is reloaded with zero after the
routine exits...and as part of any interrupt handlers.
Zapping "r1" is unavoidable if one wants to use something like the AVR
"mul" instruction, which unconditionally puts the results into "r0:r1".
Anyway, that is why C-based AVR interrupt handlers need to clear "r1"
*after* saving "r1" on the stack.
For example, here a sample "avr-gcc" interrupt handler prologue/epilogue...
282:mp3.c ****
283:mp3.c **** SIGNAL(mp3_interrupt_service)
284:mp3.c **** {
223 .LM6:
224 /* prologue: frame size=0 */
225 0008 1F92 push __zero_reg__
226 000a 0F92 push __tmp_reg__
227 000c 0FB6 in __tmp_reg__,__SREG__
228 000e 0F92 push __tmp_reg__
229 0010 1124 clr __zero_reg__
230 0012 2F93 push r18
231 0014 3F93 push r19
.
.
.
694 0222 3F91 pop r19
695 0224 2F91 pop r18
696 0226 0F90 pop __tmp_reg__
697 0228 0FBE out __SREG__,__tmp_reg__
698 022a 0F90 pop __tmp_reg__
699 022c 1F90 pop __zero_reg__
700 022e 1895 reti
Hopefully, this makes sense to you.
However, this does not explain why *you* are having problems, unless of
course you have an interrupt handler (written in assembly?) which does not
follow the "avr-gcc" rules!
Best regards,
Bruce
--
Bruce D. Lightner
Lightner Engineering
La Jolla, California
Voice: +1-858-551-4011
FAX: +1-858-551-0777
Email: address@hidden
URL: http://www.lightner.net/lightner/bruce/