Re: parsing tools, was Dragon Book - update necessary?

Randall Hyde <rhyde@cs.ucr.edu>
4 Nov 2000 01:42:03 -0500

          From comp.compilers

Related articles
[8 earlier articles]
Re: parsing tools, was Dragon Book - update necessary? ed_davis@my-deja.com (Ed Davis) (2000-11-01)
Re: parsing tools, was Dragon Book - update necessary? jim.granville@designtools.co.nz (Jim Granville) (2000-11-01)
Re: parsing tools, was Dragon Book - update necessary? iank@idiom.com (2000-11-01)
Re: parsing tools, was Dragon Book - update necessary? jmochel@foliage.com (2000-11-01)
Re: parsing tools, was Dragon Book - update necessary? joachim_d@gmx.de (Joachim Durchholz) (2000-11-01)
Re: parsing tools, was Dragon Book - update necessary? LLkParsing@aol.com (2000-11-01)
Re: parsing tools, was Dragon Book - update necessary? rhyde@cs.ucr.edu (Randall Hyde) (2000-11-04)
Re: parsing tools, was Dragon Book - update necessary? rhyde@cs.ucr.edu (Randall Hyde) (2000-11-04)
Re: parsing tools, was Dragon Book - update necessary? LLkParsing@aol.com (2000-11-05)
| List of all articles for this month |
From: Randall Hyde <rhyde@cs.ucr.edu>
Newsgroups: comp.compilers
Date: 4 Nov 2000 01:42:03 -0500
Organization: Posted via Supernews, http://www.supernews.com
References: 00-10-061 00-10-067 00-10-093 00-10-109 00-10-130 00-10-193 00-10-209 00-10-221 00-11-013
Keywords: performance, practice
Posted-Date: 04 Nov 2000 01:42:03 EST

Joachim Durchholz at joachim_d@gmx.de wrote on 11/1/00 4:49 PM:


> <snipped discussion of HLA recursion>
>
> Er... are you sure that this mutual recursion is bounded? Many systems
> have surprisingly small stacks.


Hahahahaha.
Not at all. It depends on the HLA source code fed to the compiler.
(you can have recursive macro invocations appearing as parameters to
macro invocations appearing as macro invocations... inside a compile-
time loop.)


However, I did go in and hack the Bison sources to greatly increase
the size of the parse stack. Thus far I haven't encountered any problems
(and I've written some pretty hairy macros, haven't done Ackerman's function
yet, but... :-)


OTOH, the current compiler *is* a prototype and has many known memory leaks
and other implementation deficiencies. Fortunately, I've been able to fix
the ones that have reared their ugly heads to date (I've probably written
about 75,000 lines of HLA code to date).


>> (3) Being written in Java concerns me. What is the performance like?
>
> Java in general is relatively slow. Whether it's a problem for your
> project I cannot say; I think most current-day compilers spend most of
> their time outside of scanning and parsing anyway, and your compiler
> seems to be in that category, so it's probably not a big issue.


I guess that will depend on the size of the ANTLR grammar I wind up
with. Current Bison compilation on a 100 KLOC file on an 800 MHz PIII
is about 30 seconds (plus a little less time to compile with BC++).
That's annoying but livable. I could live with twice this time in
v2.0 since it's not going to be a prototype and I don't expect
anywhere near as many edit-compile-test cycles.


I'm sure I'll have to look at ANTLR for no other reason than professional
development. Maybe I should try writing a compiler for a smaller language
with ANTLR and see how that goes before committing to doing HLA with
ANTLR.


Randy Hyde
(BTW, someone commented that HLA has a small grammar. Even throwing out
the stuff associated with flattening the grammar it still has a large
number of productions. I haven't looked at a JAVA grammar, so I can't
directly compare them, but it's probably an order of magnitude worse than
languages like C/C++).


Post a followup to this message

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