This file contains variious functions, called from parser.y , that are used to create an AST (Abstract Syntax Tree) of data for further processing. The information below assumes the user has basic knowledge of Flex and Bison.
Near the beginning of the file, there are options for turning debug printing on or off by defining or not defining options like DEBUG_NODES. Currently this debugging is not used anywhere in the file but may be useful in the future.
Much of this file relies on the struct exp_tree * data type which is defined in kpuasm.h as follows:
Besides various int, long and char* data types, notice that it contains struc t exp_tree * data types in order to create a linked list or tree structure. struc t exp_tree *lh_node represents a pointer to a Left Hand node. There's also a Right Hand node (struc t exp_tree *rh_node) as well as two extra ones called x1_node and x2_node that are used for certain functions/tree creation. Typically there's a Left Hand node.
In all of the node_ functions, notice that memory is allocated for the node by using function AllocExp(). Then various data is saved in this allocated memory depending on the parameters pased to node_assign()
Notice the node_assign() function uses both a Left and Right Hand node pointer.
The lh_node points to a node containing info about the unary_expression and therh_node points to a node containing info about an assignment_expression. Look back at parser.y and find the call to node_assign().
$1 corresponds to unary_expression, $2 to assignment_operator and $3 to assignment_expression.
As more C functionality is added to parser.y, more node functions will need to be added to node_functions.c. In doing this, other files will need to be updated too.
kcc.h has a long list of function prototypes that will need to be updated.
File gencode.c contains the gen_code() function that will need to have code for a corresponding NODE_ switch statement.
gencode.c also contains a print_src() function that will need to be updated. print_src() is a good debugging function to see that we can reprint the C source after it has all been parsed.
Let's now run the kcc.exe executable and see what debugging of this module may look like. For this example we use a file called test1.c which contains the following:
Next run kcc in the Cygwin shell.
Notice all of the node_ statements printed out before "Starting Pass 1" ever occurs. Also notice the :begin and :end for each node_ that is called in node_functions.c. Finally, before the "Starting Pass 1", print_src: reconstructs the entire program that has been parsed as well as making comments such as "// Block #1" which will be explained later.
Debugging in this manner can let you know how parser.y is working.
Since node_functions.c is only used by parser.y to build the AST tree, we now look at what parser.y does when it has finished parsing. In the info grammer, for translation_unit it calls gen_parsed($1), where $1 is the link to the root of the AST. The gen_parsed() function is in gencode.c which is where processing of the AST takes place in order to produce CPU machine code.