Add conclusions and do some misc fixes.

[matthijs/projects/internship.git] / Report / Main / Context / MontiumC.tex

diff --git a/Report/Main/Context/MontiumC.tex b/Report/Main/Context/MontiumC.tex
index 828f3f2c21d58ae23fa17dbaeb44ad07c189a630..d3da01ac263583d1bc4e9c15b4abd255ef66160b 100644 (file)
--- a/Report/Main/Context/MontiumC.tex
+++ b/Report/Main/Context/MontiumC.tex
@@ -1,4 +1,5 @@
 \section{MontiumC}
+\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
@@ -10,13 +11,19 @@ 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} show 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 frontend is responsible for mapping higher level
+description of the program (LLVM Intermediate Representation, see the next
+section). 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