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