[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] [Bug #3184] XCALL resolved incorrectly in avr5/libc.a
From: |
E. Weddington |
Subject: |
Re: [avr-libc-dev] [Bug #3184] XCALL resolved incorrectly in avr5/libc.a |
Date: |
Fri, 11 Apr 2003 09:27:43 -0600 |
On 11 Apr 2003 at 13:38, Joerg Wunsch wrote:
> As Marek Michalkiewicz wrote:
>
> > On Fri, Apr 11, 2003 at 12:07:19PM +0200, Joerg Wunsch wrote:
> > > . the library compilation cannot decide whether the device
> > > supports
> > > the ELPM instruction (not all avr5 devices do support it)
> >
> > If all uses of ELPM are limited to gcrt1.S and include files, that
> > should be no big problem.
>
> I know, that's the way it is now.
And it should still work that way with the new pgmspace.h stuff I
have on my plate.
> > GCC itself does not use ELPM at all, and puts "progmem" data at low
> > addresses, avoiding the use of inefficient 24-bit pointers, and
> > still leaving the upper 64K for executable code - looks like a good
> > compromise to me.
>
> But that prevents people from using > 64 KB of constant »progmem«
> data. I think an option to allow for this would be nice (like
> -mlarge-model or something like that), in case someone really needs
> huge tables in flash ROM, with only little code. Of course, it should
> be off by default.
IIRC, there have been several users wanting to do this (AVR Freaks
posts). But this is probably a big change and IMO should be done at a
later date.
Eric
[avr-libc-dev] [Bug #3184] XCALL resolved incorrectly in avr5/libc.a, nobody, 2003/04/11
[avr-libc-dev] [Bug #3184] XCALL resolved incorrectly in avr5/libc.a, nobody, 2003/04/12