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

diff --git a/Report/Main/Context/MontiumC.tex b/Report/Main/Context/MontiumC.tex
index d3da01a..e9eb3bf 100644
--- a/Report/Main/Context/MontiumC.tex
+++ b/Report/Main/Context/MontiumC.tex
@@ -3,8 +3,8 @@
 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).
+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
@@ -12,27 +12,32 @@ 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
+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
+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 (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
-program. 
+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 (also see section
-\ref{LLVM}). The second part transforms this intermediate representation, output
-again a (reduced form of) this representation.
+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