avr-libc-dev
[Top][All Lists]
Advanced

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

RE: [avr-libc-dev] XMEGA


From: Weddington, Eric
Subject: RE: [avr-libc-dev] XMEGA
Date: Mon, 7 Jun 2010 23:57:30 -0600

 

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Joerg Wunsch
> Sent: Monday, June 07, 2010 11:47 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] XMEGA
> 
> As Weddington, Eric wrote:
> 
> > int main () {
> >    while (1) {
> >      PORTC.OUT = 0x00;
> >      PORTD.OUT = 0xff;
> >    }
> > }
> 
> main:
> /* prologue: function */
> /* frame size = 0 */
>         ldi r26,lo8(1600)
>         ldi r27,hi8(1600)
>         ldi r30,lo8(1632)
>         ldi r31,hi8(1632)
>         ldi r24,lo8(-1)
> .L2:
>         adiw r26,4
>         st X,__zero_reg__
>         sbiw r26,4
>         std Z+4,r24
>         rjmp .L2
> 
> > And the corresponding flat register access:
> >  
> > int main () {
> >    while (1) {
> >      PORTC_OUT = 0x00;
> >      PORTD_OUT = 0xff;
> >    }
> > }
> 
> main:
> /* prologue: function */
> /* frame size = 0 */
>         ldi r24,lo8(-1)
> .L2:
>         sts 1604,__zero_reg__
>         sts 1636,r24
>         rjmp .L2
> 
> The structure-based code looks a little cumbersome but is IMHO
> correct.

Sure. This also points out something that has always nagged me, and that the 
structure-based registers can be efficient, but it is *highly* dependent on the 
type of code that one is writing. I don't like the fact that this way 
(structure-based) is unconditionally promoted as better, when it is 
demonstrably questionable at the least.

Of course, the AVR port is also in desperate need of tuning and optimization, 
and perhaps that might also alleviate some pressure.

Eric



reply via email to

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