Re: re-entrant parsers, pure_parser, bison, flex

Ray Dillinger <bear@sonic.net>
22 Jul 1997 20:58:57 -0400

          From comp.compilers

Related articles
re-entrant parsers, pure_parser, bison, flex lmipjmy@eei.ericsson.se (PJ Mealy) (1997-07-13)
Re: re-entrant parsers, pure_parser, bison, flex lmipjmy@eei.ericsson.se (PJ Mealy) (1997-07-16)
Re: re-entrant parsers, pure_parser, bison, flex tiggr@ics.ele.tue.nl (1997-07-16)
Re: re-entrant parsers, pure_parser, bison, flex lmipjmy@eei.ericsson.se (PJ Mealy) (1997-07-18)
Re: re-entrant parsers, pure_parser, bison, flex cfc@world.std.com (1997-07-18)
Re: re-entrant parsers, pure_parser, bison, flex 71511.3711@CompuServe.COM (Brian W. Inglis) (1997-07-21)
Re: re-entrant parsers, pure_parser, bison, flex bear@sonic.net (Ray Dillinger) (1997-07-22)
Re: re-entrant parsers, pure_parser, bison, flex vetter@cc.gatech.edu (Jeffrey Vetter) (1997-07-22)
Re: re-entrant parsers, pure_parser, bison, flex jlilley@empathy.com (John Lilley) (1997-08-24)
| List of all articles for this month |

From: Ray Dillinger <bear@sonic.net>
Newsgroups: comp.compilers
Date: 22 Jul 1997 20:58:57 -0400
Organization: Cognitive Dissidents
References: 97-07-063
Keywords: parse

Well, as it turns out the original poster was asking about a parsing
technique that has good time-sharing/interrupt driven characteristics.


I seem to remember seeing a C compiler in one of my college textbooks
that was interrupt-driven -- basically the characters were delivered
by a port, with an interrupt, and the interrupt handler updated the
token being built by adding one character to the current buffer,
checking the buffer to see whether it had become an invalid token, and
then, if it had, it would submit a token (the previous contents of the
buffer) to the compiler via a named pipe -- which would generate
another interrupt, and the compiler would then handle it with a
routine that updated the compiler's state by as much as it could get
out of a single token.


The purpose of this odd organization was to separate the work of
parsing and compiling into separate threads, thus to take advantage of
multiprocessing if it was available. It was rare that one chunk of
compilation could run without a mutex released by the immediately
previous chunk, but the compilation and parsing at least, could
*always* run at the same time in separate threads. And it turned out
that there were separate passes of compilation that could also run
concurrently, with pass one on a given chunk of code cascading on to
pass two, etc.


It's not, in theory, a particularly difficult organization for a
compiler -- but it surely doesn't sound like lex and yacc. (or flex
and bison, for that matter).


Bear
--


Post a followup to this message

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