[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:


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.


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 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/

reply via email to

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