Re: [avr-gcc-list] possible compiler bug?

[Theodore A. Roth]

On Wed, 28 Aug 2002, Brian Dean wrote:

:)
:)On Wed, Aug 28, 2002 at 05:55:28PM -0700, Theodore A. Roth wrote:
:)> 
:)> I've yet to see a case where the compiler didn't do the high byte first
:)> for a 16bit register access. I could be wrong though.
:)
:)In the message you replied to, see the set_pwm() function:
:)
:)        void set_pwm(volatile uint16_t * pwmreg, uint16_t pwm)
:)        {
:)          *pwmreg = pwm;
:)        }
:)
:)Results in:
:)
:)      set_pwm:
:)              movw r30,r24
:)              st Z,r22
:)              std Z+1,r23
:)              ret
:)
:)Low byte first, followed by high byte.

That's totally correct. I didn't make it clear that I meant 16bit _io_ 
register. 

What I think you are seeing is an artifact the "little endian-ness" of the
avr. Also, given the above definition, the compiler has no way of knowing 
that pwmreg is an io register.

But seeing this result, your argument is starting to seem more valid. The 
desired result would be:

      set_pwm:
              movw r30,r24
              std Z+1,r23
              st Z,r22
              ret

Of course, this assumes that you can actually read/write i/o registers with 
ld(d)/st(d)... checking the data... Yup can be done. From the LD(LDD) page 
of the instruction set datasheet:

"Loads one byte indirect with or without displacement from the data space to 
a register. For parts with SRAM, the data space consists of the register 
file, I/O memory and internal SRAM (and external SRAM if applicable)...."

I have no idea how hard it would be to implement this change in gcc. Of 
course this doesn't obviate the need for the disabling of interrupts.

Ted Roth

avr-gcc-list at http://avr1.org