Related articles |
---|
Modularize compiler construction? pengyu.ut@gmail.com (Peng Yu) (2010-01-23) |
Re: Modularize compiler construction? kkylheku@gmail.com (Kaz Kylheku) (2010-01-24) |
Re: Modularize compiler construction? cr88192@hotmail.com (BGB / cr88192) (2010-01-24) |
Re: Modularize compiler construction? cr88192@hotmail.com (cr88192) (2010-01-25) |
Re: Modularize compiler construction? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2010-01-25) |
Re: Modularize compiler construction? pengyu.ut@gmail.com (Peng Yu) (2010-01-25) |
Re: Modularize compiler construction? idbaxter@semdesigns.com (Ira Baxter) (2010-01-28) |
Re: Modularize compiler construction? gneuner2@comcast.net (George Neuner) (2010-01-28) |
Re: Modularize compiler construction? ott@mirix.org (Matthias-Christian Ott) (2010-01-31) |
Re: Modularize compiler construction? cr88192@hotmail.com (BGB / cr88192) (2010-01-31) |
Re: Modularize compiler construction? gneuner2@comcast.net (George Neuner) (2010-02-01) |
Re: Modularize compiler construction? sh006d3592@blueyonder.co.uk (Stephen Horne) (2010-02-08) |
From: | Peng Yu <pengyu.ut@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Mon, 25 Jan 2010 12:32:59 -0800 (PST) |
Organization: | Compilers Central |
References: | 10-01-080 10-01-082 |
Keywords: | design |
Posted-Date: | 28 Jan 2010 01:19:06 EST |
On Jan 25, 12:18 pm, Kaz Kylheku <kkylh...@gmail.com> wrote:
> On 2010-01-23, Peng Yu <pengyu...@gmail.com> wrote:
>
> > It seems that the current compiler construction tools (at least in
> > bison and flex) are still very primitive. Let's take the following
> > example to explain what I mean.
>
> bison and flex are not tools for /complete/ compiler construction.
>
> > easily composing different modules. It seems that there is a great
> > semantic gap between what bison & flex offer and what compiler design
> > need.
>
> The gap between what you think a tool should do and what it does is
> not a ``semantic gap''.
It doesn't matter what you call the gap. But you clearly understand
that there is a gap.
> A word processor isn't a first-person shooter video game. If you
> expect a word processor to be such a game, that doesn't mean there is
> a ``semantic gap'' beween word processors and video games, only that
> you have an unrealistic expectation.
>
> Bison does not provide the semantics of translation, only a way to
> build a parser, which is far, far from a complete translation scheme.
> It can be argued that a parser-generation tool /should/ only do that
> one job. A more complete compiler construction suite would still have
> a parser generator tool inside it which does only parser generation.
>
> The GNU project does have a much more complete compiler construction
> suite: it's called the GNU Compiler Collection (perhaps you've heard
> of it). In this suite you can write a new language as a front end
> module, which re-uses the posterior modules.
But I don't think GCC's internal structure is very accessible for a
new compiler building programmer to build a new compiler, as I don't
find documentation on GCC internal library structure. Do you know if
such documentation is available? It would be more convenient if there
is a library that can be extracted from GCC as stand-along and well
documentation API so that new compilers can be built be putting
together different modules. But I don't see how to do so with GCC.
Would you please let me know how to do so if you think that using GCC
is a viable approach?
Return to the
comp.compilers page.
Search the
comp.compilers archives again.