Parser Generator Software suitable for embedded use ?
Anton Erasmus
I have been looking for software that makes it easier to generate
parsing software. I have been looking at Anagram from
http://www.parsifalsoft.com. But it seems that the company is
not doing business anymore, since all my queries have been ignored.
What other suitable software is available that can generate C code for
an event driven parser ? It should be able to generate code that does
not rely on the existance of a standard C library. The code should
also be re-entrant. It would also be a bonus if one can test the
parser on input streams withput actually having to generate the code
and run it on the target.
Anagram seems to fulfil all these requirements, except that I have
been unable to purchase it.
I am a complete novice when it comes to formal parsing terminology,
hence tools such as Lexx and Bison I find very difficult to use. I
also do not think they are suitable to generate parsing code that will
run on a small 8 bit micro.
The application is to generate a parser that can parse the response
from a GSM modem module.
Regards
Anton Erasmus
Kelly Hall
"Anton Erasmus" <ju...@junk.net> wrote in message
news:9474bvk00jho1ftnd...@4ax.com...
> What other suitable software is available that can generate C code for
> an event driven parser ? It should be able to generate code that does
> not rely on the existance of a standard C library. The code should
> also be re-entrant. It would also be a bonus if one can test the
> parser on input streams withput actually having to generate the code
> and run it on the target.
For embedded systems, I believe the best parser generator is a human being.
> I am a complete novice when it comes to formal parsing terminology,
> hence tools such as Lexx and Bison I find very difficult to use. I
> also do not think they are suitable to generate parsing code that will
> run on a small 8 bit micro.
lex and yacc and their derivatives were designed to solve the problem that
compilers are hard to write. Looking at the command-line switches for bison
and lex ought to strong evidence that these tools were never meant to
generate code for resource-scarce environments.
> The application is to generate a parser that can parse the response
> from a GSM modem module.
I admit that I've never dealt with GSM modems. Just how elaborate can their
response language be? If you make a flowchart for how to talk with this
thing would it have more than 20 states? 50?
Kelly
CBFalconer
>
> I have been looking for software that makes it easier to generate
> parsing software. I have been looking at Anagram from
> http://www.parsifalsoft.com. But it seems that the company is
> not doing business anymore, since all my queries have been ignored.
I haven't used it, but I suspect this may do the trick:
<http://www.devincook.com/goldparser>
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Robert Kaiser
Anton Erasmus <ju...@junk.net> writes:
>
> I am a complete novice when it comes to formal parsing terminology,
> hence tools such as Lexx and Bison I find very difficult to use. I
> also do not think they are suitable to generate parsing code that will
> run on a small 8 bit micro.
I did once use bison as an expression parser for an OS-less system
(a monitor program). I had expected a lot of C library dependencies
from the bison-generated code, but it turned out to be not bad at all
(basically just putc()/getc(), which are easy to substitute). However
that was a 32-bit platform.
Learning how to use bison/flex (or yacc/lex, for that matter) can be a bit
steep, especially since there are only few good hands-on tutorials.
Rob
--
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO AG http://www.elinos.com
Klein-Winternheim / Germany http://www.sysgo.de
Mark Piffer
wrote:
>lex and yacc and their derivatives were designed to solve the problem that
>compilers are hard to write. Looking at the command-line switches for bison
>and lex ought to strong evidence that these tools were never meant to
>generate code for resource-scarce environments.
>
>Kelly
I think that at least for the (f)lex case there is hardly any problem
to be expected: the transition tables are by definition ROM and the
RAM consumption for a scanner is O(1). Runtime performance may be a
problem but even there a human can only change the constant of the
underlying O(1) algorithm. If you are not targeting for some
super-simple language with a 10-lines scanner, a standard-tool
solution surely has some benefits (software engineering)
Mark
--
Mark Piffer
MCU and DSP programming & software design
For replying please read the address and do what a human can do but a spambot not:
mark....@chello.deletethis.at (Sorry for the inconvenience!)
Kelly Hall
"Mark Piffer" <mark....@chello.at> wrote in message
news:3eb2e2ca...@news.chello.at...
> I think that at least for the (f)lex case there is hardly any problem
> to be expected: the transition tables are by definition ROM and the
> RAM consumption for a scanner is O(1).
The problem isn't the runtime, it's the size of the tables.
> If you are not targeting for some
> super-simple language with a 10-lines scanner, a standard-tool
> solution surely has some benefits (software engineering)
I love the tools, but I rarely have the performance requirement coupled with
oodles of spare code space.
There's often a tradeoff between runtime speed and code space. There's
often a tradeoff between the time needed to code it yourself and the cost
and benefits of using a tool. Everyone's project is different, and I don't
think I suggested that there's no application for lex/yacc in the realm of
computing. My experiences have led me to believe that coding up something
by hand is substantially more efficient than using the tools for small
projects. Your mileage may vary ;)
Kelly
HTD
> In article <9474bvk00jho1ftnd...@4ax.com>,
> Anton Erasmus <ju...@junk.net> writes:
> >
> > I am a complete novice when it comes to formal parsing terminology,
> > hence tools such as Lexx and Bison I find very difficult to use. I
> > also do not think they are suitable to generate parsing code that will
> > run on a small 8 bit micro.
>
> I did once use bison as an expression parser for an OS-less system
> (a monitor program). I had expected a lot of C library dependencies
> from the bison-generated code, but it turned out to be not bad at all
> (basically just putc()/getc(), which are easy to substitute). However
> that was a 32-bit platform.
>
> Learning how to use bison/flex (or yacc/lex, for that matter) can be a bit
> steep, especially since there are only few good hands-on tutorials.
>
> Rob
I once used flex to lex messages and fed the input into a state
machine driven by libero from http://www.imatix.com. As soon as the
thing worked I then went and replaced flex with a self written lexer,
keeping the state machine solution.
The application was a monitor/bootloader for a 16 bit uP. It had the
advantage that, by the time you finished debugging the appplication,
you knew what exactly what messages were going to com in so it became
a doddle to write an application specific lexer.
There are some modifications you can make to flex (config file if I
remember correctly) to reduce the space usage (there is a malloc call
in there somewhere).
Best regards
HTD