Re: AVR 16-bit I/O access order fix, PR target/20288

[Paul Schlie <schlie at comcast dot net>]

> From: Björn Haase <bjoern.m.haase@web.de>
> one brief remark concerning the issue of support for multiple memory spaces
> in gcc. In my opinion it is a principal weakness of the c-language that it
> assumes a single unified memory space and IMHO it will never be possible to
> overcome this difficulty without using extensions to the language.

- I fully agree in general; however believe if the goal is limited to simply
  enabling target specific control over the allocation and access to static
  const read-only data (which uniquely need not be allocated in read-write
  RAM); then no new language facility need be introduced to identify and
  control the access to such references as long they are consistently
  retained throughout the compilation process, and visible during target
  specific code generation.

  However acknowledge that in order to prevent the potential ambiguities
  which may be introduced by logically orthogonal address space pointers
  (as GCC presently presumes a single orthogonal address space); it may
  be necessary map the logical ROM (read-only) address space into a subset
  of the logical RAM (read-write) address space; thereby enabling a single
  pointer value to unambiguously point to a value in ether, while
  simultaneously enabling the compile-time generation of code based upon
  whether the logical reference is a ROM (read-only) reference or not.

  Assuming a simple address map of an avr uC for example:

    -----------------  (pointer address start)
   | registers & i/o |
    -----------------  (ram start)
   |                 |
   | RAM(read-write) | <- [presumed target of read-write object references]
   |                 |
    ~ ~ ~ ~ ~ ~ ~ ~ ~  (ram end)
   |                 |
    ~ ~ ~ ~ ~ ~ ~ ~ ~  (rom start)
   |                 |
   | ROM (read-only) | <- [presumed target of read-only object references]
   |                 |
    -----------------  (rom end)
   |                 |
    -----------------  (pointer address end)

> What I personally have done in order to solve this issue for me is: I
> switched to c++ for my projects. While still writing essentially c programs

- haven't tried in a while, does C++ for the avr target currently work?

> and refraining from using, e.g. new and delete, I am using c++ for the single
> purpose to have access to the extended type system. This makes it possible to
> define classes like "pointer to program memory", array in program memory or
> "variable in eeprom". WIthin the class definitions, I make use of inline
> assembly expressions that handle the operations. E.g. for the class

- essentially similar to using target specific attributes in C to identify
  specific declared objects (assuming function parameter attributes are
  enforced, but doesn't enable dynamic function selection as you note C++
  does; so unfortunately requires them to be visible during rtl code
  generation, which they consistently aren't).

> uint8_t_eeprom one could overload the "=" operator so that it writes the
> right hand side into the eeprom or one could define a conversion routine to
> uint8_t that essentially implements a eeprom read access. The only thing to
> keep care of then is to make shure that the linker places objects of class
> uint8_t_eeprom in the .eeprom section (by using appropriate attributes when
> defining the object). Code is fairly efficient. Similar solutions work for
> program memory.

- I like the approach; have you been successful in preventing the redundant
  relocation of all compiler generated static const data from ROM to RAM
  upon program startup/initialization?

  (As it would seem that even the C++ compiler may still assume this to be
   done for string, array, struct, constants; likely still requiring some
   form of target specific intervention to properly handle such data? If
   your approach allows this to be eliminated that's great, as this is the
   problem with targets which may only have a few KB of RAM total.)