X-Git-Url: https://git.stderr.nl/gitweb?a=blobdiff_plain;f=Report%2FMain%2FContext%2FMontiumC.tex;h=e9eb3bfe30383eb3d9b3f5760f882a0377e66675;hb=0ac3f8b7cfb60e71b9f95dc8bf1752e1e971685f;hp=35f1e60c61dbddc7380a8417fb270aae07213ac4;hpb=3f56dcfc5a48f15edc20515946e817e031d2a85a;p=matthijs%2Fprojects%2Finternship.git

diff --git a/Report/Main/Context/MontiumC.tex b/Report/Main/Context/MontiumC.tex
index 35f1e60..e9eb3bf 100644
--- a/Report/Main/Context/MontiumC.tex
+++ b/Report/Main/Context/MontiumC.tex
@@ -1,2 +1,51 @@
 \section{MontiumC}
-This section will describe MontiumC and the montium programming workflow.
+\label{MontiumC}
+Since having just a piece of hardware is not enough, we also need some way to
+program the Montium. To this end, the MontiumC language was created. The
+MontiumC language is a language very similar to C. It allows very fine grained
+control over the Montium through a set of functions that can be called (where
+the function called determines the operation mapped on the Montium).
+
+MontiumC is, on one hand, a strict subset of C. Every MontiumC program is
+therefore a valid C program as well. This is one of the strong points of
+MontiumC: By using a normal C compiler, a MontiumC program can be functionally
+simulated on normal hardware.
+
+On the other hand, MontiumC defines a number of special functions which are
+mapped onto the Montium ALU when compiling with the Montium-specific
+backend. When compiling with a normal C compiler, these functions are
+implemented by a library implemented in C.
+
+Figure \ref{CompilingMontiumC} shows the flow for compiling a MontiumC program
+into a Montium binary file, which can be loaded directly onto a Montium. The
+process is roughly divided into two parts (each of which corresponds to a
+different program in the compiler suite): The frontend and the backend.
+
+The frontend takes in a MontiumC program and turns it into a lower level
+description of the program (the Montium intermediate representation).
+The frontend is responsible for mapping higher level C constructs onto
+simpler instructions, for canonicalizing and simplifying the code. These
+canonicalizations and simplifications ensure that the backend can be
+kept simpler and does not have to deal with all the complexities of the
+original program. 
+
+The frontend is again divided into two pieces, the first of which
+transforms C code into an intermediate representation (called LLVM IR).
+For the first part the Clang compiler, part of the LLVM project, is used
+mostly unmodified. See section \ref{LLVM} for an overview of the LLVM
+project. The second part transforms this intermediate representation
+into a simpler form, which is more suitable for mapping onto the Montium
+hardware by the backend. The output of this transformation is again in
+the the same format, but with a lot of additional constraints. This
+extra constrained format is referred to as Montium IR.
+
+The backend, in turn, takes in this reduced description of the program and
+transforms this into a valid Montium binary. To do this, it must find an ALU
+configuration to execute a given set of operations, trace values to allocate
+them to registers, generate instructions for the adress generation units, etc.
+
+\begin{figure}
+\epsfig{file=Img/Compiling.ps, width=\textwidth}
+\caption{MontiumC compilation flow}
+\label{CompilingMontiumC}
+\end{figure}