% !TEX program = xelatex

\documentclass{article}

\usepackage{../style}

\usepackage{../langs}

\usepackage{../grammar}

\usepackage{../graphics}

%% add safety check on references...whether it is above 0 and below the 

%% index

\begin{document}

\section*{Handout 7 (Compilation)}

The purpose of a compiler is to transform a program a human can read and

write into code the machine can run as fast as possible. The fastest

code would be machine code the CPU can run directly, but it is often

good enough for improving the speed of a program to target a

virtual machine. This produces not the fastest possible code, but code

that is often pretty fast. This way of producing code has the advantage that

the virtual machine takes care of things a compiler would normally need

to take care of (like explicit memory management). 

As a first example in this module we will implement a compiler for the

\begin{itemize}

  \item \url{http://jasmin.sourceforge.net}

  \item \url{https://github.com/Storyyeller/Krakatau}

\end{itemize}

\noindent

The first is a Java program and the second a program written in Python.

Each of them allow us to generate \emph{assembly} files that are still

readable by humans, as opposed to class-files which are pretty much just

(horrible) zeros and ones. Jasmin (respectively Krakatau) will then take

an assembly file as input and generate the corresponding class file for

us. 

Good about the JVM is that it is a stack-based virtual machine, a fact

which will make it easy to generate code for arithmetic expressions. For

example when compiling the expression $1 + 2$ we need to generate the

following three instructions

\begin{lstlisting}[language=JVMIS,numbers=none]

ldc 1

ldc 2

iadd 

\end{lstlisting}

\noindent The first instruction loads the constant $1$ onto

the stack, the next one loads $2$, the third instruction adds both

numbers together replacing the top two elements of the stack

with the result $3$. For simplicity, we will throughout

consider only integer numbers. Therefore we can

use the JVM instructions \code{iadd}, \code{isub},

\code{imul}, \code{idiv} and so on. The \code{i} stands for

integer instructions in the JVM (alternatives are \code{d} for

doubles, \code{l} for longs and \code{f} for floats).

Recall our grammar for arithmetic expressions (\meta{E} is the

starting symbol):

\begin{plstx}[rhs style=, margin=3cm]

: \meta{E} ::= \meta{T} $+$ \meta{E}

         | \meta{T} $-$ \meta{E}

         | \meta{T}\\

: \meta{T} ::= \meta{F} $*$ \meta{T}

          | \meta{F} $\backslash$ \meta{T}

          | \meta{F}\\

: \meta{F} ::= ( \meta{E} )

          | \meta{Id}

          | \meta{Num}\\

\end{plstx}

\noindent where \meta{Id} stands for variables and \meta{Num}

for numbers. For the moment let us omit variables from arithmetic

expressions. Our parser will take this grammar and given an input

produce abstract syntax trees. For example we will obtain for the

expression $1 + ((2 * 3) + (4 - 3))$ the following tree.

\begin{center}

\begin{tikzpicture}

\Tree [.$+$ [.$1$ ] [.$+$ [.$*$ $2$ $3$ ] [.$-$ $4$ $3$ ]]]

\end{tikzpicture}

\end{center}

\begin{lstlisting}[language=JVMIS,numbers=none]

ldc 1 

ldc 2 

ldc 3 

imul 

ldc 4 

ldc 3 

isub 

iadd 

iadd

\end{lstlisting}

\noindent If we ``run'' these instructions, the result $8$ will be on

top of the stack (I leave this to you to verify; the meaning of each

instruction should be clear). The result being on the top of the stack

will be an important convention we always observe in our compiler. Note,

that a different bracketing of the expression, for example $(1 + (2 *

3)) + (4 - 3)$, produces a different abstract syntax tree and thus also

a different list of instructions. Generating code in this

post-order-traversal fashion is rather easy to implement: it can be done

with the following recursive \textit{compile}-function, which takes the

\begin{center}

\begin{tabular}{lcl}

$\textit{compile}(n)$ & $\dn$ & $\pcode{ldc}\; n$\\

$\textit{compile}(a_1 + a_2)$ & $\dn$ &

$\textit{compile}(a_1) \;@\;\textit{compile}(a_2)\;@\; \pcode{iadd}$\\

$\textit{compile}(a_1 - a_2)$ & $\dn$ & 

$\textit{compile}(a_1) \;@\; \textit{compile}(a_2)\;@\; \pcode{isub}$\\

$\textit{compile}(a_1 * a_2)$ & $\dn$ & 

$\textit{compile}(a_1) \;@\; \textit{compile}(a_2)\;@\; \pcode{imul}$\\

$\textit{compile}(a_1 \backslash a_2)$ & $\dn$ & 

$\textit{compile}(a_1) \;@\; \textit{compile}(a_2)\;@\; \pcode{idiv}$\\

\end{tabular}

\end{center}

\begin{lstlisting}[language=JVMIS,mathescape,numbers=none]

iload $index$

\end{lstlisting}

\noindent 

which places the content of the local variable $index$ onto 

the stack. Storing the top of the stack into a local variable 

can be done by the instruction

\begin{lstlisting}[language=JVMIS,mathescape,numbers=none]

istore $index$

\end{lstlisting}

\begin{center}

\begin{tabular}{lcl}

$\textit{compile}(n, E)$ & $\dn$ & $\pcode{ldc}\;n$\\

$\textit{compile}(a_1 + a_2, E)$ & $\dn$ & 

$\textit{compile}(a_1, E) \;@\;\textit{compile}(a_2, E)\;@\; \pcode{iadd}$\\

$\textit{compile}(a_1 - a_2, E)$ & $\dn$ &

$\textit{compile}(a_1, E) \;@\; \textit{compile}(a_2, E)\;@\; \pcode{isub}$\\

$\textit{compile}(a_1 * a_2, E)$ & $\dn$ &

$\textit{compile}(a_1, E) \;@\; \textit{compile}(a_2, E)\;@\; \pcode{imul}$\\

$\textit{compile}(a_1 \backslash a_2, E)$ & $\dn$ & 

$\textit{compile}(a_1, E) \;@\; \textit{compile}(a_2, E)\;@\; \pcode{idiv}$\\

$\textit{compile}(x, E)$ & $\dn$ & $\pcode{iload}\;E(x)$\\

\end{tabular}

\end{center}

There is a similar \textit{compile}-function for boolean

expressions, but it includes a ``trick'' to do with

\pcode{if}- and \pcode{while}-statements. To explain the issue

let us first describe the compilation of statements of the

we do not have to generate any instruction

\begin{center}

\begin{tabular}{lcl}

$\textit{compile}(\pcode{skip}, E)$ & $\dn$ & $([], E)$\\

\end{tabular}

\end{center}

\noindent whereby $[]$ is the empty list of instructions. Note that

the \textit{compile}-function for statements returns a pair, a

list of instructions (in this case the empty list) and an

environment for variables. The reason for the environment is

environment---clearly if a variable is used for the first

time, we need to allocate a new index and if it has been used

before, then we need to be able to retrieve the associated index.

This is reflected in the clause for compiling assignments, say

$\textit{x := a}$:

\begin{center}

\begin{tabular}{lcl}

$\textit{compile}(x := a, E)$ & $\dn$ & 

$(\textit{compile}(a, E) \;@\;\pcode{istore}\;index, E')$

\end{tabular}

\end{center}

\begin{lstlisting}[language=JVMIS,mathescape,numbers=none]

iload $n_x$

ldc 1

iadd

istore $n_x$

\end{lstlisting}

\noindent 

where $n_x$ is the index (or pointer to the memory) for the variable

$x$. The code for looking-up the index for the variable is as follow:

\begin{center}

\begin{tabular}{lcl}

$index \;=\; E\textit{.getOrElse}(x, |E|)$

\end{tabular}

\end{center}

\noindent

A bit more complicated is the generation of code for

\pcode{if}-statements, say

\begin{lstlisting}[mathescape,language={},numbers=none]

if $b$ then $cs_1$ else $cs_2$

\end{lstlisting}

\noindent where $b$ is a boolean expression and where both $cs_{1/2}$

\begin{center}

 point/.style={rectangle, inner sep=0mm, minimum size=0mm, fill=red},

 skip loop/.style={black, line width=1mm, to path={-- ++(0,-10mm) -| (\tikztotarget)}}]

\node (A1) [point] {};

\node (b) [block, right=of A1] {code of $b$};

\node (A2) [point, right=of b] {};

\node (cs1) [block, right=of A2] {code of $cs_1$};

\node (A3) [point, right=of cs1] {};

\node (cs2) [block, right=of A3] {code of $cs_2$};

\node (A4) [point, right=of cs2] {};

\draw (A1) edge [->, black, line width=1mm] (b);

\draw (b) edge [->, black, line width=1mm] (cs1);

\draw (A3) edge [->, black, skip loop] (A4);

\node [below=of cs2] {\raisebox{-5mm}{\small{}jump}};

\end{tikzpicture}

\end{center}

\noindent where we start with running the code for $b$; since

we are in the true case we continue with running the code for

$cs_1$. After this however, we must not run the code for

(the code for the \pcode{else}-branch). Note that this jump is

unconditional, meaning we always have to jump to the end of

$cs_2$. The corresponding instruction of the JVM is

\pcode{goto}. In case $b$ turns out to be false we need the

control-flow

\begin{center}

 point/.style={rectangle, inner sep=0mm, minimum size=0mm, fill=red},

 skip loop/.style={black, line width=1mm, to path={-- ++(0,-10mm) -| (\tikztotarget)}}]

\node (A1) [point] {};

\node (b) [block, right=of A1] {code of $b$};

\node (A2) [point, right=of b] {};

\node (cs1) [block, right=of A2] {code of $cs_1$};

\node (A3) [point, right=of cs1] {};

\node (cs2) [block, right=of A3] {code of $cs_2$};

\node (A4) [point, right=of cs2] {};

\draw (A1) edge [->, black, line width=1mm] (b);

\draw (A2) edge [skip loop] (A3);

\draw (A3) edge [->, black, line width=1mm] (cs2);

\draw (cs2) edge [->,black, line width=1mm] (A4);

\node [below=of cs1] {\raisebox{-5mm}{\small{}conditional jump}};

\end{tikzpicture}

\end{center}

\noindent where we now need a conditional jump (if the

if-condition is false) from the end of the code for the 

boolean to the beginning of the instructions $cs_2$. Once we 

are finished with running $cs_2$ we can continue with whatever

code comes after the if-statement.

The \pcode{goto} and the conditional jumps need addresses to

where the jump should go. Since we are generating assembly

code for the JVM, we do not actually have to give (numeric)

addresses, but can just attach (symbolic) labels to our code.

These labels specify a target for a jump. Therefore the labels

need to be unique, as otherwise it would be ambiguous where a

jump should go to. A label, say \pcode{L}, is attached to code

like

\begin{lstlisting}[mathescape,numbers=none]

L:

  $instr_1$

  $instr_2$

    $\vdots$

\end{lstlisting}

or 20 instructions backwards.

Recall the ``trick'' with compiling boolean expressions: the 

\textit{compile}-function for boolean expressions takes three

arguments: an abstract syntax tree, an environment for 

variable indices and also the label, $lab$, to where an conditional 

jump needs to go. The clause for the expression $a_1 = a_2$, 

for example, is as follows:

\begin{center}

\begin{tabular}{lcl}

$\textit{compile}(a_1 = a_2, E, lab)$ & $\dn$\\ 

\multicolumn{3}{l}{$\qquad\textit{compile}(a_1, E) \;@\;\textit{compile}(a_2, E)\;@\; \pcode{if_icmpne}\;lab$}

\end{tabular}

\end{center}

\noindent where we are first generating code for the

subexpressions $a_1$ and $a_2$. This will mean after running

the corresponding code there will be two integers on top of

the stack. If they are equal, we do not have to do anything

(except for popping them off from the stack) and just continue

with the next instructions (see control-flow of ifs above).

However if they are \emph{not} equal, then we need to

(conditionally) jump to the label $lab$. This can be done with

the instruction

\begin{lstlisting}[mathescape,numbers=none,language=JVMIS]

if_icmpne $lab$

\end{lstlisting}

\begin{center}

\begin{tabular}{l@{\hspace{10mm}}c@{\hspace{10mm}}l}

$\not=$ & $\Rightarrow$ & \pcode{if_icmpeq}\\

$<$ & $\Rightarrow$ & \pcode{if_icmpge}\\

$\le$ & $\Rightarrow$ & \pcode{if_icmpgt}\\

\end{tabular}

\end{center}

source of some nasty, hard-to-detect errors), you can also change the

