<html>
https://i.postimg.cc/GhC1955j/assignments-thumb.jpg
<br>
[Custom Thumbnail]<br>
All the Code of the series can be found at the <strong>Github repository</strong>:
https://github.com/drifter1/compiler
<hr>
<h1>Introduction</h1> Hello it's a me again @drifter1! Today we continue with my <strong>Compiler Series</strong>, a series where we implement a complete compiler for a simple C-like language by using the C-tools Flex and Bison. In this article we will write the needed Action Rules for Assignments and Simple Statements. These cases are pretty simple, but an article is still worth it :P
<h2>More specifically, the topics that we will cover today are:</h2>
<ol>
<li>Action rules for simple statements</li>
<li>Action rules for assignments</li>
<li>Running the compiler</li>
</ol>
<h2>Requirements:</h2> Actually <strong>you need to read and understand all the topics that I covered in the series as a whole</strong>, as these articles will give you access to knowledge about:<ul>
<li>What Compiler Design is (mainly the steps)</li>
<li>For which exact Language the Compiler is build for (Tokens and Grammar)</li>
<li>How to use Flex and Bison</li>
<li>How to implement a lexer and parser for the language using those tools</li>
<li>What the Symbol Table is and how we implement it</li>
<li>How we combine Flex and Bison together</li>
<li>How we can pass information from the Lexer to the Parser</li>
<li>How we define operator priorities, precedencies and associativity</li>
<li>What Semantic Analysis is (Attributes, SDT etc.)</li>
<li>How we do the so called "Scope Resolution"</li>
<li>How we declare types and check the type inter-compatibility for different cases, including function parameters</li>
<li>How we check function calls later on using a "Revisit queue", as function declarations mostly happen after functions get used (in our Language)</li>
<li>Intermediate Code Representations, including AST's</li>
<li>How we implement an AST (structure and management)</li>
<li>Action Rules for other cases</li>
</ul>
<h2>Difficulty:</h2>Talking about the <strong>series in general</strong> this series can be rated:
<ul><li>Intermediate to Advanced</li></ul>
<strong>Today's topic(s)</strong> can be rated:
<ul><li>Easy</li></ul>
So, without further ado, let's now finally start with the actual Tutorial...
<hr>
<h1>Actual Tutorial Content</h1> In today's we finally start getting into statements. To get more specific, our language has the following statements:<br>
https://i.postimg.cc/rsNBW5np/statements.png
<br><br>
As you might have already guessed the previous article about expressions is quite important, as expressions are used in most of the types of statements! In general, for all these types of statements we only have to include the following token definition in the parser:<br><br>
<code>%type <node> statement assigment</code><br><br>
That's because both the statement and assignment rule are represented by AST nodes. So, let's start with the simple statements on the right!
<h2>Action Rules for Simple Statements</h2> By "simple" I refer to the two simple statements of continue and break, and to the statement form of increment/decrement. Let's start out with the second one!
<h3>Increment/Decrement statement</h3> We already saw the increment/decrement stuff in our expressions article! And so we can easily copy-paste that code and use it for the statements too! So, the statement rule at first contains:<br>
<pre><code>statement:<br>
... other sub-rules ...<br>
| ID INCR SEMI
{
/* increment */
if($2.ival == INC){
$$ = new_ast_incr_node($1, 0, 0);
}
else{
$$ = new_ast_incr_node($1, 1, 0);
}
ast_traversal($$); /* just for testing */
}
| INCR ID SEMI
{
/* increment */
if($1.ival == INC){
$$ = new_ast_incr_node($2, 0, 1);
}
else{
$$ = new_ast_incr_node($2, 1, 1);
}
ast_traversal($$); /* just for testing */
}
;</code></pre>
<h3>Continue and break</h3>
The other two types of statements: "continue" and "break" are both represented by an <strong>AST Simple Node</strong>, by only having a difference in the variable <strong>"statement_type"</strong>, where <strong>'0' represents the "continue", whilst '1' represents the "break" statement</strong>. A simple <strong>visualization</strong> of that looks as following:<br>
https://i.postimg.cc/KjbXR05V/simple.png
<br><br>
Having a function that creates such a node, we just have to <strong>pass the correct parameter to "new_ast_simple_node"</strong>, depending on the statement type. This newly created node of course get's passed over to the statement rule. So, in code the <strong>statement rule</strong> now contains the following action rules:<br>
<pre><code>statement:<br>
... other sub-rules ...<br>
| CONTINUE SEMI
{
$$ = new_ast_simple_node(0);
ast_traversal($$); /* just for testing */
}
| BREAK SEMI
{
$$ = new_ast_simple_node(1);
ast_traversal($$); /* just for testing */
}<br>
... other sub-rules ...<br>
;</code></pre>
<hr>
<h2>Action Rules for Assignments</h2> The assignment rule is the more complicated one of today's statements. A <strong>visualization</strong> of that rule looks as following:<br>
https://i.postimg.cc/DZLkv91L/assignment.png
<br><br>
The left part has been managed last time in expressions and so the var_ref node already contains the two things: "symbol table entry" and "reference type". The right part is an expression that will be simply passed as the "assign_val" node entry of the AST Assign Node. Right now, this Node only stores an ST entry and the assign value, but we also have to be able to store the reference type. That's why we will <strong>create a new entry called "ref"</strong> (to stay with the naming of the Reference Node). Doing that we now have the following <strong>changes in the ast.h and ast.c files</strong>, as we also have to tweak the creation function:<br>
<pre><code><strong>ast.h</strong><br>
...<br>
typedef struct AST_Node_Assign{
enum Node_Type type; // node type<br>
// symbol table entry
list_t *entry;<br>
// reference or not
int ref; // 0: not reference, 1: reference<br>
// assignment value
struct AST_Node *assign_val;
}AST_Node_Assign;
...<br>
AST_Node *new_ast_assign_node(list_t *entry, int ref, AST_Node *assign_val);<br>
...<br>
-----------------------------------------------------------------<br>
<strong>ast.c</strong><br>
...<br>
AST_Node *new_ast_assign_node(list_t *entry, int ref, AST_Node *assign_val){
// allocate memory
AST_Node_Assign *v = malloc (sizeof (AST_Node_Assign));<br>
// set entries
v->type = ASSIGN_NODE;
v->entry = entry;
v->ref = ref;
v->assign_val = assign_val;<br>
// return type-casted result
return (struct AST_Node *) v;
}<br>
...</code></pre>
<br>
We can now easily write the needed action code in the <strong>assignment rule</strong>:<br>
<pre><code>assigment: var_ref ASSIGN expression
{
AST_Node_Ref *temp = (AST_Node_Ref*) $1;
$$ = new_ast_assign_node(temp->entry, temp->ref, $3);
}
;</code></pre>
<br>
In the <strong>statement rule</strong> we simply have to pass the node from the assignment over to the statement rule:
<pre><code>statement:<br>
... other sub-rules ...<br>
| assigment SEMI
{
$$ = $1; /* just pass information */
ast_traversal($$); /* just for testing */
}<br>
... other sub-rules ...<br>
;</code></pre>
<hr>
<h2>Running the compiler</h2> Running the compiler for the "full_example" we now get informed about the occurrences of simple statements and assignments! Some parts of the <strong>console messages</strong> look as following:<br>
https://i.postimg.cc/CLFT065n/console1.jpg
<br><br>
https://i.postimg.cc/2jdRPfkf/console2.jpg
<br><br>
I think we got to a very interesting point now! Next up are the more complicated statements if-else, for and while. I can already see them in the console :P Function calls will be done after function declarations, so that we can also do stuff around the revisit queue! Of course we also never really checked the semantics in these action rules. Right now we are only passing information between the different terminals and non-terminals of the grammar!
<hr>
<h2>RESOURCES</h2>
<h3>References:</h3>
No references, just using code that I implemented in my previous articles.
<h3>Images:</h3>
All of the images are custom-made!
<hr>
<h2>Previous parts of the series</h2>
<ul >
<li><a href="https://steemit.com/programming/@drifter1/writing-a-simple-compiler-on-my-own-introduction">Introduction</a> -> What is a compiler, what you have to know and what you will learn</li>
<li><a href="https://steemit.com/programming/@drifter1/writing-a-simple-compiler-on-my-own-a-simple-c-language">A simple C Language</a> -> Simplified C, comparison with C, tokens, basic structure</li>
<li><a href="https://steemit.com/programming/@drifter1/writing-a-simple-compiler-on-my-own-lexical-analysis-using-flex">Lexical Analysis using Flex</a> -> Theory, Regular Expressions, Flex, Lexer</li>
<li><a href="https://steemit.com/programming/@drifter1/writing-a-simple-compiler-on-my-own-symbol-table-basic-structure">Symbol Table (basic structure)</a> ->Why Symbol Tables, Basic Implementation</li>
<li><a href="https://steemit.com/programming/@drifter1/writing-a-simple-compiler-on-my-own-using-symbol-tables-in-the-lexer">Using Symbol Table in the Lexer</a> -> Flex and Symbol Table combination</li>
<li><a href="https://steemit.com/programming/@drifter1/writing-a-simple-compiler-on-my-own-syntax-analysis-theory">Syntax Analysis Theory</a> -> Syntax Analysis, grammar types and parsing</li>
<li><a href="https://steemit.com/programming/@drifter1/writing-a-simple-compiler-on-my-own-bison-basics">Bison basics</a> -> Bison tutorial actually</li>
<li><a href="https://steemit.com/programming/@drifter1/writing-a-simple-compiler-on-my-own-creating-a-grammar-for-our-language">Creating a grammar for our Language</a> -> Grammar and first Parser</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-combine-flex-and-bison">Combine Flex and Bison</a> -> lexer and parser combined</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-passing-information-from-lexer-to-parser">Passing information from Lexer to Parser</a> -> Bug Fix, yylval variable, YYSTYPE union, Setting up the Parser, Passing information "directly" and through the symbol table (special case) with examples.</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-finishing-off-the-grammer-parser-part-1">Finishing Off The Grammar/Parser (part 1)</a> -> Adding the missing grammar rules, small fixes</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-finishing-off-the-grammar-parser-part-2-c-flex-bison">Finishing Off The Grammar/Parser (part 2)</a> -> Operator priorities, precedencies and associativity, complete example file (for testing), grammar rule visualization, finish off grammar/parser</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-semantic-analysis-theory-c-flex-bison">Semantic Analysis Theory</a> -> What is Semantic Analysis about, CSG and CSL, Attribute Grammars, Syntax Directed Translations (SDT)</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-semantics-examples-c-flex-bison">Semantics Examples</a> -> Visualization of Semantics for different rules/cases, needed attributes, what we have to implement from now on</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own---scope-resolution-using-the-symbol-table-cflexbison">Scope Resolution using the Symbol Table</a> -> What we have now, scope resolution, integration, compiler output </li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-type-declaration-and-checking-c-flex-bison">Type Declaration and Checking</a> -> Type declaration and type checking code, "simple" code integration</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-function-semantics-part-1-c-flex-bison">Function Semantics (part 1)</a> -> Code for parameter definitions, function declarations and parameter compatibility checking</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-function-semantics-part-2-c-flex-bison">Function Semantics (part 2)</a> -> Revisit queue concept, basic implementation, inserting undeclared identifiers</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-abstract-syntax-tree-principle-c-flex-bison">Abstract Syntax Tree Principle</a> -> Intermediate code generation and representations, how to design an AST</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-abstract-syntax-tree-structure-c-flex-bison">Abstract Syntax Tree Structure</a> -> Node, operator and value types, AST node structures, some management functions, integration with the rest of the compiler</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-abstract-syntax-tree-management-c-flex-bison">Abstract Syntax Tree Management</a> -> Tweaking Nodes, Node creation and AST traversal functions, "manual" testing of the AST</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-action-rules-for-declarations-and-initializations-c-flex-bison">Action Rules for Declarations and Initializations</a> -> Replacing many values with a Value union, Other smaller changes, Action rules for declarations, Action rules for initializations</li>
<li><a href="https://steemit.com/utopian-io/@drifter1/writing-a-simple-compiler-on-my-own-action-rules-for-expressions-c-flex-bison">Action Rules for Expressions</a> -> Separating operator tokens, Action rules for expressions, running the compiler </li>
</ul>
<hr>
<h2>Final words | Next up on the project</h2> And this is actually it for today's post! I hope that I explained everything as much as I needed to, meaning that you learned something out of it.<br>
Next up on this series are:
<ul>
<li>Semantic analysis (using more action rules in Bison)</li>
<li>Intermediate Code generation (using the AST structure for more cases)</li>
<li>Machine Code generation (MIPS Assembly)</li>
</ul>
Which are all topics that will need more than one article to complete. Also, note that we might also get into Optimizations later on, or could even extend the Language by adding complex datatypes (structs and unions), more rules etc.<br>
So, see ya next time!
<hr>
<h2>GitHub Account:</h2>
https://github.com/drifter1<br>
https://steemitimages.com/0x0/https://media.giphy.com/media/ybITzMzIyabIs/giphy.gif
<br>
Keep on drifting! ;)
</html>