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

[Paul Schlie]

> From: "E. Weddington" <address@hidden>
>> 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.)