developed, called MontiumC. MontiumC is a subset of standard C, providing a
library of builtin functions to access the extra features of the Montium.
-The assignment of this internship focusses on improving the MontiumC compiler.
+The assignment of this internship aims at improving the MontiumC compiler.
The main goal is to make the compiler consistently support all valid MontiumC
programs, instead of giving unexpected compilation errors when some (seemingly)
valid constructs are used in certain combinations.
The MontiumC compiler heavily relies on the LLVM (Low Level Virtual Machine)
project, which provides libraries and code for compiler development. This
greatly simplifies the maintainance work for the compiler, but at the cost of
-extra integration effort. Since the LLVM project mainly focusses on "regular"
+extra integration effort. Since the LLVM project mainly aims for "regular"
architectures, its code is not always directly usable. This is mostly solvable
by adding extra extension hooks to the LLVM code, but sometimes local changes to
-LLVM are still in use.
+LLVM are required.
Outside of the original assignment, there was also some work on the new hardware
design, for the next generation Montium. Issues here centered around software
-pipelining and code compression, and finding the balance between various
-tradeoffs between flexibility, performance, complexity/area, code size). This
+pipelining and code compression, and finding the balance in various
+tradeoffs between flexibility, performance, complexity/area, code size, etc. This
work was not finished within the internship, but provided a good learning
experience.
The Low Level Virtual Machine project (LLVM, \cite{LLVM}, \cite{Lattner:MSThesis02})
is a framework for compiler construction. It provides its own intermediate
representation, the LLVM IR. This is a simple language that can be used to
-expres any program in a static single assignment (SSA) form that is easy to
-reason with and transform.
+express any program in a static single assignment (SSA) form that is easy to
+reason with and apply transformations to.
Additionally, LLVM provides a host of libraries to work with this IR. There is
code for:
both application programmers and compiler designers.
\begin{figure}
- \epsfig{file=Img/MontiumOverview.eps, width=.5\textwidth}
+ %\epsfig{file=Img/MontiumOverview.eps, width=.5\textwidth}
\caption{Overview of the Montium design}
\end{figure}
addresses, only modifications to the current address. Each memory simply reads
from its current address and offers the value read to the interconnect (which
can then further distribute it to wherever it is needed). Writing works in the
-same way (though a memory can only be read or written to in the same cycle).
+same way (though a memory can only be read from or written to in the same cycle).
\subsubsection{ALU's}
The main processing elements of the Montium are its 5 ALU's. Each of them has
four (16 bit) inputs, each with a number of input registers. Each ALU contains a
number of function units, a multiplier, a few adders and some miscellaneous
-logic. Each of the elements in the ALU can be controlled seperately and data can
+logic. Each of the elements in the ALU can be controlled separately and data can
be routed in different ways by configuration of multiplexers inside the
ALU. The ALU has two output ports, without registers. Additionally, there is a
connection from each ALU to its neighbour.
clock speeds. In the new design, the number of ALUs is reduced, but each ALU is
subdivided in multiple parallel operating function units. Also, the Montium has
only very limited support for control flow, making it hard to program it for
-data dependent control and synchronization, which ask for improvements.
+data dependent control and synchronization, which asks for improvements.
This approach requires computations to be properly pipelined to efficiently
use all those function units in parallel, but since data only travels through
the Netherlands. It emerged as the result of research at the University of
Twente and focuses on developing hardware IP blocks for use in semiconductor
devices. The main product of Recore is the Montium Tile Processor, a low
-energy, high performance reconfigurable processor aimed at low-power DSP
+power, high performance reconfigurable processor aimed at low-power DSP
applications. The Montium will be discussed in more detail in the next section.
-Recore aims to provide a full solution for semiconductor manufactures and their
+Recore aims to provide a full solution for semiconductor manufacturers and their
customers, by providing IP blocks such as the Montium, tools for working with
them such as a compiler, an IDE and simulation environments and sample programs
and DSP libraries to ease application development. Currently, all of these
-components are still in a development stage, but already used internally and by
+components are still in a development stage, but already used internally and at
the University of Twente.
The activities of Recore and the employees working on them are roughly divisible
These changes are generic for LLVM and not needed specifically for the Montium.
Currently, most MontiumC code seems to still work with only a little
-change to LLVM, but especially with the new hardware, some missed out
-optimizations might become more useful.
+change to LLVM, but especially with the new hardware, these missed
+optimizations might become more of problem.
\section{LLVM based backend}
Currently, the frontend is using the LLVM framework, while the backend is
However, the main risk here is when the LLVM framework turns out to be not fully
suitable for the Montium backend. When nothing can be reused, the amount of code
needed is not any less, and if the framework poses limitations, might even be
-more. The new hardware design might be a lot more suitable for reusing code than
-the old Montium, though. Also, the added work of migrating to a new framework
-and new language is also a extra cost.
+more. The new hardware design might be a lot more suitable for reusing LLVM code than
+the old Montium, however. Also, the added work of migrating to a new framework
+and new language is also an extra cost.
Currently, doing this might or might not be a good idea. What is required first,
is doing a more in-depth investigation of the LLVM backend framework (which is,
\chapter*{Introduction}
This report describes my internship at Recore Systems. Having heard of Recore
and their innovative Montium chip during a few courses, I got involved with the
-Montium and its tooling during some DSP work during another course at the
+Montium and its tooling during some DSP work for another course at the
University of Twente.
From that initial contact, arrangements for an internship were quickly made, and
of) the specification, because they will not work reliably in all cases.
The best way to detect these cases is making the compiler check its input using
-an the specification. This way, any code operating outside of the specification
+the specification. This way, any code operating outside of the specification
can be detected automatically. Writing such checks has not happened yet, mainly
because the impact of the new hardware on MontiumC is not quite clear yet.
to make it run more efficiently.
In figure \ref{ExampleHigh} the same code is displayed, but this time
-using higer level C features (for loops, arra indexing). This is the
+using higer level C features (for loops, array indexing). This is the
level of code we are trying to achieve, but we're not there yet. It
should be noted that this is still not "normal" C, since we use the
"imul" function instead of the normal * operator. However, since the
projects / matthijs / projects / internship.git / commitdiff