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

Jim Granville <jim.granville@designtools.co.nz>
1 Nov 2000 18:32:46 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: Dragon Book - update necessary? rhyde@cs.ucr.edu (Randall Hyde) (2000-10-15)
Re: Dragon Book - update necessary? bruce@hoult.org (Bruce Hoult) (2000-10-19)
Re: Dragon Book - update necessary? rhyde@cs.ucr.edu (Randall Hyde) (2000-10-23)
Re: parsing tools, was Dragon Book - update necessary? LLkParsing@aol.com (2000-10-26)
Re: parsing tools, was Dragon Book - update necessary? rhyde@cs.ucr.edu (Randall Hyde) (2000-10-31)
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)
[1 later articles]
| List of all articles for this month |

From: Jim Granville <jim.granville@designtools.co.nz>
Newsgroups: comp.compilers
Date: 1 Nov 2000 18:32:46 -0500
Organization: Mandeno Granville elect
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
Keywords: parse
Posted-Date: 01 Nov 2000 18:32:46 EST

Randall Hyde wrote:
<snip>
> (3) Being written in Java concerns me. What is the performance like?
> Granted, it's got to be better than running 100 KLOC through Bison
> (which generally takes about a minute on my machine), but I would
> really like better turn around on the compiles with the next version.
<snip>
> That means that I have a pretty good idea of what needs to be done
> if I write HLA in a language like C++ or object Pascal (or even HLA,
> for that matter). I'm not at all sure what the issues will be if I
> switch to a tool like ANTLR. This is a traditional software engineering
> risk management problem: do I go with the tried and true mechanism that
> is safe, or do I try to use a tool and hope that the tool is appropriate?
> On the one hand, ANTLR (or some other tool) could save a lot of effort.
> OTOH, the tool may turn out to be inappropriate and I get locked into
> using the tool or waste a couple of years of my life and have to start
> over using the 3rd generation language approach.
>
> Whatever, the actual work on V2.0 is still about a year away, so
> I've got lots of time to mull over this decision (and, perhaps,
> play around with some tools in the meantime).
> Randy Hyde


How about the idea of an approach similar to multi path code
generation? An example would be code written in any HLL, that
includes Assembler. Here, you code first in the highest level
language, then tune the ASM where required. We like to use a preparser
so the original HLL and Tuned ASM can reside in the same source,
simplifying audit trails.


  Applying this to a compiler-generator, you would need the equivalent
of a pre-parser IF..ELSE..ENDIF to switch between the highest level,
using grammar 'rules', and a replacement code block, that was hand
optimised from an earlier pass. ( and I concur the replacement paste
is non-trivial, but can be helped by the fact it can be tagged by the
original generator )


  In your case, ideally, the generated code, and lowest level would be
HLA - but that points to some extra effort to create an HLA generator,
so you might choose C as the generated/optimised code.


  Or, maybe your HLA is able to link with C++ or Object Pascal, and
give 3 choices of source level :-).


- jg
[The problem with that kind of approach is that the different branches
too often end up with subtly different behavior, causing debugging
headaches when moving to a different platform and "nothing has changed".
Also, as has often been noted elsewhere, unless you measure your actual
running code, you'll usually guess very wrong about where the hot spots
in your code are. -John]







Post a followup to this message

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