Re: Evaluation of parser generators

cwilson@Xenon.Stanford.EDU (Christopher S. Wilson)
15 Dec 1997 21:57:15 -0500

          From comp.compilers

Related articles
Evaluation of parser generators wclodius@aol.com (1997-12-10)
Re: Evaluation of parser generators kadhim@spock.cs.colorado.edu (Basim Kadhim) (1997-12-12)
Re: Evaluation of parser generators thetick@magelang.com (Scott Stanchfield) (1997-12-12)
Re: Evaluation of parser generators wclodius@aol.com (1997-12-14)
Re: Evaluation of parser generators wclodius@aol.com (1997-12-14)
Re: Evaluation of parser generators cwilson@Xenon.Stanford.EDU (1997-12-15)
Re: Evaluation of parser generators parrt@magelang.com (Terence Parr) (1997-12-15)
Re: Evaluation of parser generators d.love@daresbury.ac.uk (Dave Love) (1997-12-23)
| List of all articles for this month |

From: cwilson@Xenon.Stanford.EDU (Christopher S. Wilson)
Newsgroups: comp.compilers
Date: 15 Dec 1997 21:57:15 -0500
Organization: Stanford SUIF Group
References: 97-12-092 97-12-113
Keywords: tools, Fortran

Wclodius <wclodius@aol.com> wrote:
>In response to Basim Kadhims post:


        [non-SUIF related Eli discussion removed]


>> We do have a complete grammar for Fortran 77 and 90 (they are
>> actually bundled together). The Fortran 77 specification also
>> includes an attribute grammar for name and type analysis (and SUIF
>> code generation).
>
>I should note that I was very pleased with Waite's documentation of
>many of these issues. I was a little surprised in checking up on SUIF
>that in the latest version they still seem to be relying on a modified
>version of f2c instead of your new version.


That's a reasonable thing to ask about. I work in the Stanford SUIF
Group, so let me respond.


The SUIF system is set up on a very decentralized model. We want
different groups at different locations to be able to contribute their
own packages. We don't want everyone to have to wait for their pieces
to be incorporated into a single central SUIF tar file. Instead we
provide a ``basesuif'' package that has the core libraries and enough
tools built on top of the core to do something useful (C and Fortran
front-ends, SUIF-to-C back-end). Everything else goes in add-on
packages. The Stanford SUIF group publishes 8 or so add-on packages
in addition to basesuif. Other groups at other places publish their
own packages directly on the web from their own sites.


Our f2c-based Fortran front-end in basesuif predates the Eli
Fortran-to-SUIF front-end. Its presence in basesuif should not be
construed as endorsing it as the one-and-only Fortran-to-SUIF
front-end. It's small, useful, and depends on nothing but basesuif,
so there's not really any reason to stop including it in basesuif.


What we do have is a web page with links to both SUIF packages that
Stanford publishes and SUIF packages that others currently publish.
This is the primary page for the SUIF software system
(http://www-suif.stanford.edu/suif), so packages from various places
are all treated the same as Stanford SUIF packages. We are happy to
put links to any published software using SUIF.


We have an ongoing on-line survey of projects using SUIF. The survey
is a web form (http://www-suif.stanford.edu/suif/survery) and from the
results we have produced a list of projects using SUIF
(http://www-suif.stanford.edu/suif/survey/results.html) for those who
indicated in the survey that they don't mind the information being
made public. The links to SUIF software are based on information
we've recieved from this survey, and apparently we haven't recieved
any information from the Eli group.


I was aware of the SUIF code generation for Eli, so I probably should
have noticed that they were missing from the survey results and sent
the Eli group a note asking them if they could fill out the form and
give us the appropriate link information; perhaps they missed the
survey announcement in the SUIF mailing lists. I'll do that now so
hopefully we'll get the link on the SUIF page soon.


> I was also a little
>surprised that you have not followed up with an F90 SUIF generator,
>although F90 is unfashionable.


Doing an F90-to-SUIF translator requires the mapping of a bunch of new
constructs that F90 introduces into SUIF code. You have to generate
various sorts of loops, dope vectors, and so on to make explicit the
things that the F90 constructs are doing implicitly.


So there's a non-trivial amount of work to do to go from a F90 AST to
constructs that SUIF can directly represent. This probably wouldn't
be very interesting to the Eli group, so I'm not too surprised that
they haven't gone to the effort. But there's no reason that someone
interested in Fortran 90 and SUIF couldn't do the work to bridge the
gap.


                --Chris Wilson
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.