[Top][All Lists]

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

Re: [avr-gcc-list] mcall-prologues completely broken for >128k

From: Sean D'Epagnier
Subject: Re: [avr-gcc-list] mcall-prologues completely broken for >128k
Date: Tue, 12 May 2009 20:46:55 -0600

On 5/12/09, Weddington, Eric <address@hidden> wrote:
> I don't understand what you're doing here.
> You've completely removed EIJMP from gcc.

That is correct.  It is better for gcc not to use this instruction.

> And you cannot hardcode an SEI in avr-libc. How do you know that interrupts
> were previously enabled? Typically SREG is saved, then CLI, atomic code,
> SREG restored. You can restore SREG before the final atomic instruction
> because interrupts are delayed. See datasheet and elsewhere in avr-libc
> where this is done.

I am branching if interrupts are enabled instead of saving and
restoring SREG because I don't have __tmp_reg__ free to use.  Is there
a reason it wouldn't work?


> Eric Weddington
>> -----Original Message-----
>> From: Sean D'Epagnier [mailto:address@hidden
>> Sent: Sunday, May 10, 2009 12:26 AM
>> To: Weddington, Eric
>> Cc: address@hidden; Anatoly Sokolov
>> Subject: Re: [avr-gcc-list] mcall-prologues completely broken
>> for >128k
>> Hi,
>> Here are some patches.   Please take a look and tell me if what I did
>> with setjmp makes any sense.  I don't really use longjmp so it's not
>> fully tested, and it is only to handle a case which is very difficult
>> to create.
>> I have tested the gcc patch and my program is working very well now.
>> There is still a major issue of what to do in bootloaders.  It appears
>> that the trampolines do not get generated for bootloaders.. and how
>> can they?  For bootloaders the compiler should use eijmp and eicall
>> and set EIND to the bootloader segment at startup.  But what if
>> longjmp is used and what if application code is called?  I'm not sure
>> what the best solution is here, but currently I'm just glad my
>> bootloader doesn't need indirect jumps.
>> Sean

reply via email to

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