[Top][All Lists]

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

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

From: ken restivo
Subject: Re: [avr-gcc-list] avr-gcc generating ldd r31, Z+
Date: Fri, 28 Dec 2001 19:56:26 -0800
User-agent: Mutt/1.2.5i

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!

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

reply via email to

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