public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Joseph S. Myers" <jsm@polyomino.org.uk>
To: Giovanni Bajo <giovannibajo@libero.it>
Cc: "Svein E. Seldal" <svein.seldal@solidas.com>, gcc@gcc.gnu.org
Subject: Re: RFC embedded c proposal
Date: Thu, 29 Apr 2004 16:19:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.58.0404291411520.25216@digraph.polyomino.org.uk> (raw)
In-Reply-To: <057d01c42de1$e1ed3fd0$174a2597@bagio>

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

      reply	other threads:[~2004-04-29 14:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-29 11:25 Svein E. Seldal
2004-04-29 11:57 ` Paolo Bonzini
2004-04-29 12:51 ` Giovanni Bajo
2004-04-29 16:19   ` Joseph S. Myers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.58.0404291411520.25216@digraph.polyomino.org.uk \
    --to=jsm@polyomino.org.uk \
    --cc=gcc@gcc.gnu.org \
    --cc=giovannibajo@libero.it \
    --cc=svein.seldal@solidas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).