From 0ac3f8b7cfb60e71b9f95dc8bf1752e1e971685f Mon Sep 17 00:00:00 2001 From: Matthijs Kooijman Date: Tue, 7 Oct 2008 11:19:34 +0200 Subject: [PATCH] Fix misc style and spelling errors. Thanks to Brenda and Sebastiaan for pointing out these errors. --- Report/Front/Abstract.tex | 8 +-- Report/Main/Conclusions.tex | 10 ++-- Report/Main/Context/Montium.tex | 75 +++++++++++++++-------------- Report/Main/Context/MontiumC.tex | 25 ++++++---- Report/Main/Context/Recore.tex | 20 ++++---- Report/Main/Future.tex | 5 +- Report/Main/Introduction.tex | 6 +-- Report/Main/Problems/Assignment.tex | 2 +- Report/Main/Problems/Challenges.tex | 40 +++++++-------- Report/Main/Problems/Results.tex | 6 +-- 10 files changed, 105 insertions(+), 92 deletions(-) diff --git a/Report/Front/Abstract.tex b/Report/Front/Abstract.tex index 0a4bd98..9ef31c1 100644 --- a/Report/Front/Abstract.tex +++ b/Report/Front/Abstract.tex @@ -1,6 +1,6 @@ \begin{abstract} Recore Systems is working on the Montium architecture, which is a coarse grained -reconfigurable architecture, aiming at high flexibility, paired with low power +reconfigurable architecture, aimed at high flexibility, paired with low power 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. @@ -26,13 +26,13 @@ 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 in various +pipelining and code compression, and around 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. Currently, the MontiumC compiler is still far from perfect. There are plenty of -areas for improvement, including: Checking of specifications and improved error -messages, debug info (or line number) propagation to the backend, integrating +areas for improvement, including: checking of specifications, improved error +messages, debug info (or line number) propagation to the backend and integrating the (currently separate) backend codegenerator. \end{abstract} diff --git a/Report/Main/Conclusions.tex b/Report/Main/Conclusions.tex index 4d2585a..78b36b5 100644 --- a/Report/Main/Conclusions.tex +++ b/Report/Main/Conclusions.tex @@ -10,7 +10,7 @@ specification of MontiumC: If you don't know what the goals are, you can't really work towards them. But this also holds on a smaller scale. When, during coding you encounter a problem, it's often easy to solve just that problem. However, after stacking a few small solutions on top of each -other, things get complicated real fast. Then, it helps to take a step back and +other, things get complicated real fast. It helps to take a step back and try to find the bigger problem you are trying to solve, and evaluate subsolutions in that perspective. @@ -18,7 +18,7 @@ During my (limited amount of) work with the new hardware design, it became quickly apparent that trying to design the hardware in an optimal way, was completely impossible (when trying to stay within area and power constraints). The most important issue here is finding the balance between two sides -of a tradeoff, which was quite often hardware vs compiler complexity. Especially +of a tradeoff, which was quite often hardware versus compiler complexity. Especially this last issue makes it very clear that when designing hardware, the supporting tooling should be designed in parallel, to prevent the tooling from needing to be overly complex. @@ -46,6 +46,6 @@ system, while leaving out other parts. In some cases the LLVM code is less suitable, but this is mostly solvable and should be less of an issue once the new hardware is finished. -All in all, I feel that this internship has worked out quite well. The people -were cooperating, the job was fun yet challenging and the result is -well-received. +All in all, I feel that this internship has worked out quite well. +Cooperation with other employees was pleasant, the job was fun yet +challenging and the result is well-received. diff --git a/Report/Main/Context/Montium.tex b/Report/Main/Context/Montium.tex index 1993d66..973d21e 100644 --- a/Report/Main/Context/Montium.tex +++ b/Report/Main/Context/Montium.tex @@ -1,8 +1,9 @@ \section{Montium Tile Processor} +\label{Montium} The Montium Tile Processor (Montium) is the main product of Recore Systems. It -is a reconfigurable processor that is aimed for inclusion in a tiled, -heterogenous multi- or manycore System-on-Chip (SoC), connected to other tiles -and the outside world through a Network-on-Chip (NoC). +is a reconfigurable processor that is designed for inclusion in a tiled, +heterogenous multi- or manycore system-on-chip (SoC), connected to other tiles +and the outside world through a network-on-chip (NoC). The Montium has a number of fundamental differences with ``regular'' processors and DSP engines, that make it both interesting and challenging to program for @@ -15,13 +16,13 @@ both application programmers and compiler designers. \subsection{Overall design} The Montium is built from a few parts. The central part is the interconnect, -which ties memories, Arithmetic and Logic Units (ALU) and the Communication -and Configuration Unit (CCU) together. The memories store data locally, the -ALU's process data and the CCU moves data and configuration on and off the +which ties memories, arithmetic and logic units (ALU) and the communication +and configuration unit (CCU) together. The memories store data locally, the +ALUs process data and the CCU moves data and configuration on and off the Montium. Furthermore, there is a sequencer, which is the closest thing to a normal processor in the Montium: It accepts and executes instructions one by -one, is capable of performing (conditional) jumps and some other limited control -flow. +one, is capable of performing (conditional) jumps and can perform some other +limited control flow. \subsubsection{Sequencer} The Sequencer executes its instructions one by one and controls all other @@ -38,7 +39,7 @@ also means that the Montium is reconfigured on every cycle, for maximum flexibility and performance. Using a two-level configuration register scheme ensures that when a (part of) a -particular configuration is reused in more then one sequencer instruction, it +particular configuration is reused in more than one sequencer instruction, it does not have to be duplicated entirely. Only the index pointing to the right configuration register (which is a lot smaller) is duplicated in multiple sequencer instructions. This does of course limit the amount of different @@ -50,42 +51,45 @@ The Montium contains ten memories (two for each ALU). Each of these memories has its own Address Generation Unit (AGU), which can generate different memory address patterns. This means that the instructions or CRs never contain direct memory 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 from or written to in the same cycle). +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 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 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 +\subsubsection{Arithmetic and logic units} +The main processing elements of the Montium are its 5 arithmetic and +logic units (ALU). 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 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. -The ALU also has no internal registers, so data travels through the entire ALU +The ALU has no internal registers, so data travels through the entire ALU in a single cycle, to arrive at the outputs before the end of the cycle. This means that the ALU can perform a lot of computation in a single clock cycle. For -example, using four of the five ALU's, an FFT butterfly operation (two complex +example, using four of the five ALUs, an FFT butterfly operation (two complex multiplications and four complex additions) can be exected in a single clock cycle. The downside of this approach is that the data will have a long path to travel, which limits the clock speed of the design. -\subsubsection{CCU} -The CCU controls communication with the external world, usually a -NoC. During normal operations, the CCU can take values from the +\subsubsection{Communication and Configuration Unit} +The communication and configuration unit (CCU) controls communication +with the external world, usually a network-on-chip. During normal operations, the +CCU can take values from the interconnect and stream them out onto the NoC, or vice versa. Additionally, the CCU can be used from outside the Montium to start and stop execution and move configuration registers, sequencer instructions and memory contents into and out of the Montium. \subsubsection{Interconnect} -The central part of the Montium is the interconnect, which is a mostly connected -crossbar of lines. There are a total of 10 global busses in the interconnect, to -which every input and output port of the various components can be connected. -This way, every output of the memories, ALU's and CCU can be routed to every -input (provided that there are enough global busses). Additionally, each pair of -memories belonging to a specific ALU can be routed directly to the inputs and +The central part of the Montium is the interconnect, which is a crossbar +of lines, of which most are connected. There are a total of 10 global +busses in the interconnect, to which every input and output port of the +various components can be connected. This way, every output of the +memories, ALUs and CCU can be routed to every input, provided that +there are enough global busses. Additionally, each pair of memories +belonging to a specific ALU can be routed directly to the inputs and outputs of that ALU, without requiring a global bus. \subsection{Design changes} @@ -103,8 +107,9 @@ use all those function units in parallel, but since data only travels through only a single function unit in each cycle, this allows for much higher clock speeds than the old design. -During my internship I have mainly been working with the old Montium design, and -unless otherwise stated, that is what is meant when referring to the "Montium". -Some of the work has been done with the new design in mind, but only during the -final weeks of my internship I have been actually working with the new design. -See section \ref{Pipelining} for more details. +During my internship I have mainly been working with the old Montium +design, and unless otherwise stated, that is what is meant when +referring to the "Montium". Some of the work has been done with the new +design in mind, but I have been actually working with the new design +only during the final weeks of my internship. See section +\ref{Pipelining} for more details. diff --git a/Report/Main/Context/MontiumC.tex b/Report/Main/Context/MontiumC.tex index d563209..e9eb3bf 100644 --- a/Report/Main/Context/MontiumC.tex +++ b/Report/Main/Context/MontiumC.tex @@ -16,23 +16,28 @@ 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 diff --git a/Report/Main/Context/Recore.tex b/Report/Main/Context/Recore.tex index ca96fb1..8203ca1 100644 --- a/Report/Main/Context/Recore.tex +++ b/Report/Main/Context/Recore.tex @@ -4,16 +4,18 @@ 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 power, high performance reconfigurable processor aimed at low-power DSP -applications. The Montium will be discussed in more detail in the next section. +applications. The Montium will be discussed in more detail in section +\ref{Montium}. 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 at -the University of Twente. +them such as a compiler, an integrated development environment (IDE) and +simulation environments and sample programs and digital signal +processing (DSP) libraries to ease application development. Currently, +all of these 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 -into three disciplines: Hardware design, tooling development and DSP -engineering. This distinction is not a very strict or physical one: most work is -the result of a coordinated effort. +The activities of Recore and the employees working on them are roughly +divided into three disciplines: Hardware design, tooling development and +DSP engineering. This distinction is not a very strict or physical one: +most work is the result of a coordinated effort. diff --git a/Report/Main/Future.tex b/Report/Main/Future.tex index 8bc81f5..bfa737a 100644 --- a/Report/Main/Future.tex +++ b/Report/Main/Future.tex @@ -1,6 +1,7 @@ \chapter{Future work} \label{FutureWork} -This chapter will describe outstanding tasks and issues. +This chapter will describe tasks for the future and issues that remain +to be resolved. \section{Verifiers} Currently, when faulty MontiumC is written, this will be detected very late in @@ -43,7 +44,7 @@ backend would benefit from being able to use existing LLVM code and passes, utility code, etc. Also, this would enable the compiler to become a single 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 +However, the main risk here is that the LLVM framework might turn 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 LLVM code than diff --git a/Report/Main/Introduction.tex b/Report/Main/Introduction.tex index e761bc6..c9c9400 100644 --- a/Report/Main/Introduction.tex +++ b/Report/Main/Introduction.tex @@ -15,8 +15,8 @@ Systems, their products and the tools I have been using. The second chapter provides an overview of the assignment and the challenges faced when completing it. -The third chapter lists a number of tasks that are still unfinished and future -work. +The third chapter lists a number of tasks that are still unfinished and +proposes future work. -The last chapter provides a number of conclusions about my internship and the +The last chapter contains a number of conclusions about my internship and the work performed. diff --git a/Report/Main/Problems/Assignment.tex b/Report/Main/Problems/Assignment.tex index b87711c..876e8f2 100644 --- a/Report/Main/Problems/Assignment.tex +++ b/Report/Main/Problems/Assignment.tex @@ -1,5 +1,5 @@ \section{Assignment} -During my internship, my assignment has been to improve the frontend. In +During my internship, my assignment has been to improve the MontiumC compiler frontend. In particular, instead of using the complete frontend supplied by the LLVM project unmodified, a local version was to be created with a number of Montium-specific changes and transformations. diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex index b92430b..1fccb19 100644 --- a/Report/Main/Problems/Challenges.tex +++ b/Report/Main/Problems/Challenges.tex @@ -12,12 +12,12 @@ was ``whatever the compiler eats''. To be able to create a proper set of transformations, the constraints on the input and output of that transformation process should be properly specified. This entails two parts: Specifying the MontiumC language, and specifying the -Montium IR constraints, which is is the input to the backend. +Montium IR constraints, which is the input to the backend. Specifying Montium IR was relatively easy, since it is defined directly by the -backend. The MontiumC specification is slightly more complex. There are two +backend. The MontiumC specification was slightly more complex. There are two different angles to it: What does the compiler support, and what do we want the -compiler to support. +compiler to support? \subsubsection{What is supported?} One angle for looking at MontiumC is seeing what the compiler can currently @@ -34,7 +34,7 @@ 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 the specification. This way, any code operating outside of the specification -can be detected automatically. Writing such checks has not happened yet, mainly +can be detected automatically. Writing such checks has not happened so far, mainly because the impact of the new hardware on MontiumC is not quite clear yet. Existing transformations, on the other hand, might miss a few corner cases. When @@ -49,8 +49,8 @@ specification. This way, corner cases exposed by the testing code can be detected automatically. A framework for this testing has been set up and partially filled with small tests. -Building this initial specification did pose a number of challenges. Since -simply trying all possible C features to see if they are accepted by the +Building this initial specification did pose a number of challenges. +Simply trying all possible C features to see if they are accepted by the MontiumC compiler and thus valid MontiumC is a lengthy process and only useful in a limited way. A more constructive way would be to examine the compiler components to see what transformations are applied and from that derive the @@ -69,7 +69,7 @@ specification of MontiumC, since the base specification only supports a few C features. \subsubsection{What is wanted?} -A completely different angle of looking at this is from the requirements point +A completely different angle of looking at this specification is from the requirements point of view. What do we want MontiumC to support? This angle is even harder than the previous one, since there are a lot of levels of requirements. Ideally, MontiumC would not exist and our compiler would support the C language fully. However, @@ -83,7 +83,7 @@ anything is mappable, but with a simple compiler this will not result in the most efficient code. In the Montium case, a lot of things simply cannot be mapped on the hardware at all. -Considering that our ideal is not reachable (Though the new hardware might take +Considering that our ideal is not reachable (though the new hardware might take us a lot closer), every feature considered for MontiumC was evaluated thoroughly for feasibility, both in hardware and in the compiler. In practice, this meant that new language features would be @@ -118,7 +118,7 @@ out of the specification. It is not unlikely that the specification is still incorrect in a few places (or rather, that the code does not implement the specification properly). Since -so far there has been not any automated checking of programs against the +so far there has not been any automated checking of programs against the specification, these errors have not been uncovered. Once the new hardware is more clearly defined and the MontiumC specification is updated for it, this checking should be added so the specification and compiler can be better @@ -196,10 +196,10 @@ out rather hard (it's still not included currently). Working with this pass did prove very insightful, however, as to how the LLVM framework is built and what its possibilities are. -Additionally, during my working with the code in this internship I also produced +Additionally, during my working with the code during this internship I also produced a number of patches for LLVM, containing bugfixes, some cleanup and documentation improvements. Since the best way to integrate with any open source -project seems to be contributing code, I was giving commit access to the LLVM +project seems to be contributing code, I was given commit access to the LLVM tree not long thereafter. This access has proved very useful during the rest of the internship, since it was now a a lot easier to make (simple) changes to the LLVM framework to better suit the needs of Recore. @@ -210,7 +210,7 @@ Any changes that are directly required by the Montium frontend and the LLVM chan need are obvious. However, usually when making changes to the main LLVM tree, just changing enough for Recore is not engough for LLVM. Since the LLVM code must work on any program, not just MontiumC programs, extra changes are -required (see also parapgrah \ref{StayingGeneric}). This is also an issue of +required (see also parapgrah \ref{StayingGeneric}). Additionally, this is an issue of building up credit within the LLVM community: The more you contribute to LLVM, the more influence you have when things need changing. @@ -234,7 +234,7 @@ other one as well. Compiler changes also require hardware support, so working with the hardware developers was not uncommon either. In practice, most communication with the hardware developers went through the backend developer, except for the design discussion concerning the new Montium -hardware design (also see section \ref{Pipelining} below). +hardware design (also see section \ref{Pipelining}). In addition, discussions regarding design issues at various levels often happen out in the open, which invites people with an opinion about something to @@ -279,7 +279,7 @@ nodes. In a few more cases, the problems are still unresolved, effectively resulting in additional constraints on the MontiumC language. Examples of these are preventing instructions from being moved out of if/else blocks (which is -perfectly fine from an LLVM IR standpoint, but does not take into account the +perfectly fine from an LLVM IR point of view, but does not take into account the extra meaning that an if statement has in MontiumIR) and removal of unused bits from a constant (which could introduce more different constants than the Montium has registers for them). @@ -291,8 +291,8 @@ I've also been involved for a bit with the instruction scheduling algorithm required for the new (pipelined) hardware design and the hardware design itself. Even though this is completely outside of the area of my assignment, the initial prototype of that scheduler was created by someone else using LLVM. Because of -my experience with LLVM, I have been assisting him with that. Initially mostly -helping out with hints on LLVM coding, but later also with thinking about the +my experience with LLVM, I have been assisting him with it. Initially I +helped him by giving hints on LLVM coding, but later also with thinking about the scheduler and hardware design. I will not go into much detail about the new hardware and its scheduler here, @@ -339,14 +339,14 @@ first and last few iterations (the prologue and epilogue) are distinctly different from the loop "kernel", the number of instructions needed for a pipelined loop can easily increase a lot. -However, all pipelined loops share a very distinct structure (first +However, all pipelined loops share a very distinct structure: first stage 1, then stage 1+2, then stage 1+2+3, etc, then all stages at the -same time, similar for the epilogue). Also, every instruction in the +same time, similar for the epilogue. Also, every instruction in the prologue and epilogue are a strict subset of the instructions in the kernel. By adding some hardware support for exactly this structure, the code size increase for the prologue and epilogue can be effectively reduced to a fixed number of instructions (which take the number of stages as a -parameter and uses preloaded instructions with explicit stage annotation). +parameter and use preloaded instructions with explicit stage annotation). The tradeoff here is that this hardware is only usable specifically for these inner loops, any other code will leave this extra hardware unused. However, @@ -365,7 +365,7 @@ but those will be a lot smaller than the full instruction). On the new hardware, however, function calls are more powerful, which should lead to a lot less code duplication. For this reason, putting every instruction in configuration registers might actually take more space instead of less. It -should be noted that, the configuration registers of the old Montium are +should be noted that the configuration registers of the old Montium are effectively a compiler controlled cache that is mandatory and static (instructions must be in the cache and the cache cannot be modified at runtime). By lifting these limitations, we get a cache that is a lot more flexible. diff --git a/Report/Main/Problems/Results.tex b/Report/Main/Problems/Results.tex index 901472d..dbdda0b 100644 --- a/Report/Main/Problems/Results.tex +++ b/Report/Main/Problems/Results.tex @@ -12,15 +12,15 @@ lot of small fixes and changes to make LLVM more flexible and extendable. \subsection{MontiumC improvements} Improvements made to the MontiumC language are mostly limited to making the langauge better specified. Things which had limited support now either have full -support, or were removed from the language. +support or were removed from the language. -Usage of global variables, struct variables, arguments and returns values and +Usage of global variables, struct variables, arguments and return values and constant arguments is now possible in most cases, where it only was possible in some specific cases before. Additionally, there has been some experimenting with new MontiumC features, such as C style memory access and loops. So far, these features have not received -enough work in both the frontend as the backend to be supported in the language +enough work in both the frontend and the backend to be supported in the language yet. \subsection{Frontend improvements} -- 2.30.2