[antlr-interest] Re: C++ grammar
iank at bearcave.com
iank at bearcave.com
Fri Jun 14 07:42:16 PDT 2002
> David Wigg's ANTLR wish list
>
> 1. A standard way of being able to pass Comments and Compiler
> Directives etc. through ANTLR (without having to find a way of
> fudging it yourself)
>
> 2. A standard way of passing column number with text and/or token
> (ditto)
I think that David has made a good point here. It is not that this
cannot be done in ANTLR as it exists. And most people who write
serious ANTLR parsers with nice error messages (which is one reason
one uses ANTLR) do this. Since many of us add these features, it
might make sense to make these into builtin features.
Since I'm throwing my few pennies into the ring, I'll throw
out some thoughts on the C++ code generator.
I have caught a disease called digital signal processing during the
last year. Wavelets have consumed my fevered brain, distracting me
from all work on compilers. I am only now starting to hope that
recovery is on the way. So I have not worked with the new code
base. However, when I last saw it, the code base (e.g., the ANTLR
scanner) made heavy use of the C++ STL.
I recently wrote a scanner/parser for an XML subset (OK, I guess I
still do some lanuage processor related work) using STL. It is much
slower than I would have expected. There are a variety of reasons
for this, but the STL streams, at least on Solaris, seem to be
slow.
I have not actually benchmarked my Java parser, so I don't know how
fast it is. So I don't know if the overhead of STL is an issue.
Also, in the past I've disregarded this issue, since I thought that
the overhead of building the symbol table, doing semantic analysis
and building the control flow/data flow graph would consume at least
as much time as the parser, so the parser would not be the
bottleneck.
However, I keep thinking about Microsoft's C++ compiler compared to
the Sun or GNU C++ compiler. Microsoft's compiler is much faster
(bless their little dark hearts). From what I understand this may,
in part, be attributable to the front end, which got a major rewrite
somewhere around release 5.
So has anyone looked at parser performance? Is it worth the effort
to think about removing STL from ANTLR?
Ian Kaplan
iank at bearcave.com
www.bearcave.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
More information about the antlr-interest
mailing list