Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!floyd!whuxle!mit-eddie!genrad!decvax!cca!ima!haddock!johnl
From: johnl@haddock.UUCP
Newsgroups: net.lang
Subject: Re: Parsers for small micros (8-bits) - (nf)
Message-ID: <178@haddock.UUCP>
Date: Tue, 29-May-84 23:36:52 EDT
Article-I.D.: haddock.178
Posted: Tue May 29 23:36:52 1984
Date-Received: Thu, 7-Jun-84 07:36:34 EDT
Lines: 26

#R:sdccs7:-124000:haddock:12300002:000:1236
haddock!johnl    May 28 22:52:00 1984

Anybody who says that creating LR(1) parse tables by hand is easy has a
different understanding of "easy" than the rest of us do.  However,
there's no need to do it by hand.  If you're using a UN*X system, you
have yacc handy.  Run your grammar through yacc, which creates a parser
consisting mostly of tables and partly of a C program to interpret them.
Discard the C code (since it belongs to AT&T, and you're probably not
programming your micro in C anyway) and use the tables.  Read Aho &
Ullman and the C code you just discarded to figure out what the tables
mean.

The big advantages of LR(1) parsing are that the tables can be
constructed mechanically from the grammar, which makes subsequent tweaks
to the grammar easy, and that it detects an error quickly -- as soon as
it sees a symbol that can't be part of a legal piece of syntax.  The
disadvantage is that the tables can be kind of large.

If you're tight on space and your language isn't too big or wierd, you
might consider doing what Ritchie's original compiler (which had two
passes, each of which fit in 12K) does, operator precedence for the
expressions and recursive descent for everything else.  Much smaller and
not all that hard to write.

John Levine, ima!johnl