Re: Help with systemverilog grammar

[Hans Aberg]

At 12:06 -0800 2005/02/18, Soumitra Kumar wrote:
>I am willing to write a parser for systemverilog.
>Following is the LRM.
>http://www.eda.org/sv/SystemVerilog_3.1a.pdf
>
>I am looking for some advice.
>
>. Should I take the bnf as it is and start resolving
>the conflicts, or rewrite the rules myself.

This depends on the language. There are two major hurdles: One is that the
BNF of languages usually do not tell the whole story, but the language also
has some context information that dictates the use of the grammar. For
example, the language may admit one to define new symbols. In this case, one
would put the new symbols on a lookup table which the lexer reads, and
returns the grammar. Another problem is that the lexer always reads just one
token ahead, and that the parser that Bison generates is LALR(1), which is a
limited set of CFG grammars. Then one can either attempt to rewrite the
grammar, sometimes tweak the lexer, or use the GLR. I usually suggest one to
be conservative on the last one, because GLR cannot help a faulty grammar.
And recurive rules should normally be left recursive (see the Bison manual):
  A: x | A y
so as to prevent the parser stack from growing.

>. In case of reduce/reduce conflicts, multiple rules
>have the same lookahead symbol. If this non-terminal
>is used in multiple rules, it becomes difficult to
>identify which rule is the culprit for a particular
>lookahead symbol. Is there a way in bison to know this
>information.

Turn on the --verbose option, to get a .output file with a description of
the state machine that Bison generates (which runs the parser).

>. Is there a hacking/design document for bison?

Akim Demaille posted a bi.pdf in this list:
  Date: 10 Jan 2002 11:32:03 +0100
List-Archive: <http://lists.gnu.org/pipermail/help-bison>

  Hans Aberg