\documentclass[12pt]{book} \usepackage[T1]{fontenc} \usepackage[utf8]{inputenc} \usepackage{lmodern} \usepackage{hyperref} \usepackage{graphicx} \usepackage[english]{babel} \usepackage{listings} \usepackage{amsmath} \usepackage{amsthm} \usepackage{amssymb} \usepackage{natbib} \usepackage{stmaryrd} \usepackage{xypic} \lstset{% language=Lisp, basicstyle=\ttfamily\small } %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 'dedication' environment: To add a dedication paragraph at the start of book % % Source: http://www.tug.org/pipermail/texhax/2010-June/015184.html % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \newenvironment{dedication} { \cleardoublepage \thispagestyle{empty} \vspace*{\stretch{1}} \hfill\begin{minipage}[t]{0.66\textwidth} \raggedright } { \end{minipage} \vspace*{\stretch{3}} \clearpage } %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Chapter quote at the start of chapter % % Source: http://tex.stackexchange.com/a/53380 % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \makeatletter \renewcommand{\@chapapp}{}% Not necessary... \newenvironment{chapquote}[2][2em] {\setlength{\@tempdima}{#1}% \def\chapquote@author{#2}% \parshape 1 \@tempdima \dimexpr\textwidth-2\@tempdima\relax% \itshape} {\par\normalfont\hfill--\ \chapquote@author\hspace*{\@tempdima}\par\bigskip} \makeatother %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \newcommand{\itm}[1]{\ensuremath{\mathit{#1}}} \newcommand{\Stmt}{\itm{stmt}} \newcommand{\Exp}{\itm{exp}} \newcommand{\Instr}{\itm{instr}} \newcommand{\Prog}{\itm{prog}} \newcommand{\Arg}{\itm{arg}} \newcommand{\Int}{\itm{int}} \newcommand{\Var}{\itm{var}} \newcommand{\Op}{\itm{op}} \newcommand{\key}[1]{\texttt{#1}} \newcommand{\READ}{(\key{read})} \newcommand{\UNIOP}[2]{(\key{#1}\,#2)} \newcommand{\BINOP}[3]{(\key{#1}\,#2\,#3)} \newcommand{\LET}[3]{(\key{let}\,([#1\;#2])\,#3)} \newcommand{\ASSIGN}[2]{(\key{assign}\,#1\;#2)} \newcommand{\RETURN}[1]{(\key{return}\,#1)} \newcommand{\INT}[1]{(\key{int}\;#1)} \newcommand{\REG}[1]{(\key{reg}\;#1)} \newcommand{\VAR}[1]{(\key{var}\;#1)} \newcommand{\STACKLOC}[1]{(\key{stack}\;#1)} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \title{\Huge \textbf{Essentials of Compilation} \\ \huge An Incremental Approach} \author{\textsc{Jeremy G. Siek} \thanks{\url{http://homes.soic.indiana.edu/jsiek/}} } \begin{document} \frontmatter \maketitle \begin{dedication} This book is dedicated to the programming language wonks at Indiana University. \end{dedication} \tableofcontents %\listoffigures %\listoftables \mainmatter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter*{Preface} Talk about nano-pass \citep{Sarkar:2004fk,Keep:2012aa} and incremental compilers \citep{Ghuloum:2006bh}. %\section*{Structure of book} % You might want to add short description about each chapter in this book. %\section*{About the companion website} %The website\footnote{\url{https://github.com/amberj/latex-book-template}} for %this file contains: %\begin{itemize} % \item A link to (freely downlodable) latest version of this document. % \item Link to download LaTeX source for this document. % \item Miscellaneous material (e.g. suggested readings etc). %\end{itemize} \section*{Acknowledgments} Need to give thanks to \begin{itemize} \item Kent Dybvig \item Daniel P. Friedman \item Abdulaziz Ghuloum \item Oscar Waddell \item Dipanwita Sarkar \item Ronald Garcia \item Bor-Yuh Evan Chang \end{itemize} %\mbox{}\\ %\noindent Amber Jain \\ %\noindent \url{http://amberj.devio.us/} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Integers and Variables} \label{ch:int-exp} %\begin{chapquote}{Author's name, \textit{Source of this quote}} %``This is a quote and I don't know who said this.'' %\end{chapquote} \section{The $S_0$ Language} The $S_0$ language includes integers, operations on integers, (arithmetic and input), and variable definitions. The syntax of the $S_0$ language is defined by the grammar in Figure~\ref{fig:s0-syntax}. This language is rich enough to exhibit several compilation techniques but simple enough so that we can implement a compiler for it in two weeks of hard work. To give the reader a feeling for the scale of this first compiler, the instructor solution for the $S_0$ compiler consists of 6 recursive functions and a few small helper functions that together span 256 lines of code. \begin{figure}[htbp] \centering \fbox{ \begin{minipage}{0.85\textwidth} \[ \begin{array}{lcl} \Op &::=& \key{+} \mid \key{-} \mid \key{*} \mid \key{read} \\ \Exp &::=& \Int \mid (\Op \; \Exp^{*}) \mid \Var \mid \LET{\Var}{\Exp}{\Exp} \end{array} \] \end{minipage} } \caption{The syntax of the $S_0$ language. The abbreviation \Op{} is short for operator, \Exp{} is short for expression, \Int{} for integer, and \Var{} for variable.} \label{fig:s0-syntax} \end{figure} The result of evaluating an expression is a value. For $S_0$, values are integers. To make it straightforward to map these integers onto x86-64 assembly~\citep{Matz:2013aa}, we restrict the integers to just those representable with 64-bits, the range $-2^{63}$ to $2^{63}$. We will walk through some examples of $S_0$ programs, commenting on aspects of the language that will be relevant to compiling it. We start with one of the simplest $S_0$ programs; it adds two integers. \[ \BINOP{+}{10}{32} \] The result is $42$, as you might expected. % The next example demonstrates that expressions may be nested within each other, in this case nesting several additions and negations. \[ \BINOP{+}{10}{ \UNIOP{-}{ \BINOP{+}{12}{20} } } \] What is the result of the above program? The \key{let} construct stores a value in a variable which can then be used within the body of the \key{let}. So the following program stores $32$ in $x$ and then computes $\BINOP{+}{10}{x}$, producing $42$. \[ \LET{x}{ \BINOP{+}{12}{20} }{ \BINOP{+}{10}{x} } \] When there are multiple \key{let}'s for the same variable, the closest enclosing \key{let} is used. Consider the following program with two \key{let}'s that define variables named $x$. \[ \LET{x}{32}{ \BINOP{+}{ \LET{x}{10}{x} }{ x } } \] For the purposes of showing which variable uses correspond to which definitions, the following shows the $x$'s annotated with subscripts to distinguish them. \[ \LET{x_1}{32}{ \BINOP{+}{ \LET{x_2}{10}{x_2} }{ x_1 } } \] The \key{read} operation prompts the user of the program for an integer. Given an input of $10$, the following program produces $42$. \[ \BINOP{+}{(\key{read})}{32} \] We include the \key{read} operation in $S_0$ to demonstrate that order of evaluation can make a different. Given the input $52$ then $10$, the following produces $42$ (and not $-42$). \[ \LET{x}{\READ}{ \LET{y}{\READ}{ \BINOP{-}{x}{y} } } \] The initializing expression is always evaluated before the body of the \key{let}, so in the above, the \key{read} for $x$ is performed before the \key{read} for $y$. % The behavior of the following program is somewhat subtle because Scheme does not specify an evaluation order for arguments of an operator such as $-$. \[ \BINOP{-}{\READ}{\READ} \] Given the input $42$ then $10$, the above program can result in either $42$ or $-42$, depending on the whims of the Scheme implementation. The goal for this chapter is to implement a compiler that translates any program $p \in S_0$ into a x86-64 assembly program $p'$ such that the assembly program exhibits the same behavior on an x86 computer as the $S_0$ program running in a Scheme implementation. \[ \xymatrix{ p \in S_0 \ar[rr]^{\text{compile}} \ar[drr]_{\text{run in Scheme}\quad} && p' \in \text{x86-64} \ar[d]^{\quad\text{run on an x86 machine}}\\ & & n \in \mathbb{Z} } \] In the next section we introduce enough of the x86-64 assembly language to compile $S_0$. \section{The x86-64 Assembly Language} An x86-64 program is a sequence of instructions. The instructions manipulate 16 variables called \emph{registers} and can also load and store values into \emph{memory}. Memory is a mapping of 64-bit addresses to 64-bit values. The syntax $n(r)$ is used to read the address $a$ stored in register $r$ and then offset it by $n$ bytes (8 bits), producing the address $a + n$. The arithmetic instructions, such as $\key{addq}\,s\,d$, read from the source $s$ and destination argument $d$, apply the arithmetic operation, then stores the result in the destination $d$. In this case, computing $d \gets d + s$. The move instruction, $\key{movq}\,s\,d$ reads from $s$ and stores the result in $d$. The $\key{callq}\,\mathit{label}$ instruction executes the procedure specified by the label, which we shall use to implement \key{read}. Figure~\ref{fig:x86-a} defines the syntax for this subset of the x86-64 assembly language. \begin{figure}[tbp] \fbox{ \begin{minipage}{0.96\textwidth} \[ \begin{array}{lcl} \itm{register} &::=& \key{rsp} \mid \key{rbp} \mid \key{rax} \mid \key{rbx} \mid \key{rcx} \mid \key{rdx} \mid \key{rsi} \mid \key{rdi} \mid \\ && \key{r8} \mid \key{r9} \mid \key{r10} \mid \key{r11} \mid \key{r12} \mid \key{r13} \mid \key{r14} \mid \key{r15} \\ \Arg &::=& \key{\$}\Int \mid \key{\%}\itm{register} \mid \Int(\key{\%}\itm{register}) \\ \Instr &::=& \key{addq} \; \Arg, \Arg \mid \key{subq} \; \Arg, \Arg \mid \key{imulq} \; \Arg,\Arg \mid \key{negq} \; \Arg \mid \\ && \key{movq} \; \Arg, \Arg \mid \key{callq} \; \mathit{label} \mid \key{pushq}\;\Arg \mid \key{popq}\;\Arg \mid \key{retq} \\ \Prog &::= & \key{.globl \_main}\\ & & \key{\_main:} \; \Instr^{+} \end{array} \] \end{minipage} } \caption{A subset of the x86-64 assembly language.} \label{fig:x86-a} \end{figure} Figure~\ref{fig:p0-x86} depicts an x86-64 program that is equivalent to $\BINOP{+}{10}{32}$. The \key{globl} directive says that the \key{\_main} procedure is externally visible, which is necessary so that the operating system can call it. The label \key{\_main:} indicates the beginning of the \key{\_main} procedure. The instruction $\key{movq}\,\$10, \%\key{rax}$ puts $10$ into the register \key{rax}. The following instruction $\key{addq}\,\key{\$}32, \key{\%rax}$ adds $32$ to the $10$ in \key{rax} and puts the result, $42$, back into \key{rax}. The instruction \key{retq} finishes the \key{\_main} function by returning the integer in the \key{rax} register to the operating system. \begin{figure}[htbp] \centering \begin{minipage}{0.6\textwidth} \begin{lstlisting} .globl _main _main: movq $10, %rax addq $32, %rax retq \end{lstlisting} \end{minipage} \caption{A simple x86-64 program equivalent to $\BINOP{+}{10}{32}$.} \label{fig:p0-x86} \end{figure} The next example exhibits the use of memory. Figure~\ref{fig:p1-x86} lists an x86-64 program that is equivalent to $\BINOP{+}{52}{ \UNIOP{-}{10} }$. To understand how this x86-64 program uses memory, we need to explain a region of memory called called the \emph{procedure call stack} (\emph{stack} for short). The stack consists of a separate \emph{frame} for each procedure call. The memory layout for an individual frame is shown in Figure~\ref{fig:frame}. The register \key{rsp} is called the \emph{stack pointer} and points to the item at the top of the stack. The stack grows downward in memory, so we increase the size of the stack by subtracting from the stack pointer. The frame size is required to be a multiple of 16 bytes. The register \key{rbp} is the \emph{base pointer} which serves two purposes: 1) it saves the location of the stack pointer for the procedure that called the current one and 2) it is used to access variables associated with the current procedure. We number the variables from $1$ to $n$. Variable $1$ is stored at address $-8\key{(\%rbp)}$, variable $2$ at $-16\key{(\%rbp)}$, etc. \begin{figure} \centering \begin{minipage}{0.6\textwidth} \begin{lstlisting} .globl _main _main: pushq %rbp movq %rsp, %rbp subq $16, %rsp movq $10, -8(%rbp) negq -8(%rbp) movq $52, %rax addq -8(%rbp), %rax addq $16, %rsp popq %rbp retq \end{lstlisting} \end{minipage} \caption{An x86-64 program equivalent to $\BINOP{+}{52}{\UNIOP{-}{10} }$.} \label{fig:p1-x86} \end{figure} \begin{figure} \centering \begin{tabular}{|r|l|} \hline Position & Contents \\ \hline 8(\key{\%rbp}) & return address \\ 0(\key{\%rbp}) & old \key{rbp} \\ -8(\key{\%rbp}) & variable $1$ \\ -16(\key{\%rbp}) & variable $2$ \\ \ldots & \ldots \\ 0(\key{\%rsp}) & variable $n$\\ \hline \end{tabular} \caption{Memory layout of a frame.} \label{fig:frame} \end{figure} Getting back to the program in Figure~\ref{fig:p1-x86}, the first three instructions are the typical prelude for a procedure. The instruction \key{pushq \%rbp} saves the base pointer for the procedure that called the current one onto the stack and subtracts $8$ from the stack pointer. The second instruction \key{movq \%rsp, \%rbp} changes the base pointer to the top of the stack. The instruction \key{subq \$16, \%rsp} moves the stack pointer down to make enough room for storing variables. This program just needs one variable ($8$ bytes) but because the frame size is required to be a multiple of 16 bytes, it rounds to 16 bytes. The next four instructions carry out the work of computing $\BINOP{+}{52}{\UNIOP{-}{10} }$. The first instruction \key{movq \$10, -8(\%rbp)} stores $10$ in variable $1$. The instruction \key{negq -8(\%rbp)} changes variable $1$ to $-10$. The \key{movq \$52, \%rax} places $52$ in the register \key{rax} and \key{addq -8(\%rbp), \%rax} adds the contents of variable $1$ to \key{rax}, at which point \key{rax} contains $42$. The last three instructions are the typical \emph{conclusion} of a procedure. The \key{addq \$16, \%rsp} instruction moves the stack pointer back to point at the old base pointer. The amount added here needs to match the amount that was subtracted in the prelude of the procedure. Then \key{popq \%rbp} returns the old base pointer to \key{rbp} and adds $8$ to the stack pointer. The \key{retq} instruction jumps back to the procedure that called this one and subtracts 8 from the stack pointer. The compiler will need a convenient representation for manipulating x86 programs, so we define an abstract syntax for x86 in Figure~\ref{fig:x86-ast-a}. The \itm{info} field of the \key{program} AST node is for storing auxilliary information that needs to be communicated from one pass to the next. The function \key{print-x86} provided in the supplemental code converts an x86 abstract syntax tree into the text representation for x86 (Figure~\ref{fig:x86-a}). \begin{figure}[tbp] \fbox{ \begin{minipage}{0.96\textwidth} \[ \begin{array}{lcl} \Arg &::=& \INT{\Int} \mid \REG{\itm{register}} \mid \STACKLOC{\Int} \\ \Instr &::=& (\key{add} \; \Arg\; \Arg) \mid (\key{sub} \; \Arg\; \Arg) \mid (\key{imul} \; \Arg\;\Arg) \mid (\key{neg} \; \Arg) \mid \\ && (\key{mov} \; \Arg\; \Arg) \mid (\key{call} \; \mathit{label}) \mid (\key{push}\;\Arg) \mid (\key{pop}\;\Arg) \mid (\key{ret}) \\ \Prog &::= & (\key{program} \;\itm{info} \; \Instr^{+}) \end{array} \] \end{minipage} } \caption{Abstract syntax for x86-64 assembly.} \label{fig:x86-ast-a} \end{figure} \section{Planning the route from $S_0$ to x86-64} \label{sec:plan-s0-x86} To compile one language to another it helps to focus on the differences between the two languages. It is these differences that the compiler will need to bridge. What are the differences between $S_0$ and x86-64 assembly? Here we list some of the most important the differences. \begin{enumerate} \item x86-64 arithmetic instructions typically take two arguments and update the second argument in place. In contrast, $S_0$ arithmetic operations only read their arguments and produce a new value. \item An argument to an $S_0$ operator can be any expression, whereas x86-64 instructions restrict their arguments to integers, registers, and memory locations. \item An $S_0$ program can have any number of variables whereas x86-64 has only 16 registers. \item Variables in $S_0$ can overshadow other variables with the same name. The registers and memory locations of x86-64 all have unique names. \end{enumerate} We ease the challenge of compiling from $S_0$ to x86 by breaking down the problem into several steps, dealing with the above differences one at a time. The main question then becomes: in what order to we tackle these differences? This is often one of the most challenging questions that a compiler writer must answer because some orderings may be much more difficult to implement than others. It is difficult to know ahead of time which orders will be better so often some trial-and-error is involved. However, we can try to plan ahead and choose the orderings based on what we find out. For example, to handle difference \#2 (nested expressions), we shall introduce new variables and pull apart the nested expressions into a sequence of assignment statements. To deal with difference \#3 we will be replacing variables with registers and/or stack locations. Thus, it makes sense to deal with \#2 before \#3 so that \#3 can replace both the original variables and the new ones. Next, consider where \#1 should fit in. Because it has to do with the format of x86 instructions, it makes more sense after we have flattened the nested expressions (\#2). Finally, when should we deal with \#4 (variable overshadowing)? We shall be solving this problem by renaming variables to make sure they have unique names. Recall that our plan for \#2 involves moving nested expressions, which could be problematic if it changes the shadowing of variables. However, if we deal with \#4 first, then it will not be an issue. Thus, we arrive at the following ordering. \[ \xymatrix{ 4 \ar[r] & 2 \ar[r] & 1 \ar[r] & 3 } \] We further simplify the translation from $S_0$ to x86 by identifying an intermediate language named $C_0$, roughly half-way between $S_0$ and x86, to provide a rest stop along the way. The name $C_0$ comes from this language being vaguely similar to the $C$ language. The differences \#4 and \#1, regarding variables and nested expressions, are handled by the passes \textsf{uniquify} and \textsf{flatten} that bring us to $C_0$. \[\large \xymatrix@=50pt{ S_0 \ar@/^/[r]^-{\textsf{uniquify}} & S_0 \ar@/^/[r]^-{\textsf{flatten}} & C_0 } \] The syntax for $C_0$ is defined in Figure~\ref{fig:c0-syntax}. The $C_0$ language supports the same operators as $S_0$ but the arguments of operators are now restricted to just variables and integers. The \key{let} construct of $S_0$ is replaced by an assignment statement and there is a \key{return} construct to specify the return value of the program. A program consists of a sequence of statements that include at least one \key{return} statement. \begin{figure}[htbp] \[ \begin{array}{lcl} \Arg &::=& \Int \mid \Var \\ \Exp &::=& \Arg \mid (\Op \; \Arg^{*})\\ \Stmt &::=& \ASSIGN{\Var}{\Exp} \mid \RETURN{\Arg} \\ \Prog & ::= & (\key{program}\;\itm{info}\;\Stmt^{+}) \end{array} \] \caption{The $C_0$ intermediate language.} \label{fig:c0-syntax} \end{figure} To get from $C_0$ to x86-64 assembly requires three more steps, which we discuss below. \[\large \xymatrix@=50pt{ C_0 \ar@/^/[r]^-{\textsf{select\_instr.}} & \text{x86}^{*} \ar@/^/[r]^-{\textsf{assign\_homes}} & \text{x86}^{*} \ar@/^/[r]^-{\textsf{patch\_instr.}} & \text{x86} } \] We handle difference \#1, concerning the format of arithmetic instructions, in the \textsf{select\_instructions} pass. The result of this pass produces programs consisting of x86-64 instructions that use variables. % As there are only 16 registers, we cannot always map variables to registers (difference \#3). Fortunately, the stack can grow quite, so we can map variables to locations on the stack. This is handled in the \textsf{assign\_homes} pass. The topic of Chapter~\ref{ch:register-allocation} is implementing a smarter approach in which we make a best-effort to map variables to registers, resorting to the stack only when necessary. The final pass in our journey to x86 handles an indiosycracy of x86 assembly. Many x86 instructions have two arguments but only one of the arguments may be a memory reference. Because we are mapping variables to stack locations, many of our generated instructions will violate this restriction. The purpose of the \textsf{patch\_instructions} pass is to fix this problem by replacing every bad instruction with a short sequence of instructions that use the \key{rax} register. \section{Uniquify Variables} The purpose of this pass is to make sure that each \key{let} uses a unique variable name. For example, the \textsf{uniquify} pass could translate \[ \LET{x}{32}{ \BINOP{+}{ \LET{x}{10}{x} }{ x } } \] to \[ \LET{x.1}{32}{ \BINOP{+}{ \LET{x.2}{10}{x.2} }{ x.1 } } \] We recommend implementing \textsf{uniquify} as a recursive function that mostly just copies the input program. However, when encountering a \key{let}, it should generate a unique name for the variable (the Racket function \key{gensym} is handy for this) and associate the old name with the new unique name in an association list. The \textsf{uniquify} function will need to access this association list when it gets to a variable reference, so we add another paramter to \textsf{uniquify} for the association list. \section{Flatten Expressions} The purpose of the \textsf{flatten} pass is to get rid of nested expressions, such as the $\UNIOP{-}{10}$ in the following program, without changing the behavior of the program. \[ \BINOP{+}{52}{ \UNIOP{-}{10} } \] This can be accomplished by introducing a new variable, assigning the nested expression to the new variable, and then using the new variable in place of the nested expressions. For example, the above program is translated to the following one. \[ \begin{array}{l} \ASSIGN{ \itm{x} }{ \UNIOP{-}{10} } \\ \RETURN{ \BINOP{+}{52}{ \itm{x} } } \end{array} \] We recommend implementing \textsf{flatten} as a recursive function that returns two things, 1) the newly flattened expression, and 2) a list of assignment statements, one for each of the new variables introduced while flattening the expression. Take special care for programs such as the following that initialize variables with integers or other variables. \[ \LET{a}{42}{ \LET{b}{a}{ b }} \] This program should be translated to \[ \ASSIGN{a}{42} \; \ASSIGN{b}{a} \; \RETURN{b} \] and not the following, which could result from a naive implementation of \textsf{flatten}. \[ \ASSIGN{x.1}{42}\; \ASSIGN{a}{x.1}\; \ASSIGN{x.2}{a}\; \ASSIGN{b}{x.2}\; \RETURN{b} \] \section{Select Instructions} In the \textsf{select\_instructions} pass we begin the work of translating from $C_0$ to x86. The target language of this pass is a pseudo-x86 language that still uses variables, so we add an AST node of the form $\VAR{\itm{var}}$. The \textsf{select\_instructions} pass deals with the differing format of arithmetic operations. For example, in $C_0$ an addition operation could take the following form: \[ \ASSIGN{x}{ \BINOP{+}{10}{32} } \] To translate to x86, we need to express this addition using the \key{add} instruction that does an inplace update. So we first move $10$ to $x$ then perform the \key{add}. \[ (\key{mov}\,\INT{10}\, \VAR{x})\; (\key{add} \;\INT{32}\; \VAR{x}) \] There are some cases that require special care to avoid generating needlessly complicated code. If one of the arguments is the same as the left-hand side of the assignment, then there is no need for the extra move instruction. For example, the following \[ \ASSIGN{x}{ \BINOP{+}{10}{x} } \quad\text{should translate to}\quad (\key{add} \; \INT{10}\; \VAR{x}) \] Regarding the \RETURN{e} statement of $C_0$, we recommend treating it as an assignment to the \key{rax} register and let the procedure conclusion handle the transfer of control back to the calling procedure. \section{Assign Homes} As discussed in Section~\ref{sec:plan-s0-x86}, the \textsf{assign\_homes} pass places all of the variables on the stack. Consider again the example $S_0$ program $\BINOP{+}{52}{ \UNIOP{-}{10} }$, which after \textsf{select\_instructions} looks like the following. \[ \begin{array}{l} (\key{mov}\;\INT{10}\; \VAR{x})\\ (\key{neg}\; \VAR{x})\\ (\key{mov}\; \INT{52}\; \REG{\itm{rax}})\\ (\key{add}\; \VAR{x} \REG{\itm{rax}}) \end{array} \] The one and only variable $x$ is assigned to stack location \key{-8(\%rbp)}, so the \textsf{assign\_homes} pass translates the above to \[ \begin{array}{l} (\key{mov}\;\INT{10}\; \STACKLOC{{-}8})\\ (\key{neg}\; \STACKLOC{{-}8})\\ (\key{mov}\; \INT{52}\; \REG{\itm{rax}})\\ (\key{add}\; \STACKLOC{{-}8}\; \REG{\itm{rax}}) \end{array} \] In the process of assigning stack locations to variables, it is convenient to compute and store the size of the frame which will be needed later to generate the procedure conclusion. \section{Patch Instructions} The purpose of this pass is to make sure that each instruction adheres to the restrictions regarding which arguments can be memory references. For most instructions, the rule is that at most one argument may be a memory reference. Consider again the following example. \[ \LET{a}{42}{ \LET{b}{a}{ b }} \] After \textsf{assign\_homes} pass, the above has been translated to \[ \begin{array}{l} (\key{mov} \;\INT{42}\; \STACKLOC{{-}8})\\ (\key{mov}\;\STACKLOC{{-}8}\; \STACKLOC{{-}16})\\ (\key{mov}\;\STACKLOC{{-}16}\; \REG{\itm{rax}}) \end{array} \] The second \key{mov} instruction is problematic because both arguments are stack locations. We suggest fixing this problem by moving from the source to \key{rax} and then from \key{rax} to the destination, as follows. \[ \begin{array}{l} (\key{mov} \;\INT{42}\; \STACKLOC{{-}8})\\ (\key{mov}\;\STACKLOC{{-}8}\; \REG{\itm{rax}})\\ (\key{mov}\;\REG{\itm{rax}}\; \STACKLOC{{-}16})\\ (\key{mov}\;\STACKLOC{{-}16}\; \REG{\itm{rax}}) \end{array} \] The \key{imul} instruction is a special case because the destination argument must be a register. \section{Testing with Interpreters} The typical way to test a compiler is to run the generated assembly code on a diverse set of programs and check whether they behave as expected. However, when a compiler is structured as our is, with many passes, when there is an error in the generated assembly code it can be hard to determine which pass contains the source of the error. A good way to isolate the error is to not only test the generated assembly code but to also test the output of every pass. This requires having interpreters for all the intermediate languages. Indeed, the file \key{interp.rkt} in the supplemental code provides interpreters for all the intermediate languages described in this book, starting with interpreters for $S_0$, $C_0$, and x86 (in abstract syntax). The file \key{run-tests.rkt} automates the process of running the interpreters on the output programs of each pass and checking their result. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Register Allocation} \label{ch:register-allocation} % three new passes between instruction selection and spill code % uncover-live % build-interference % allocate registers (uses assign-homes) \[ \xymatrix{ C_0 \ar@/^/[r]^-{\textsf{select\_instr.}} & \text{x86}^{*} \ar[d]^-{\textsf{uncover\_live}} \\ & \text{x86}^{*} \ar[d]^-{\textsf{build\_interference}} \\ & \text{x86}^{*} \ar[d]_-{\textsf{allocate\_register}} \\ & \text{x86}^{*} \ar@/^/[r]^-{\textsf{patch\_instr.}} & \text{x86} } \] % example % some vars with disjoint live ranges: x y % some vars with overlapping live ranges: z \begin{lstlisting} (let ([x 30]) (let ([z (+ x 4)]) (let ([y 2]) (let ([w (+ z 10)]) (- w y))))) \end{lstlisting} after select instructions \begin{lstlisting} (program (x z y w) (mov (int 30) (var x)) (mov (var x) (var z)) (add (int 4) (var z)) (mov (int 2) (var y)) (mov (var z) (var w)) (add (int 10) (var w)) (mov (var w) (reg rax)) (sub (var y) (reg rax))) \end{lstlisting} \section{Liveness Analysis} \begin{lstlisting} (program (x z y w) ; { } (mov (int 30) (var x)) ; { x } (mov (var x) (var z)) ; { z } (add (int 4) (var z)) ; { z } (mov (int 2) (var y)) ; { y, z } (mov (var z) (var w)) ; { w, y } (add (int 10) (var w)) ; { w, y } (mov (var w) (reg rax)) ; { y, rax } (sub (var y) (reg rax))) \end{lstlisting} \section{Build Interference Graph} %% (hash %% 'z1498 %% (set 'rax 'x1497 'y1499) %% 'x1497 %% (set 'z1498) %% 'rax %% (set 'z1498 'y1499) %% 'y1499 %% (set 'rax 'z1498))) \[ \xymatrix{ w \ar@{-}[d] \ar@{-}[dr] & x \ar@{-}[d] \\ y \ar@{-}[r] & z } \] \section{Graph Coloring via Sudoku} Suppose only \key{rbx} is available for use by the register allocator. \[ \xymatrix{ w:\key{-8(\%rbp)} \ar@{-}[d] \ar@{-}[dr] & x:\itm{rbx} \ar@{-}[d] \\ y:\itm{rbx} \ar@{-}[r] & z:\key{-16(\%rbp)} } \] \begin{lstlisting} movq $30, %rbx movq %rbx, -16(%rbp) addq $4, -16(%rbp) movq $2, %rbx movq -16(%rbp), -8(%rbp) addq $10, -8(%rbp) movq -8(%rbp), %rax subq %rbx, %rax \end{lstlisting} patch instructions fixes the move from \key{-16(\%rbp)} to \key{-8(\%rbp)}. \begin{lstlisting} movq -16(%rbp), %rax movq %rax, -8(%rbp) \end{lstlisting} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Booleans, Conditions, and Type Checking} \label{ch:bool-types} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Tuples and Heap Allocation} \label{ch:tuples} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Functions} \label{ch:functions} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Lexically Scoped Functions} \label{ch:lambdas} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Mutable Data} \label{ch:mutable-data} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{The Dynamic Type} \label{ch:type-dynamic} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Parametric Polymorphism} \label{ch:parametric-polymorphism} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{High-level Optimization} \label{ch:high-level-optimization} \bibliographystyle{plainnat} \bibliography{all} \end{document} %% LocalWords: Dybvig Waddell Abdulaziz Ghuloum Dipanwita %% LocalWords: Sarkar lcl Matz aa representable