Paul Schlie <[EMAIL PROTECTED]> writes: > > From: "E. Weddington" <[EMAIL PROTECTED]> > >> 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 _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
