On Fri, Sep 08, 2006 at 04:48:27PM -0700, Paul Eggert wrote:
> Bob Rossi <[EMAIL PROTECTED]> writes:
>
> > The only catch, is that I compiled with -02. If you compile with out
> > optimizations it seems to be 1-2% slower, don't know why that is.
>
> That's OK. Thanks.
>
> > Actually, I thought the LALR(1) was the yacc skeleton, but apparently it
> > is its own skeleton. Does bison not test the yacc skeleton against the
> > Calculator example? If not, I don't have any nice tests to run. In this
> > case, what examples should I run the push parser against?
>
> Sorry, I don't know the answer to either question offhand. Perhaps
> you can modify the tests so that the yacc skeleton is tested against
> the calc example.
OK, I made a mistake here. The LALR(1) tests the yacc skeleton.
So, there are 3 pure tests being tested here. I'm going to add 3 push
tests to test the same functionality.
I did run into a small problem. I'm using yyparse as the function name
when you do the push parser, instead of something new like yypushparse.
Do you think I should continue to use yyparse? or should I add a new
function yypushparse that is generated when %push-parser is specified?
Here is the trouble I've run into. There is an option like this in
the testsuite:
%parse-param {semantic_value *result} %parse-param {int *count}
When that is done, apparently bison generates yyparse like this:
int yyparse (semantic_value *result, int *count);
However, the push parser defines yyparse like this:
void yyparse (void *PVVOID);
So, I end up getting a compiler error when %push-parser and
%parse-param are used together.
- Does it make sense to use these options together? (I don't know what
%parse-param is used for)
- Should I generate a yypushparse function instead to avoid this
problem?
- Should I make the push-parser handle those extra parameters when
%parse-param is used? (ie)
void yyparse (void *PVVOID, semantic_value *result, int *count);
Thanks,
Bob Rossi
