[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] RFC gcc multiple memory space implementation
From: |
Svein E. Seldal |
Subject: |
Re: [avr-gcc-list] RFC gcc multiple memory space implementation |
Date: |
Wed, 28 Apr 2004 20:56:15 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; nb-NO; rv:1.6) Gecko/20040413 Debian/1.6-5 |
Hi
My suggestion on how the gcc compiler idealy should work, would look
like this:
- Introduce a new attribute that you may assign to the type definitions
of pointers (please note, its not a part of the data storeage, but the
type of the variable):
char __attribute__((__progmemptr__)) * cptr; // **or**
char pm * cptr;
How the attribute "pm" or "attribute..." is written is really
irrelevant. We only need the feature in itself. Personally I like the
first one best, because it fits GCC better IMHO.
#define PM __attribute__((__progmemptr__))
Note that the attribute is a part of the type:
char * dptr = cptr; // Invalid; cptr is a code pointer
For avr-libc this will lead to:
void puts(const char * str);
void puts_P(const char PM * str);
puts( cptr ); // Invalid; cptr is a code pointer
puts_P( cptr ); // Valid
And finally:
int temp;
cptr = &temp; // Fail, because temp is not located in flash
- Introduce native, automatic accesses to the memoryspaces based on the
types of the accesses:
int temp;
temp = *ptr; // LPM's the contents of code-adr PTR
One of the major issue concerning implementing this into gcc is the fact
that gcc has no current mechanisms for setting attributes that are a
part of the type. GCC has attributes for functions and for data
storeages, but not for types.
Comments?
Svein