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) |
From: | qjackson@mail.direct.ca |
Newsgroups: | comp.compilers |
Date: | 19 May 1996 14:17:24 -0400 |
Organization: | Parsepolis Software ("ParseCity") |
References: | 96-05-089 |
Keywords: | lex, yacc, parallel |
> 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.
I've implemented a C++ class hierarchy for an interpreted pattern matching
language that theoretically can create as many machines as memory will allow.
At the deepest levels of shared tables (there are a few static tables),
there will be some semaphore activity to avoid truly simultaneous memory
access during key phases, but for the most part, the processes of scanning,
parsing, and interpreting LPM are handled at the level of object
encapsulation, and therefore, each instantiated Lpm object can be viewed as
a virtual machine. This allows one to instantiate "arrays" of interpreters
as easily as:
Lpm NinetySixInterpreters[96];
I imagine that several strategies become possible in light of this.
Yours,
Quinn Tyler Jackson
--
Parsepolis Software || Quinn Tyler Jackson
"ParseCity" || qjackson@direct.ca
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.