Related articles |
---|
flex scanner too huge, suggestions? troy@bell-labs.com (Troy Cauble) (2001-02-17) |
Re: flex scanner too huge, suggestions? tej@melbpc.org.au (Tim Josling) (2001-02-23) |
Re: flex scanner too huge, suggestions? snicol@apk.net (Scott Nicol) (2001-02-23) |
Re: flex scanner too huge, suggestions? rkrayhawk@aol.com (2001-02-23) |
Re: flex scanner too huge, suggestions? olsenc@ichips.intel.com (2001-02-25) |
Re: flex scanner too huge, suggestions? Ron@Profit-Master.com (Ron Pinkas) (2001-02-25) |
Re: flex scanner too huge, suggestions? troy@bell-labs.com (Troy Cauble) (2001-03-01) |
From: | Troy Cauble <troy@bell-labs.com> |
Newsgroups: | comp.compilers |
Date: | 17 Feb 2001 01:35:30 -0500 |
Organization: | Bell Labs, Holmdel, NJ, USA |
Keywords: | lex, practice, question |
Posted-Date: | 17 Feb 2001 01:35:29 EST |
Hi all,
I have a working flex/bison implementation to parse a text
protocol. The problem is that the scanner is huge.
Made with LFLAGS = -Cfe, size gives
42068(.text) + 24(.data) + 60(.bss) + 1687886(.rodata) = 1730038
Made with LFLAGS = -Cem, size gives
42496(.text) + 24(.data) + 60(.bss) + 508326(.rodata) = 550906
This is still pretty large for some of our target environments.
I haven't tried to disable features to determine what makes
it so huge, but the protocol is case-insensitive and context
(position) sensitive. I addressed the context sensitivity
with flex start states.
My flex file has the following %option line.
%option noyywrap 8bit batch case-insensitive perf-report
I'm looking for suggestions for either tweaking my flex
implementation or switching to another scanner generator.
The corresponding bison parser is solid, so I'm not really
looking for suggestions to replace the pair. (We initially
tried several other tools for the total parsing problem but
they all choked on this large, context sensitive protocol.)
Thanks,
-troy
Return to the
comp.compilers page.
Search the
comp.compilers archives again.