Re: [avr-gcc-list] Using lex/flex with avr-gcc

[Joerg Wunsch]

As "Anton Erasmus" <address@hidden> wrote:

>Has anybody used lex/flex together with avr-gcc.

Yes, i recently made an experiment with it.

> I see one has to
>link with a lex library when compiling C code generated by lex.

That's not strictly necessary.  If you look a bit further, you'll notice
that libl.a just contains a default for yywrap() as well as a dummy
main().  The yywrap() default is just

int yywrap()
        {
        return 1;
        }

but it can be avoided altogether by using %option noyywrap.  The yacc
library liby.a contains a default for yyerror() and again, a dummy
main().  The yyerror() function is implemented as:

int
yyerror(msg)
char *msg;
{
        (void)fprintf(stderr, "%s\n", msg);
        return(0);
}

which again looks fairly trivial, doesn't it? :-)  Whether that's OK
to you or not depends on whether you've got a valid and useful stderr
at all.

>Is it at all feasable or does the AVR not have enough resources to
>run a lexer generated by lex/flex ?

First, the biggest problem by now is the missing realloc() function in
our library.  However :), as mentioned above, i did already some
testing, so obviously, i've got a realloc() implementation in the
pipeline (something i've intented to do for quite some time anyway).
It hasn't undergone all the required quality assurance steps though,
that's why i didn't commit it to CVS by now.  If you'd like to test
it, i can send it to you in private mail.

Second, using the defaults of flex and yacc (byacc in my case -- i
haven't looked whether bison would work, too, but i've got the feeling
that most GNU stuff is a bit worse with resource consumption for the
sake of more features) it's currently only feasible for devices with
external RAM, and perhaps not less than 16 KB of ROM.  Even a simple
lex/yacc »Hello world!«-style program initially allocates (malloc())
~17 KB of RAM for various buffers.  This can certainly be tuned, but i
didn't take a close look.  Also, since the generated state machines
make heavy use of table lookups, this will by default cost both, ROM
/and/ RAM, but then, it's pretty fast.  Perhaps, speed can be traded
for RAM space here by modifying the template files so that ROM-based
tables + LPM instructions are used, but the effort reqired for this
will certainly only buy out if your software maintenance costs are
outweighed by the costs for the additional hardware (i. e. for the PCB
with external RAM).  IOW, it probably takes a mass application as a
driving force for this.

Oh, i just notice that you're /only/ talking about lex.  I've been
testing the combination of both, so i can't tell you how each of them
individually contributes to the resource consumption.
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/