From: Matthijs Kooijman Date: Wed, 24 Sep 2008 15:12:25 +0000 (+0200) Subject: Cosmetic fixes. X-Git-Tag: Report-final~3 X-Git-Url: https://git.stderr.nl/gitweb?a=commitdiff_plain;h=28976641f199e6c3ad3a17aa82cbb87b0e31a9d0;p=matthijs%2Fprojects%2Finternship.git Cosmetic fixes. --- diff --git a/Report/Front/Abstract.tex b/Report/Front/Abstract.tex index 02256b9..0a4bd98 100644 --- a/Report/Front/Abstract.tex +++ b/Report/Front/Abstract.tex @@ -5,7 +5,7 @@ usage and high performance. For programming the Montium, a flavour of C was 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. @@ -19,15 +19,15 @@ give the best error messages yet. 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. diff --git a/Report/Main/Context/LLVM.tex b/Report/Main/Context/LLVM.tex index 9d14cbc..a39c3ec 100644 --- a/Report/Main/Context/LLVM.tex +++ b/Report/Main/Context/LLVM.tex @@ -3,8 +3,8 @@ 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: diff --git a/Report/Main/Context/Montium.tex b/Report/Main/Context/Montium.tex index cd45205..1993d66 100644 --- a/Report/Main/Context/Montium.tex +++ b/Report/Main/Context/Montium.tex @@ -9,7 +9,7 @@ and DSP engines, that make it both interesting and challenging to program 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} @@ -52,13 +52,13 @@ address patterns. This means that the instructions or CRs never contain direct m 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. @@ -96,7 +96,7 @@ in a single cycle, but since they operate sequentially, this severly limits 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 diff --git a/Report/Main/Context/Recore.tex b/Report/Main/Context/Recore.tex index 6631a70..ca96fb1 100644 --- a/Report/Main/Context/Recore.tex +++ b/Report/Main/Context/Recore.tex @@ -3,14 +3,14 @@ Recore Systems is a relatively young semiconductor company based in Enschede, 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 diff --git a/Report/Main/Future.tex b/Report/Main/Future.tex index 3246bab..8bc81f5 100644 --- a/Report/Main/Future.tex +++ b/Report/Main/Future.tex @@ -32,8 +32,8 @@ more invasive changes to LLVM. 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 @@ -46,9 +46,9 @@ binary executable, instead of having a seperate executable and a Java program. 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, diff --git a/Report/Main/Introduction.tex b/Report/Main/Introduction.tex index 7ce3239..e761bc6 100644 --- a/Report/Main/Introduction.tex +++ b/Report/Main/Introduction.tex @@ -1,7 +1,7 @@ \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 diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex index d5bc014..982397a 100644 --- a/Report/Main/Problems/Challenges.tex +++ b/Report/Main/Problems/Challenges.tex @@ -33,7 +33,7 @@ makes use of corner cases in the compiler that have been missed in (or left out 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. @@ -100,7 +100,7 @@ lot of instructions. Second, the code is effectively software pipelined 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