RFC embedded c proposal

RFC embedded c proposal

[Svein E. Seldal]

Hi,

I'm working on a patch on [AVR-]GCC to support multiple memoryspaces. 
The AVR has more than one memoryspace (code + data), and thus a 
modification to GCC is needed.

This standard proposal from ISO/IEC:

   http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n1021.pdf

contains issues about C extension in respect of embedded processors. In 
section 3.1.2. it suggests syntax for multiple memoryspaces:

	_X char a, b, c;
		// Declares three characters in address space _X

	_X const int *p;
		// Declares a pointer in the generic address space
		// that points to a constant int object in address
		// space _X

	_X struct { int a; char b; } *_Y q;
		// Declares a pointer in address space _Y that points
		// to a structure in address space _X

Now, if I were to implement this into GCC, what would be best method of 
  implementation? Consider:

a) Add the appropriate _X keywords for the target at hand (which in this 
case could be _Progmem, _Flash, _Code or similar)

*or*

b) Declare an __attribute__, e.g. __attribute__((progmem)), that will 
become a part of the type decleration:

	__attribute__((progmem)) char a, b, c;  // Works today in GCC

	__attribute__((progmem)) int *p;        // Does not work


Which of these two methods would be best suited for gcc?


Regards,
Svein

Re: RFC embedded c proposal

[Paolo Bonzini]

> b) Declare an __attribute__, e.g. __attribute__((progmem)), that will 
> become a part of the type decleration:
> 
>     __attribute__((progmem)) char a, b, c;  // Works today in GCC
> 
>     __attribute__((progmem)) int *p;        // Does not work
> 
> 
> Which of these two methods would be best suited for gcc?

I think this one; then if you want you can use builtin_define in the 
target's TARGET_CPU_CPP_BUILTINS #define, to define _Progmem to be 
__attribute__ ((progmem)).  This is how AltiVec works, at least.

Paolo

Re: RFC embedded c proposal

[Giovanni Bajo]

Svein E. Seldal wrote:

> Now, if I were to implement this into GCC, what would be best method
>   of implementation? Consider:
>
> a) Add the appropriate _X keywords for the target at hand (which in
> this case could be _Progmem, _Flash, _Code or similar)
> b) Declare an __attribute__, e.g. __attribute__((progmem)), that will
> become a part of the type decleration:

Well, there has been discussion in the past on GCC adopting the Embedded C
standard. If I were to do this, I would surely go with (a), implementing it
under a new language dialect, like -std=embedded-c or something. Doing this
with (b) looks like a bad idea in the longer run, as we will have an
alternative non-standard syntax to cope with forever.

Giovanni Bajo

Re: RFC embedded c proposal

[Joseph S. Myers]

On Thu, 29 Apr 2004, Giovanni Bajo wrote:

> Svein E. Seldal wrote:
> 
> > Now, if I were to implement this into GCC, what would be best method
> >   of implementation? Consider:
> >
> > a) Add the appropriate _X keywords for the target at hand (which in
> > this case could be _Progmem, _Flash, _Code or similar)
> > b) Declare an __attribute__, e.g. __attribute__((progmem)), that will
> > become a part of the type decleration:
> 
> Well, there has been discussion in the past on GCC adopting the Embedded C
> standard. If I were to do this, I would surely go with (a), implementing it
> under a new language dialect, like -std=embedded-c or something. Doing this
> with (b) looks like a bad idea in the longer run, as we will have an
> alternative non-standard syntax to cope with forever.

I don't believe anything in DTR 18037 (I haven't seen a final ISO TR)
conflicts with C99, and since the TR might continue after a new revision
of the C standard without a new version of the TR being issued the flag to
enable it (if one is required) should probably be orthogonal to the
existing -std flags.

The attribute syntax should be able to achieve the effects of the address
space qualifiers (maybe more hooks would be needed for the compatibility
checks specified), though no doubt if multiple targets want them then some
central support (with whatever syntax) may make sense; the syntax in DTR
18037 has at least been designed to a greater extent than attributes.

-- 
Joseph S. Myers
jsm@polyomino.org.uk