\section{Code generation}\label{sec:gen}
-\subsection{ABR}
-%Heap en stack layout
+\subsection{Binary Representation}
+\SPLC{} uses a simple stack layout in which all functions have their own stack
+frame and all the arguments and local variables are present within this frame.
+Arguments and local variables are either saved on the stack directly, or as a
+pointer to the heap. Simple values, i.e. Ints, Bools and Chars are stored
+directly on the stack, while other values are stored on the heap.
+
+The heap simply grows with each added value, currently no garbage collection is
+done. Lists are represented simply as linked lists, by first storing the pointer
+to the next list element and then the current list element. Tuples are simply
+stored by staring the two values in succession.
+
+When calling a functions its arguments are placed on the stack, after which
+a \tt{bsr} instruction calls the function. The functions can then load its
+arguments, if and when these are needed in an expression, by copying them
+from below its stack frame.
+
+Note that the combination of this copying behaviour and passing complex values
+as heap pointers means that in some cases \SPLC{} programs behave as
+pass-by-value while in others it behave as pass-by-reference. Simple values
+are trivially pass-by-value, whilst lists and tuples can behave as both,
+depending on the usage. E.g. assigning a new list/tuple to an argument will
+behave as pass-by-value, whilst changing the argument through a field selector
+will behave as pass by reference.
+
+Listing~\ref{lst:stackFunCall} shows the layout of the stack executing the
+two functions. the layout shown is the layout of the stack just before
+the \tt{add} instruction to add x and y. Note that, in compliance with \SSM{}s
+calling model, the return address of a function is saved below the stack frame
+of that function. When plus has returned the two arguments are popped of the
+stack and the value in \tt{RR} (for functions which do not return \tt{Void})
+is placed on the stack.
+
+\begin{SPLCode} \label{lst:stackFunCall}
+plus(x, y}{ return x + y; }
+
+main(){ var a = plus(3, 4); }
+
+/*# | Stack
+111 | 002 ;return address of main
+;begin stack frame of main
+112 | 110 ;Frame pointer for main; points to bottom of stack
+113 | 003 ;arg1 for plus
+114 | 004 ;arg2 for plus
+115 | 0fa ;return address of plus
+;begin stack frame of plus
+116 | 112 ;Frame pointer for plus; points to mains stack frame
+117 | 003 ;x, loaded by ldl -3
+118 | 004 ;y, loaded by ldl -2
+*/
+\end{SPLCode}
\subsection{Generation}
-%gewoon hoe het werkt
+The code generation phase transforms a well typed \AST{} to either an error,
+or an \tt{SSMProgram}The latter is a list of labels and instructions. The
+generation happens within a
+\CI{WriterT SSMProgram (StateT (Addressbook, [Label]) (Either GenError)) a}
+environment. Which we have implemented as a \tt{RWST} with \tt{()} for the
+reading environment. In this \tt{Addressbook} is a simple map from
+identifiers to \tt{Address}, which in turn is either a label to jump to or an
+address where a variable can be found (relative to the current frame). The list
+of labels is simply an infinite generator for fresh labels, used when generating
+code for e.g. an if-statement.
+
+Code generation is done by walking through the \AST{} depth first and generating
+instructions for each encountered element. E.g. generation for an \tt{Op2Expr}
+is simply recursively generating for each element of the expression:
+\CI{g e1 >>| g e2 >>| g op}.
\subsection{Higher order functions}
The nature of the type checking algorithm already included type checking and
repositories / cc1516.git / blobdiff