Re: [avr-llvm-devel] Current Status?

[Borja F. <bor...@gm...>]

This is what I've found in atmega's 644pa datasheet:

1) when reading do LSByte first
2) when writing do MSByte first

It explains the order is very important because there's some temp register
when reading/writing some registers of the 16bit timers that gets activated
with this particular order. Since these regs are present up to address 0xff
then all in/out instructions should follow this order. Also LDS/STS
instructions that use this address range should follow this order for
addresses between 0x60 and 0xff, I think that making all sts/lds
instructions follow this order instead of that specific range is ok, i
can't think of a penalty of doing this.
Now things get a bit harder for ld/st instructions because there's no way
to know what is the actual address being used. Reversing the order is not
good because it messes up postinc or predec operations, maybe only reverse
the order if the address is volatile? just an idea.
As an example IAR doesn't care at all, it only reverses in/out
instructions, so unless I'm missing something it's going to produce wrong
code.

2012/3/9 Weddington, Eric <Eri...@at...>

> Hi Borja,
>
> Yes, there is a certain order. It's one way for reading, and another for
> writing. And then, for the xmega devices, it gets switched around for
> one of the operations. :-P
>
> Unfortunately, I can't remember off the top of my head which is which.
> I'll have to go take a look at the AVR GCC backend code to refresh my
> memory...
>
> Eric
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Wednesday, March 07, 2012 2:38 PM
> > To: John Myers
> > Cc: avr...@li...
> > Subject: Re: [avr-llvm-devel] Current Status?
> >
> > Eric, one question. I vaguely remember that when reading or writing (i
> can't
> > remember if both) a 16 bit variable from RAM there was a certain
> order, MSByte
> > first then LSByte or the other way round. Can you clarify this
> information for
> > me and where is this specified and for which memory space this
> happens.
> >
> >
> > 2012/3/5 Borja Ferrer <bor...@gm...>
> >
> >
> >       Ah John one more thing, you may want to combine
> SelectionDAGBuilder.diff
> > and TargetCallingConv.diff into one file since they both are used for
> the same
> > purpose, you can name the patch SplitArgPiece
> >
> >
> >       2012/3/5 Borja Ferrer <bor...@gm...>
> >
> >
> >               For now, spload should be the only pseudo that is
> allowed to get
> > into assembly, if you see any other pseudo it is a bug. Expanding
> spload into
> > real instructions requires a bit of work that is currently
> unimplemented, so
> > for now we'll have to live with it. I hope it's not a big deal for
> you.
> >
> >               About the patches, it's a good idea what you said, feel
> free to do
> > it when you have time. I still have to add some more patches about
> interrupts.
> >
> >
> >               2012/3/5 John Myers <ato...@gm...>
> >
> >
> >                       On Sun, Mar 4, 2012 at 1:33 PM, Borja Ferrer
> > <bor...@gm...> wrote:
> >
> >
> >                               John check the lastest patch files I've
> just commited
> > to see if they patch correctly or i've messed them.
> >                               Btw, have you been able to try the
> backend?
> >
> >
> >                       They all apply cleanly but you have to hunt
> around to find
> > which directory to start in for each file. I'm going to combine them
> into one
> > patch that can be applied from the root directory.
> >
> >
> >                       I haven't really looked at the backend yet . I
> did notice
> > that there was a pseudo instruction (spload) that made it into the
> assembly
> > file which stopped avr-gcc from being able to assemble it though.
> >
> >                       main:
> >                           push    r28
> >                           push    r29
> >                           spload    r29:r28, SP
> >                           sbiw    r29:r28, 2
> >                           ldi    r24, 0
> >                           ldi    r25, 0
> >                           std    Y+1, r24
> >                           std    Y+2, r25
> >                           spload    r29:r28, SP
> >                           adiw    r29:r28, 2
> >                           pop    r29
> >                           pop    r28
> >                           ret
> >
> >
> >
> >
> >
>
>