Related articles |
---|
GCC for BCPL tc@cs.bath.ac.uk (Tom Crick) (2004-11-20) |
RE: GCC for BCPL tom@kednos.com (Tom Linden) (2004-11-26) |
Re: GCC for BCPL nmm1@cus.cam.ac.uk (2004-11-26) |
Re: GCC for BCPL henry@spsystems.net (2004-12-11) |
From: | Tom Crick <tc@cs.bath.ac.uk> |
Newsgroups: | comp.compilers |
Date: | 20 Nov 2004 21:25:41 -0500 |
Organization: | Compilers Central |
Keywords: | parse, question, GCC |
Posted-Date: | 20 Nov 2004 21:25:40 EST |
Dear all,
I'm the maintainer of the GCC for BCPL project
(http://gccbcpl.sourceforge.net) and have recently got to the stage
where I need some help from fellow compiler-people!
Recently work has been spent on validating the BCPL grammar, but this
has forced a re-evaluation of using Bison to create the parser. The
original BCPL parsers were recursive-descent and certain language
features (particularly the optional semicolon problem) seem to point
towards their use now. However, does anyone with experience of BCPL
feel that Bison is adequate for generating a BCPL parser? As soon as
this stage is over, the development focus can move back to GCC
integration and the building of the (GCC 4.0) intermediate
representations.
Another minor issue, that was overlooked when posted to the GCC
mailing lists recently, was the potential re-use of a generic symbol
table structure that already exists within the GCC
infrastructure. Does anyone know if there is one, or if there are any
guidelines for symbol tables when developing front ends with GCC? I
have already re-used an existing table, but I just wondered if there
was no need to do this. [Apologies for the GCC-centric nature of this
question.]
Thanks and regards,
Tom Crick
tomcrick@users.sourceforge.net
http://gccbcpl.sourceforge.net
Return to the
comp.compilers page.
Search the
comp.compilers archives again.