Re: flex/yacc--many multiple parsers in same program

gclind01@starbase.spd.louisville.edu (George C. Lindauer)
14 May 1996 20:20:21 -0400

          From comp.compilers

Related articles
flex/yacc--many multiple parsers in same program cowden@leitess.com (1996-05-13)
Re: flex/yacc--many multiple parsers in same program gclind01@starbase.spd.louisville.edu (1996-05-14)
Re: flex/yacc--many multiple parsers in same program qjackson@mail.direct.ca (1996-05-19)
Re: flex/yacc--many multiple parsers in same program zucco@world.std.com (1996-05-19)
Re: flex/yacc--many multiple parsers in same program vadim@mercury.co.il (1996-05-19)
Re: flex/yacc--many multiple parsers in same program pardo@cs.washington.edu (1996-05-19)
Re: flex/yacc--many multiple parsers in same program jlilley@ix.netcom.com (1996-05-19)
| List of all articles for this month |
From: gclind01@starbase.spd.louisville.edu (George C. Lindauer)
Newsgroups: comp.unix.programmer,comp.compilers
Date: 14 May 1996 20:20:21 -0400
Organization: University of Louisville, Louisville KY USA
References: 96-05-089
Keywords: lex, yacc, parallel

cowden@leitess.com (Michael Cowden) writes:


>I'm looking to write a single interpreter that can simultaneously
>parse up to 96 separate programs. Due to other restraints in the
>program I cannot fork a process to handle each parser. What are my
>options using lex and yacc? It seems like a real hack to get either
>of them to handle more than one program.


Just how important is simultaneity? I mean unless you have multiple
processors it is going to take approximately the same amount of time
to do it if you do them consecutively as if you do them
simultaneously. Consecutively would actually be faster because no
context switches or passing. The only reason I would consider
simultaneity is if there is some relationship between parsing the
different programs... i.e. if they cross-reference data or if the
parses have to be kept in sync for whatever reason. Even then you
might simply get away with keeping each pass through the input files
in sync...


A variation on the threaded theme Jon suggested is to change YACC and
FLEX slightly so that there are prefixes put on the names of all the
exported routines. Then you can just link 96 instances of the parser
together... kinda inefficient memory-wise but if you wanta follow
gate's lead it is a rather quick hack. Just be sure your parse
routines (the ones YACC calls) don't affect global
variables... i.e. you will have to pass a context to the parse
routines unless you want to instantiate the global data and parse
routines 96 times... and speaking of instantiation wasn't there a C++
version of YACC? Maybe it will let you make a parse class and
instantiate it a bunch of times...


David
--


Post a followup to this message

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