Скачать или смотреть The SEMANTIC Analysis! (Demystifying COMPILERS, lesson 4)

Section 1 (0:00)
Section 2 (0:11)
Section 3 (0:28)
Section 4 (0:46)
Section 5 (0:54): The last step before any code generation or optimization is the semantic analysis. It checks if whether or not there is a consistency on the usage of type-declarations and type-expressions;
A stream of tokens can pass through the lexical and the syntactic analysis and still not be compilable… E.g., this one here… What is the problem we have here? We declared variables x, y and z as character values, but they are assigned to integer values, returned by the nextInt() method. Notice that there is nothing wrong with the lexemes or the order in which the tokens are written, but we still have a compilation problem!
Section 6 (1:36):
All the expressions on a stream of code must have expected types. E.g.: inside an if statement, there must be a boolean expression, inside a loop condition, there also must be a boolean expression, all sub-expressions of an expression must be of the same type, and so on...
Section 7 (1:54): The code below is not correctly typed because it invokes scanner.nextInt() as an expression to x and y and these two variables were declared as char, a different type from that one returned by scanner.nextInt(). It would have passed from the syntactic analysis phase, but it is still not compilable.
For expressions where variable names are used, it is checked if their types, that were stored on the symbol table, correspond to the operators that are used on the expression.
Section 8 (2:27): (UPDATE) small correction: the grammar is LL(1) only if its root is EXPR, NOT for the root on PROGRAM... For our example, however, there was no problem...

So, let’s consider again the LL(1) version of the grammar of the subset of Java of the previous lessons, this one shown here…
Section 9 (2:37): Now, consider the following token stream
int x;
int y = 0;
x = y + 2 + 4 + “Bits em Alta Velocidade”;
We can see that there is a type error on the previous assignment on variable x. But how is it detected by the Semantic Analyzer?
Section 10 (3:00): First of all, we know that the lexical analyzer creates a symbol table for the declared variables when checking the validity of each lexeme on the token stream:
Lexeme Type Scope
x int local
y int local
Section 11 (3:19): So, what is done here is the following: the type of each sub-expression is inherited on the tree that represents the expression. If there is a combination of operator and sub-expressions that do not match the expected type, then there is a type error. Let’s see this process in practice:
So, in the case of expression y + 2 + 4 + the string “Bits em Alta Velocidade”, we can see that there is a sub-expression in which there is a string operand and an integer operand being applied to operator “plus”.
But… Operator + in Java can be used for two String operands or for two int, float or double operands, but not for a String operand and other operand of other type. Thus, in the case below, we have a type error...
We say that the + operator is an overloaded operator, because it can be applied to two String operands and to two double, float and int operands. When used with Strings, + is a concatenation, and when used with int, float or double, + is an algebraic sum between the operands.
On the other expression, now we have an integer expression. As it occur on the declarative assignment int y = 0;, then the Semantic Analyzer must see on the Symbol Table what is the type of y and check if it matches the type of the expression. In our case, it does, so there is no type error here...
Section 12 (4:51): So, let’s change our program in order to make it become correctly typed… Our changed program is the following:
int x;
int y = 0;
x = y + 2 + 4 + 7;
Why is it correctly typed? We see that operator + applied to 4 and 7 is a sum between integers, so no type error until here... It returns another integer value, and this result is the second parameter of the sum operator whose left operand is 2. Again, no type-error here…and again, an integer value is returned. The result is the second parameter of the sum operator whose left side is y, whose type is integer, as checked in the symbol table. So, again, no type error here. As the final result of this expression is an integer, then we must check on the symbol table if it matches the type of integer x. We see that it does! So, the expression is correctly typed, and compilable!
Section 13 (5:57): Now, All lexemes are valid (successfully mapped into tokens), the sequence of tokens is correct and the program is well-typed. Is the program ok to compile?
The answer is YES!! \o/
Section 14 (6:14): Thank You!


Mesmerize by Kevin MacLeod is licensed under a Creative Commons Attribution 4.0 licence. https://creativecommons.org/licenses/...

Source: http://incompetech.com/music/royalty-...

Artist: http://incompetech.com/