This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC embedded c proposal


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]