Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!rutgers!husc6!mit-eddie!genrad!decvax!ucbvax!hplabs!hpcea!hpfcdc!hpfclq!kah
From: kah@hpfclq.HP.COM (Kathy Harris)
Newsgroups: net.lang
Subject: Re: Faster parser driver for yacc?
Message-ID: <2250002@hpfclq.HP.COM>
Date: Thu, 16-Oct-86 17:18:26 EDT
Article-I.D.: hpfclq.2250002
Posted: Thu Oct 16 17:18:26 1986
Date-Received: Tue, 21-Oct-86 21:53:36 EDT
References: <2250001@hpfclq.HP.COM>
Organization: Hewlett-Packard
Lines: 25

/ hpfclq:net.lang / DMB@PSUVMA.BITNET /  2:00 pm  Oct  8, 1986 /
>Is the parser Yacc generates really the bottleneck? My understanding was that
>it was one of the faster parts, so that any minor changes wouldn't effect
>speed that much.

>                dave
----------

It depends on what you want to use yacc for.  In compilers, it's probably
true that the computation involved in code generation makes the parse
time less critical.

However, yacc can be useful as a parser for other types of input languages
where the computation task is not so great and so yacc becomes a large
part of the task.  A more efficient yacc parser would make it feasible
to use yacc in more contexts than just compilers.

The application I've been looking at is an assembler that uses yacc to
parse the assembly source.  Currently, yyparse is 25%+ of the user time.
I'm looking for ways to speed of the parse phase, and yet not sacrifice
the flexibility (eg, in adding support for new instructions and addressing
types) that is provided by yacc.

kathy harris
{hplabs | ihnp4}!hpfcla!kah