[avr-gcc-list] RFC gcc multiple memory space implementation

[Svein E. Seldal]

Hi everyone,

This mail is a rather exhaustive description of the problem at hand, 
explaining why we are discussion what we are discussing. If you are 
familiar with the problem, you can probably skip this mail and jump 
straight into the gory details...

As we know, gcc is currently unable to handle more than one memoryspace. 
The AVR architecture is a Harvard processor, it has effectively two 
memoryspaces; the flash/code and the ram/data space. (The EEPROM is a 
third space as well.)

(I'm avoiding the use of the term Harvard architecture from now on, due 
to a rather common misunderstanding among some software developers.)

Today GCC handles the memories spaces by all joining them into the one 
large space, separating them by using different locations for flash, 
data, etc. This works for mostly all cases, because with the aid of 
attributes you are able to place data in the appropriate memoryspace 
(i.e. EEPROM, flash, etc.) accordingly.

The problem arises when you are trying to access data in the non-native 
dataspace, like the flash or the eeprom. Since both data pointers and 
code pointer are using the same memoryspace, gcc is not able to 
differentiate on how to access this memory.

If a user want to access the code memory or the eeprom memory, the user 
has to manually use special methods by the CPU to access the memories 
(LPM opcode, EEARH/L + EEDR registers).

While this seems to work great in simple applications, this can become a 
rather cumbersome limitation in bigger projects.

Example of limitations:

- Strings must be declared in an aquard way:

        const char PROGMEM string[] = "String";

- Accesses to flash stores must be done manually (losing valuable 
compiler optimalisations):

        const int PROGMEM var = 12;
        pgm_read_byte(&var);

- No type conversion errors:

        int *ptr = &var;   // No error despite &var is a code ptr

- Linked structs/pointers are impossible, ie. structs containing other 
flash pointers:

        struct simplestruct {
                const char *command;
                void (*callback)(void);
        };

        struct simplestruct PROGMEM bad = {
                "Not possible",
                myfunc
        };
        
The code above will allocate the "Not possible" string in datamemory(!). 
You'll have to do it like this:

        const char PROGMEM possible[] = "Possible";
        struct simplestruct PROGMEM cumbersome = {
                possible,
                myfunc
        };

I could probably go on and on to list poor features. My point is just to 
identify the problem to be able to provide a possible solution and 
discussion.


Regards,
Svein