> From: "E. Weddington" <[EMAIL PROTECTED]> >> Bj�rn Haase wrote: >>> Am Donnerstag, 2. Juni 2005 14:57 schrieb Per Arnold Bl�smo: >>> Although I think it would have been best to have the possibilities to >>> support 24bits pointers in avr-gcc. >> >> The root of the problem, IMVHO is that what one is looking for in fact is not >> only 24 bit pointers but various distinct classes of pointers, i.e. support >> for different types of memories: Pointers to Ram (probably 16 bits wide), >> Pointers to Flash (both 16 bits and 24 bits) Pointers to EEPROM (possibly >> also in two flavours with 16 bits and 24 bits , etc.). >> >> Presently, IIUC, gcc has support only for one single class of pointer: The >> case for conventional C. >> >> IMO, switching PMODE to PSImode (4-Byte integer, only partially used) is not >> a >> solution since it would change the width of all pointers at the same time. >> E.g. also RAM pointers and EEPROM pointers would happen to be 32 bits wide >> what is certainly not useful. >> >> 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.) After screwing around attempting to reliably identify and enable direct access to read-only literal data which may be stored in program-rom, but still requiring some form of GCC extension to enable pointers to such data to be identified when passed as an argument or returned from a function; I've given up, as GCC doesn't reliably enable it's identification during code generation as it seemed it should, likely due to years of assumption that it was apparently unnecessary for most platforms (as would be the case for targets with a single unified address space, but not multiple discrete addresses spaces like that of AVR). So presently I'm of the opinion that Bj�rn's C++ smart-pointer class definition suggestion is both the easiest to implement and use from a practical point of view; thereby enabling the specification of 32-bit unsigned int smart-pointers for direct FLASH and EEPROM data access as may be desired. (however for both performance and efficiency reasons only 16-bit pointers are required for code and ram, as call/jump tables should be used for extended program code access, and is sufficient for ram data; therefore no tweaks beyond call/jump tables support should be required to enable more generalized AVR support. Although still wish literal ROM based data access could be more intelligent and transparent, but it doesn't seem possible without both GCC and language refinements to enable it's more flexible and specific allocation and access.) _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
