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

[Weddington, E. <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
> 
> 
> 
> 
>