[Top][All Lists]

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

Re: [avr-libc-dev] Re: Far addresses in flash

From: John Devereux
Subject: Re: [avr-libc-dev] Re: Far addresses in flash
Date: 03 Jun 2005 18:16:37 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Paul Schlie <address@hidden> writes:

> > From: "E. Weddington" <address@hidden>
> >> Björn Haase wrote:
> >> A real solution of the issue would, IMO, require that someone adds
> >> functionality for supporting different memory spaces within gcc's C/C++
> >> front-end and gcc's mid-end.
> >> 
> > You're right, that's the best, and most needed solution.
> > However, *is* it possible to have 24-bit pointers in GCC
> > (as opposed to 32-bit)? How difficult would that be?
> - Likely not worth it, as GCC also presumes data to be aligned on
>   power-of-two unit boundaries, and it doesn't address the multiple address
>   space issues raised by Björn.
>   Personally, I believe the single largest obstacle associated with the
>   use of GCC for any reasonably serious AVR development is the fact that
>   presently complex literal data can quickly consume AVR's relatively small
>   RAM (as all data is presumed to be accessible from there), although
>   intermediate asm helper routines may be used to explicitly access other
>   memory spaces explicitly (or as Björn has also previously suggested, a
>   set of C++ pointer classes may be defined and utilized to hide the asm
>   routines within, thereby enabling the declaration of smart pointer classes
>   external to the compiler's implementation to abstract access to multiple
>   address spaces, which helps, but still requires that literal data be
>   declared and used in only limited ways, as otherwise will unnecessarily
>   still consume AVR's typically limited RAM.)

Agree emphatically. It would be really great if gcc could do this.


John Devereux

reply via email to

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