[Top][All Lists]

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

[avr-gcc-list] Old bug - ordering of 16 bit assignments

From: Brian Dean
Subject: [avr-gcc-list] Old bug - ordering of 16 bit assignments
Date: Sat, 26 Feb 2005 17:57:40 -0500
User-agent: Mutt/


I'm not sure when this bug re-appeared, but when one makes an
assignment of a value through a 16 bit pointer, avr-gcc is assigning
the low byte, then high byte.  However, many uses of a pointer like
this are for situations such as pointing at 16-bit registers.  In such
cases, the assignment should be made high byte first, then low byte,
as per Atmel datasheets due to the sequence of the latching mechanism.
See the following example:

void set_motor_pwm(struct motor_t * m, uint16_t pwm)
  *m->pwmreg = pwm;

This generates incorrect code if the pointer points to 16-bit I/O
register mapped into SRAM:

        movw r30,r24
        ld __tmp_reg__,Z+
        ld r31,Z
        mov r30,__tmp_reg__
        st Z,r22                 <----- low byte assigned first [INCORRECT]
        std Z+1,r23

While the following assignment that uses the I/O space:

void test(void)
  OCR3A = 512;

This one generates correct code:

        ldi r24,lo8(512)
        ldi r25,hi8(512)
        sts (134)+1,r25         <----- high byte first [CORRECT]
        sts 134,r24

At one time, Joerg Wunsch fixed this bug and it was later integrated
into the gcc tree, but now that seems to have been lost.  I'm not sure
where else to report this - where do we report this to in order to
hopefully get the correct behaviour of having assignments be made high
byte first to be complicit with the Atmel datasheets?

Also, I've heard of someone working on a test suite - could a check
for proper ordering of 16-bit assignments be added to the tests so
that something like this doesn't get reverted again?

Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers

reply via email to

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