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 _______________________________________________ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
