Re: [avr-gcc-list] avr-gcc generating ldd r31, Z+

[ken restivo]

Yep, that's exactly the problem. 

Ted and I both missed the distinction between Z+ and Z+d, and he's provided a 
patch to handle LDD correctly.

You are correct, there was nothing wrong with the avr-gcc-generated code. 

Thanks for the explanation!

-ken
----------
On Sat, Dec 29, 2001 at 04:32:35AM +0100, Jens Andersen wrote:
> Hi Ken
>
> I have checked the Atmel instruction set document, and to me it
> seems that the gcc generated code is ok.
>
> As i read it, it says that if you load (Z) r30,r31 using the
> Z+ (post-increment) or -Z (pre-decrement) form the result is undefined.
>
> The gcc code uses the Z+q (displacement) form of the ldd instruction
> which leaves Z unchanged, so it should be ok.
>
> I hope this helps you.
>
> Jens Andersen
>
On Sat, Dec 29, 2001 at 01:58:03AM +0100, Kasper Pedersen wrote:
> >I seem to have found an avr-gcc/as bug, or perhaps I am doing something 
> >wrong here.
> >Here is the relevant section of disassembly:
> >t = t->next;
> >152: 07 80 ldd r0, Z+7 ; 0x07
> >154: f0 85 ldd r31, Z+8 ; 0x08
> >156: e0 2d mov r30, r0
> >The databook states that ldd r31, Z+ is undefined, and simulavr is honoring 
> >that and halting at instruction 0x154.
> 
> It makes sense that LD pointer-half,pointer+/-pointer could be undefined as 
> it has two results for one register(and IS specified as
> undefined in the
> datasheet), however "ldd pointer-half,pointer+displacement" at 0x154 in your 
> code has only one result, and IS valid/defined..
> 
> So I would guess there's a fluke in simulavr.
> 
> /Kasper
> 
avr-gcc-list at http://avr1.org