The parse tree classes are under:
srcs/v2k/parser/treeThere are 133 .java source files there; no wonder it's taken a while.
NOTE: ANTLR does have (automatic) AST (Abstract Syntax Tree) building capability. However, I wanted to experience the very hands-on experience of crafting my own, for this project. Not to worry, there will be many more parsers, for many more DSLs to work on; and, automatic AST generation will be more efficient there.
There is a simple script
Error: Must specify at least one "infile".
Usage: v2kparse [options] infile...
-I dir Add dir (must be readable) to `include file search path.
-D name Predefine name as a macro with value 1.
-D name=defn Predefine name as a macro with value defn.
Those options are less friendly than the (more common) Verilog style options (as in
bin/analyze; see earlier blogs); but useful for testing.
bin/ptreescript to see the latter simply defines the constant
USEPT(use parse tree). This constant is detected in file
srcs/v2k/parser/Parser.javaand selects which sub-class of
public abstract class ASTreeBaseto build the tree. There are 2 sub-classes:
tree.basic.ParseTreeis used to build a simple tree which simply tracks module names and instances. That is used by the
bin/analyzescript to glean info appropriate for source file dependency tracking (described in earlier blogs.) The 2nd one:
tree.ParseTreeis used for full tree construction, as in the
So, get your hands dirty playing around with
bin/ptree. And, if you embelish the
bin/analyzescript with use of the
-DUSEPTargument to java, then you could also get a full-blown parse tree, and use the more standard Verilog command line arguments, too. However, since the analyze script also uses jruby hooks to generate usable output, by walking the
basic.ParseTree, the jruby scripts would also have to be changed (since the API of the
tree.ParseTreeis slightly different).
The next phase of the project is to add elaboration...