Re: too many gotos

[Laurence Finston]

On Wed, 13 Oct 2004, Nick Chapman wrote:

>
> The grammar is for the SystemVerilog Hardware Description Language.
> The LRM and grammar can be found at:
>
> http://www.eda.org/sv/SystemVerilog_3.1a.pdf
> http://www.eda.org/sv/SV3.1a_bnf_no_footnotes.htm
>

Thanks.  It looks very impressive.  I've only just taken a
cursory look at it, but I noticed a couple of things that,
in my opinion, might cause problems:

I noticed one case of right recursion, but there might be
more.  The Bison manual recommends always using left recursion:
http://www.gnu.org/software/bison/manual/html_node/Recursion.html#Recursion
I don't know whether this would contribute to your specific
problem, but it might.  (I know virtually nothing about
Bison's innards.)

I've found that optional items in rules, either singly or
a sequence of them, can sometimes cause
problems.  When they do, it can be difficult to understand
their effect on the generated parser (for me, at least).

I've found that it can be helpful to store the objects
representing the optional symbols in objects referenced by
pointers in the object passed to `yyparse()' as a
parameter.  It's possible to do this when generating a
reentrant parser. I often find it easier to
solve problems within the actions rather than the rules.

I sometimes do use options in the "normal" way, but I try to
remove them to their own rules, i.e., I tend to prefer _more
and simpler_ rules to _fewer and more complicated_ ones.

I also noticed that you implement loops and conditionals by
means of the rules.  I think this might cause problems.
Have you examined the descriptions of the states
corresponding to these rules in the `<filename>.output' file?
As far as conditionals are concerned, I think it's a
bit wasteful to parse the part that's not evaluated, when
one can just skip over it.  However, I don't know how your
compiler (or interpreter) is supposed to work.

In my project, I read the input for conditionals and loops
into a string.  For a loop, I just read the string in
repeatedly until a condition is met.  For a conditional, I
only read in the code for the `true' case and discard the
rest.  This is anexample of removing complication from the
grammar and putting it into the actions, where it's
generally easier to deal with.

I hope you find this helpful.  If you really need to change
the parser code, someone else will have to answer.  I
consider actually modifying Bison to be a last resort, but
some people may not agree.

Laurence