This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc translator build with QT
On Thu, 19 Jul 2012 15:45:16 +1000
Chris Jones <chrisjones@spin.net.au> wrote:
> Basile Starynkevitch wrote:
> > On Thu, 19 Jul 2012 13:23:40 +1000
> > Chris Jones <chrisjones@spin.net.au> wrote:
> >
> >> Is there any reason that I can't create a new front-end translator for
> >> gcc using QT?
> > GCC being a free GPLv3 software, you could always fork it and do that. But I am not sure
> > to understand what you really are thinking of.
> >
> > While current GCC is easily extensible thru plugins (or MELT extensions, see
> > http://gcc-melt.org/ for more), there is no plugin interface to add a new front-end (yet).
> >
> > And Qt http://qt.nokia.com/ being mostly a graphical interface toolkit, I don't see how
> > it is relevant to a new front-end.
> >
> > GCC has very deeply the idea that you compile compilation units (such as toplevel C
> > files) in whole by parsing some files.
>
> You might remember a while ago I was asking how to implement a new
> language support into gcc. And it was suggested to me by several people
> that implementing it via a front-end and translator would be the best
> way to go.
You might have a confusing terminology, with regards to GCC internals.
You could implement a new language by making a translator from that language to C (this
is actually a good idea, and I am doing that in MELT; MELT is a domain specific language
to extend GCC, see http://gcc-melt.org/). Don't call that translator a front-end.
You could choose to have your translator emit standard C code, then it should generate C
code compilable by any C compiler (e.g. gcc, tcc, clang, ...).
You could also choose to have your translator emit C code with GCC extensions.
http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
Many GCC extensions are useful when emitting C code (e.g. variable length array,
labels as values & computed gotos, attributes, extended asm, builtins...); some GCC
extensions are accepted by some other compilers (e.g. Clang). But standard conforming
compilers should only follow the C standards (and don't provide all GCC extensions).
If you choose to emit C code, your translator probably depends upon GCC but is *not* a
GCC front-end; it is an independent program which happens to need GCC.
Alternatively (and probably latter, once you have a prototype implementation of your
language), you could make a GCC front-end for your language. This requires you to develop
a large bunch of code which is linked inside (your fork of) GCC. This also requires you
to understand the details of GCC middle-end representations and passes.
Within the GCC community, a GCC front-end is a large bunch of code linked inside GCC.
Look inside GCC source code, notably gcc/go/ & gcc/objc/ for examples.
A translator emitting C code for GCC should not be called a front-end.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***