[RFC] Gcc and multiple memory spaces (former Gcc and harvard architectures (towards AVR))

[Svein E. Seldal]

After some helpful pointers by Robert Dewar, I'm going to rephrase my 
questions. It seems like I have used the wrong terms, so I'm trying to 
clear things up by explaining my intentions better this time.

I would really like gcc to have support for several memory-spaces. 
Because some targets, like the AVR, has more than one memory-space; one 
for code (I-space) and one for data (D-space). And these spaces cannot 
normally intermix. The I-space is used by the CPU core to fetch new 
instructions, while the D-space is used for data storeage. While the 
I-space is normally reserved for storing code, it is possible to store 
data there as well in some targets. And these targets usually has 
different sets of opcodes to access these spaces; one set for D-space 
access, and one set for the special I-space access.

The AVR target (for one) has a very low memory (D-space), while it has 
reasonable amounts of flash (I-space). It would be an advantage if const 
variables, strings. etc. could be placed into flash (I-space). While it 
is possible to do so by using the 'progmem' attribute, it is impossible 
to get gcc to natively handle this information. This is caused by the 
simple fact that gcc is only capable of handling one memory space, which 
happens to be the runtime memory (D-space).

If users are to read from the flash (I-space), they have to fiddle 
around with manual assembly. This gives several obvious drawbacks: 
Strings that are placed into flash, are not collected. const structs in 
flash are a mess, because you have to access the members manually (using 
assembly), etc. Very errorprone!

I've spoken to the AVR maintainers about this feature, but they cannot 
implement this because it has global gcc implications.

Please see http://gcc.gnu.org/ml/gcc/2002-12/msg01194.html for a 
description of my suggestion.

It seems to me that this would imply the following changes/additions to gcc:

a) Implement attributes which places data in the appropriate memoryspace 
(ala the AVR-target's 'progmem' attribute)

b) Implement the ability to declare attributes on pointers (not just 
pointer storeage), which would make it possible to have pointers to 
locations in other memoryspaces.

c) Rewrite the target-specific parts of gcc where the memory accesses 
are translated into assembly. -- Take the AVR as an example. It uses 
different opcodes for accessing the D-space from the I-space. This 
implies that gcc must be able to generate the appropriate code for the 
correct address-space/access form.

FYI: The definitions of these memoryspaces are defined by the target 
architecture, never by the user in a runtime environment.

Unfortunately, I'm not a skilled gcc programmer (yet) so I would need 
lots and lots of help to do it. But this is something I'm very keen on 
getting implemented into gcc. The AVR target suffers from this 
limitation, were it is the greatest drawback for using gcc in AVR systems.

However I do not wish to burn too much energy trying to implement this 
feature is nobody wants it...

Is this idea realistically implementable into gcc?

What does the SC say about this? Isn't this food for their tables?

Please give me feedback on the issue if you have some.


Merry Christmas,
Svein