layout of the code and first give the code for the else-branch and then

for the if-branch. However in the case of while-loops this

``upside-down-inside-out'' way of generating code still seems the most

convenient.

We are now ready to give the compile function for 

if-statements---remember this function returns for statements a 

pair consisting of the code and an environment:

\begin{center}

\begin{tabular}{lcl}

$\textit{compile}(\pcode{if}\;b\;\pcode{then}\; cs_1\;\pcode{else}\; cs_2, E)$ & $\dn$\\ 

\multicolumn{3}{l}{$\qquad L_\textit{ifelse}\;$ (fresh label)}\\

\multicolumn{3}{l}{$\qquad L_\textit{ifend}\;$ (fresh label)}\\

\multicolumn{3}{l}{$\qquad (is_1, E') = \textit{compile}(cs_1, E)$}\\

\multicolumn{3}{l}{$\qquad (is_2, E'') = \textit{compile}(cs_2, E')$}\\

\multicolumn{3}{l}{$\qquad(\textit{compile}(b, E, L_\textit{ifelse})$}\\

\multicolumn{3}{l}{$\qquad\phantom{(}@\;is_1$}\\

\multicolumn{3}{l}{$\qquad\phantom{(}@\; \pcode{goto}\;L_\textit{ifend}$}\\

\multicolumn{3}{l}{$\qquad\phantom{(}@\;L_\textit{ifelse}:$}\\

\multicolumn{3}{l}{$\qquad\phantom{(}@\;is_2$}\\

\multicolumn{3}{l}{$\qquad\phantom{(}@\;L_\textit{ifend}:, E'')$}\\

\end{tabular}

\end{center}

\noindent In the first two lines we generate two fresh labels

for the jump addresses (just before the else-branch and just

after). In the next two lines we generate the instructions for

the two branches, $is_1$ and $is_2$. The final code will

be first the code for $b$ (including the label 

just-before-the-else-branch), then the \pcode{goto} for after

the else-branch, the label $L_\textit{ifesle}$, followed by

the instructions for the else-branch, followed by the 

after-the-else-branch label. Consider for example the 

if-statement:

\begin{lstlisting}[mathescape,numbers=none,language=While]

if 1 = 1 then x := 2 else y := 3

\end{lstlisting}

\noindent 

The generated code is as follows:

\begin{lstlisting}[language=JVMIS,mathescape,numbers=left]

   ldc 1

   ldc 1

   if_icmpne L_ifelse $\quad\tikz[remember picture] \node (C) {\mbox{}};$

   ldc 2

   istore 0

   goto L_ifend $\quad\tikz[remember picture] \node (A) {\mbox{}};$

L_ifelse: $\quad\tikz[remember picture] \node[] (D) {\mbox{}};$