DOCSLIB.ORG

Retargeting a C Compiler to the HAPRA/FAPRA Architecture

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Retargeting a C Compiler to the HAPRA/FAPRA Architecture Institute of Computer Architecture and Computer Engineering University of Stuttgart Pfaffenwaldring 47 D{70569 Stuttgart Diplomarbeit Nr. 2980 Retargeting a C compiler to the HAPRA/FAPRA architecture Tilmann Scheller Course of Study: Software Engineering Examiner: Prof. Dr. Hans-Joachim Wunderlich Supervisor: Dipl.-Ing. Christian Z¨ollin Dipl.-Inform. Melanie Elm Commenced: October 19, 2009 Completed: April 20, 2010 CR-Classification: C.0, C.4, D.3.4 Abstract The HAPRA and FAPRA architectures are simple 32-bit RISC architectures which are used for educational purposes. Without a compiler for a high-level language, software for the HAPRA/- FAPRA architecture needs to be written in assembly language. This is un- fortunate since writing software in assembly language is time-consuming, error-prone and results in unportable software. The goal of this thesis is to develop a complete C-based toolchain for the HAPRA/FAPRA architecture, including an assembler, a C compiler and porting a C standard library. The resulting toolchain is used to compare the different subsets of the HAPRA/FAPRA instruction set in terms of runtime performance and space efficiency. With the availability of a C compiler for the target architecture it is significantly easier to measure the impact of extensions or modifications of the existing instruction set. A wide spectrum of portable open source software exists today. The avail- ability of a C-based toolchain for the HAPRA/FAPRA architecture enables, at one go, access to this large software stack. It is expected that this toolchain will be used to port a full operating system to the HAPRA/FAPRA archi- tecture. The ability of running an entire operating system is also likely to be a great motivator for students designing their own custom implementations of the HAPRA/FAPRA architecture as part of their lab courses. 3 4 Contents 1 Introduction 13 2 Architecture & Compiler Fundamentals 15 2.1 Instruction set architecture.................... 15 2.1.1 FAPRA architecture................... 15 2.1.2 HAPRA architecture................... 18 2.1.3 HASE/Angora...................... 20 2.2 Compiler pipeline......................... 21 2.2.1 Frontend.......................... 22 2.2.2 Middle-end........................ 23 2.2.3 Backend.......................... 24 2.3 LLVM Compiler Infrastructure.................. 25 2.3.1 Overview......................... 25 2.3.2 C frontend......................... 26 2.3.3 Intermediate representations............... 26 2.3.4 Target-independent code generator........... 28 3 Implementation 31 3.1 Application Binary Interface................... 31 3.2 HAPRA/FAPRA backend.................... 33 3.2.1 Overview......................... 34 3.2.2 Machine description................... 38 3.3 C frontend............................. 39 3.4 C standard library........................ 39 3.5 Assembler............................. 40 3.6 Simulator............................. 40 3.7 Linker............................... 42 4 Results 43 4.1 Example.............................. 43 4.2 Measurements........................... 46 4.2.1 Instruction count..................... 46 4.2.2 Code size......................... 48 4.3 Simulator............................. 50 4.4 Experience............................. 52 4.5 Remarks.............................. 52 5 Conclusion & Future Work 55 5 A Appendix 57 6 List of Figures 1 The HASE GUI.......................... 20 2 The compiler pipeline....................... 21 3 The LLVM architecture...................... 26 4 The target-independent code generator architecture....... 28 5 The HAPRA/FAPRA ABI stack frame layout.......... 32 6 The newlib architecture...................... 40 7 The libcpu architecture...................... 41 8 Comparing the number of executed instructions between HAPRA and FAPRA............................ 48 9 Comparing the binary size of benchmarks compiled for HAPRA and FAPRA............................ 50 7 8 List of Tables 1 The FAPRA instruction set architecture............. 17 2 The HAPRA instruction set architecture............. 19 3 Registers in the HAPRA/FAPRA ABI.............. 32 4 Size and alignment of scalar data types on the FAPRA archi- tecture with byte-addressing.................... 33 5 Size and alignment of scalar data types on the FAPRA archi- tecture with word-addressing and on the HAPRA architecture. 34 6 The Stanford benchmark suite.................. 46 7 The Computer Language Shootout benchmark suite...... 47 8 Instruction distribution when executing hello.......... 49 9 Executing the Stanford benchmark suite on simulators..... 51 10 Executing the Computer Language Shootout benchmark suite on simulators............................ 51 9 10 Listings 1 Instruction format description in TableGen syntax....... 38 2 Instruction description in TableGen syntax........... 39 3 C source code of Mandelbrot example.............. 43 4 LLVM IR of Mandelbrot example................. 44 5 FAPRA assembly code of Mandelbrot example......... 45 11 12 1 Introduction The RISC processor architectures introduced in the undergraduate and grad- uate lab courses of the institute use a rather simple, nevertheless complete, instruction set (see table1 and2). While the programming environment features an assembly simulation and debugging environment, larger software projects would benefit from the availability of a compiler for a high-level language. The goal of this thesis is to develop a complete C-based toolchain for the HAPRA/FAPRA architecture, including an assembler, a C compiler and porting a C standard library. A wide spectrum of portable open source software exists today, with the Linux kernel being undisputedly among the most popular open source projects. The availability of a C-based toolchain for the HAPRA/FAPRA architecture enables, at one go, access to a large software stack, which, once the initial work of porting the Linux kernel is done, can be run with minimal effort. Without a compiler for a high-level language, software for the HAPRA/- FAPRA architecture needs to be written in assembly language. This is un- fortunate since writing software in assembly language is time-consuming, error-prone and results in unportable software. It is expected that this toolchain will be used to port the µClinux [uCl] kernel and userspace to the HAPRA/FAPRA architecture, making it possi- ble to run a full operating system on the hardware. This has the nice side effect that students which design custom implementations of the HAPRA/- FAPRA architecture as part of their lab courses, get the ability to run a whole operating system on their hardware, which is expected to be a great motivator for them. With the availability of a C compiler for the target architecture it is significantly easier to compare the different subsets of the HAPRA/FAPRA instruction set in terms of runtime performance and space efficiency and to measure the effect of extensions or modifications of the existing instruction set. This thesis is organized as follows: Chapter2 describes the the HAPRA/- FAPRA architecture, the compiler pipeline and the compiler framework used in this thesis. Chapter3 discusses the implementation of the toolchain for the HAPRA/FAPRA architecture. Chapter4 presents results of measure- ments, the experiences made during the implementation of the toolchain and suggestions on how to improve the HAPRA/FAPRA architecture. Chapter5 draws a conclusion and gives an outlook on future work. 13 14 2 Architecture & Compiler Fundamentals This chapter describes the HAPRA and FAPRA instruction set architectures (ISA), presents a brief overview of the compilation process and introduces the Low Level Virtual Machine (LLVM) Compiler Infrastructure. 2.1 Instruction set architecture This section describes the HAPRA and FAPRA architecture and their re- spective assembly language development environments. 2.1.1 FAPRA architecture The FAPRA architecture is a simple 32-bit RISC architecture, which was designed for educational purposes. The instruction set encompasses 29 dif- ferent instructions which can be divided into 5 instruction classes: load/store instructions, load immediate instructions, control flow instructions, arith- metic/logical instructions and comparison instructions. Table1 shows the FAPRA ISA. SIMD-variants of the architecture also exist, which allow operations on vectors of two or four 32-bit integers, increasing the data-parallelism respec- tively. The memory transfer size is not widened in the SIMD-variants and is always 32-bit, thus loading an arbitrary 128-bit value from memory requires four load instructions and additional instructions to place the individual vec- tor elements at the desired positions within the destination vector register. As the native word size is 32-bit, there is a register file consisting of 32 registers with a width of 32-bit, except for the SIMD-variants where the registers are 64-bit or 128-bit wide, forming a unified register file which con- tains both scalar and vector values. The program counter is stored in a dedicated register which can only be read/written implicitly, e.g. through certain control flow instructions. A special status register with flags for re- sults of arithmetic/logical instructions does not exist, instead comparison instructions compute their results directly into their destination register. There are no native floating-point instructions, floating-point operations need to be implemented in software. As usual for RISC architectures, instructions have a fixed width of 32-bit in order to simplify the decoding and prefetching
Load more

Recommended publications
  • Resourceable, Retargetable, Modular Instruction Selection Using a Machine-Independent, Type-Based Tiling of Low-Level Intermediate Code
    Reprinted from Proceedings of the 2011 ACM Symposium on Principles of Programming Languages (POPL’11) Resourceable, Retargetable, Modular Instruction Selection Using a Machine-Independent, Type-Based Tiling of Low-Level Intermediate Code Norman Ramsey Joao˜ Dias Department of Computer Science, Tufts University Department of Computer Science, Tufts University [email protected] [email protected] Abstract Our compiler infrastructure is built on C--, an abstraction that encapsulates an optimizing code generator so it can be reused We present a novel variation on the standard technique of selecting with multiple source languages and multiple target machines (Pey- instructions by tiling an intermediate-code tree. Typical compilers ton Jones, Ramsey, and Reig 1999; Ramsey and Peyton Jones use a different set of tiles for every target machine. By analyzing a 2000). C-- accommodates multiple source languages by providing formal model of machine-level computation, we have developed a two main interfaces: the C-- language is a machine-independent, single set of tiles that is machine-independent while retaining the language-independent target language for front ends; the C-- run- expressive power of machine code. Using this tileset, we reduce the time interface is an API which gives the run-time system access to number of tilers required from one per machine to one per archi- the states of suspended computations. tectural family (e.g., register architecture or stack architecture). Be- cause the tiler is the part of the instruction selector that is most dif- C-- is not a universal intermediate language (Conway 1958) or ficult to reason about, our technique makes it possible to retarget an a “write-once, run-anywhere” intermediate language encapsulating instruction selector with significantly less effort than standard tech- a rigidly defined compiler and run-time system (Lindholm and niques.
    [Show full text]
  • The LLVM Instruction Set and Compilation Strategy
    The LLVM Instruction Set and Compilation Strategy Chris Lattner Vikram Adve University of Illinois at Urbana-Champaign lattner,vadve ¡ @cs.uiuc.edu Abstract This document introduces the LLVM compiler infrastructure and instruction set, a simple approach that enables sophisticated code transformations at link time, runtime, and in the field. It is a pragmatic approach to compilation, interfering with programmers and tools as little as possible, while still retaining extensive high-level information from source-level compilers for later stages of an application’s lifetime. We describe the LLVM instruction set, the design of the LLVM system, and some of its key components. 1 Introduction Modern programming languages and software practices aim to support more reliable, flexible, and powerful software applications, increase programmer productivity, and provide higher level semantic information to the compiler. Un- fortunately, traditional approaches to compilation either fail to extract sufficient performance from the program (by not using interprocedural analysis or profile information) or interfere with the build process substantially (by requiring build scripts to be modified for either profiling or interprocedural optimization). Furthermore, they do not support optimization either at runtime or after an application has been installed at an end-user’s site, when the most relevant information about actual usage patterns would be available. The LLVM Compilation Strategy is designed to enable effective multi-stage optimization (at compile-time, link-time, runtime, and offline) and more effective profile-driven optimization, and to do so without changes to the traditional build process or programmer intervention. LLVM (Low Level Virtual Machine) is a compilation strategy that uses a low-level virtual instruction set with rich type information as a common code representation for all phases of compilation.
    [Show full text]
  • Automatic Isolation of Compiler Errors
    Automatic Isolation of Compiler Errors DAVID B.WHALLEY Flor ida State University This paper describes a tool called vpoiso that was developed to automatically isolate errors in the vpo com- piler system. The twogeneral types of compiler errors isolated by this tool are optimization and nonopti- mization errors. When isolating optimization errors, vpoiso relies on the vpo optimizer to identify sequences of changes, referred to as transformations, that result in semantically equivalent code and to pro- vide the ability to stop performing improving (or unnecessary) transformations after a specified number have been performed. Acompilation of a typical program by vpo often results in thousands of improving transformations being performed. The vpoiso tool can automatically isolate the first improving transforma- tion that causes incorrect output of the execution of the compiled program by using a binary search that varies the number of improving transformations performed. Not only is the illegaltransformation automati- cally isolated, but vpoiso also identifies the location and instant the transformation is performed in vpo. Nonoptimization errors occur from problems in the front end, code generator,and necessary transforma- tions in the optimizer.Ifanother compiler is available that can produce correct (but perhaps more ineffi- cient) code, then vpoiso can isolate nonoptimization errors to a single function. Automatic isolation of compiler errors facilitates retargeting a compiler to a newmachine, maintenance of the compiler,and sup- porting experimentation with newoptimizations. General Terms: Compilers, Testing Additional Key Words and Phrases: Diagnosis procedures, nonoptimization errors, optimization errors 1. INTRODUCTION To increase portability compilers are often split into twoparts, a front end and a back end.
    [Show full text]
  • Automatic Derivation of Compiler Machine Descriptions
    Automatic Derivation of Compiler Machine Descriptions CHRISTIAN S. COLLBERG University of Arizona We describe a method designed to significantly reduce the effort required to retarget a compiler to a new architecture, while at the same time producing fast and effective compilers. The basic idea is to use the native C compiler at compiler construction time to discover architectural features of the new architecture. From this information a formal machine description is produced. Given this machine description, a native code-generator can be generated by a back-end generator such as BEG or burg. A prototype automatic Architecture Discovery Tool (called ADT) has been implemented. This tool is completely automatic and requires minimal input from the user. Given the Internet address of the target machine and the command-lines by which the native C compiler, assembler, and linker are invoked, ADT will generate a BEG machine specification containing the register set, addressing modes, instruction set, and instruction timings for the architecture. The current version of ADT is general enough to produce machine descriptions for the integer instruction sets of common RISC and CISC architectures such as the Sun SPARC, Digital Alpha, MIPS, DEC VAX, and Intel x86. Categories and Subject Descriptors: D.2.7 [Software Engineering]: Distribution, Maintenance, and Enhancement—Portability; D.3.2 [Programming Languages]: Language Classifications— Macro and assembly languages; D.3.4 [Programming Languages]: Processors—Translator writ- ing systems and compiler generators General Terms: Languages Additional Key Words and Phrases: Back-end generators, compiler configuration scripts, retargeting 1. INTRODUCTION An important aspect of a compiler implementation is its retargetability.For example, a new programming language whose compiler can be quickly retar- geted to a new hardware platform or a new operating system is more likely to gain widespread acceptance than a language whose compiler requires extensive retargeting effort.
    [Show full text]
  • Building Linux Applications Using RVDS 3.0 and the GNU Tools and Libraries
    Application Note 150 Building Linux Applications Using RVDS 3.0 and the GNU Tools and Libraries Released on: September, 2006 Copyright © 2005-2006. All rights reserved. DAI0150B Application Note 150 Application Note 150 Building Linux Applications Using RVDS 3.0 and the GNU Tools and Libraries Copyright © 2005-2006. All rights reserved. Release Information The following changes have been made to this application note. Table 1 Change history Date Issue Change April 2006 A First release for RVDS 3.0 September 2006 B Second release for RVDS 3.0 SP1 Proprietary Notice Words and logos marked with ® and ™ are registered trademarks owned by ARM Limited, except as otherwise stated below in this proprietary notice. Other brands and names mentioned herein may be the trademarks of their respective owners. Neither the whole nor any part of the information contained in, or the product described in, this document may be adapted or reproduced in any material form except with the prior written permission of the copyright holder. The product described in this document is subject to continuous developments and improvements. All particulars of the product and its use contained in this document are given by ARM in good faith. However, all warranties implied or expressed, including but not limited to implied warranties of merchantability, or fitness for purpose, are excluded. This document is intended only to assist the reader in the use of the product. ARM Limited shall not be liable for any loss or damage arising from the use of any information in this document, or any error or omission in such information, or any incorrect use of the product.
    [Show full text]
  • Totalprof: a Fast and Accurate Retargetable Source Code Profiler
    TotalProf: A Fast and Accurate Retargetable Source Code Profiler Lei Gao, Jia Huang, Jianjiang Ceng, Rainer Leupers, Gerd Ascheid, and Heinrich Meyr Institute for Integrated Signal Processing Systems RWTH Aachen University, Germany {gao,leupers}@iss.rwth-aachen.de ABSTRACT 1. INTRODUCTION Profilers play an important role in software/hardware de- Profiling is deemed of pivotal importance for embedded sign, optimization, and verification. Various approaches system design. On the one hand, profiles obtained from re- have been proposed to implement profilers. The most alistic workloads are indispensable in application, processor, widespread approach adopted in the embedded domain is and compiler design. On the other hand, profile-based pro- Instruction Set Simulation (ISS) based profiling, which pro- gram optimization (e.g., [5]) and parallelization (e.g., [7]) vides uncompromised accuracy but limited execution speed. play an increasingly important role in harnessing the pro- Source code profilers, on the contrary, are fast but less accu- cessing power of embedded processors. However, current rate. This paper introduces TotalProf, a fast and accurate profiling techniques face two major challenges: First, the source code cross profiler that estimates the performance stringent time-to-market pressure and the increasing com- of an application from three aspects: First, code optimiza- plexity of applications and systems require profiling tools to tion and a novel virtual compiler backend are employed to be fast and quickly available, so that they can be employed resemble the course of target compilation. Second, an opti- as early as possible in the evaluation of design variants. Sec- mistic static scheduler is introduced to estimate the behav- ond, the accuracy of profiles is imperative to capture the ior of the target processor’s datapath.
    [Show full text]
  • Retargeting a C Compiler for a DSP Processor
    Retargeting a C Compiler for a DSP Processor Master thesis performed in electronics systems by Henrik Antelius LiTH-ISY-EX-3595-2004 Linköping 2004 Retargeting a C Compiler for a DSP Processor Master thesis in electronics systems at Linköping Institute of Technology by Henrik Antelius LiTH-ISY-EX-3595-2004 Supervisors: Thomas Johansson Ulrik Lindblad Patrik Thalin Examiner: Kent Palmkvist Linköping, 2004-10-05 Avdelning, Institution Datum Division, Department Date 2004-10-05 Institutionen för systemteknik 581 83 LINKÖPING Språk Rapporttyp ISBN Language Report category Svenska/Swedish Licentiatavhandling ISRN LITH-ISY-EX-3595-2004 X Engelska/English X Examensarbete C-uppsats Serietitel och serienummer ISSN D-uppsats Title of series, numbering Övrig rapport ____ URL för elektronisk version http://www.ep.liu.se/exjobb/isy/2004/3595/ Titel Anpassning av en C-kompilator för kodgenerering till en DSP-processor Title Retargeting a C Compiler for a DSP Processor Författare Henrik Antelius Author Sammanfattning Abstract The purpose of this thesis is to retarget a C compiler for a DSP processor. Developing a new compiler from scratch is a major task. Instead, modifying an existing compiler so that it generates code for another target is a common way to develop compilers for new processors. This is called retargeting. This thesis describes how this was done with the LCC C compiler for the Motorola DSP56002 processor. Nyckelord Keyword retarget, compiler, LCC, DSP Abstract The purpose of this thesis is to retarget a C compiler for a DSP proces- sor. Developing a new compiler from scratch is a major task. Instead, modifying an existing compiler so that it generates code for another target is a common way to develop compilers for new processors.
    [Show full text]
  • Design and Implementation of a Tricore Backend for the LLVM Compiler Framework
    Design and Implementation of a TriCore Backend for the LLVM Compiler Framework Studienarbeit im Fach Informatik vorgelegt von Christoph Erhardt geboren am 14.11.1984 in Kronach Angefertigt am Department Informatik Lehrstuhl fur¨ Informatik 4 { Verteilte Systeme und Betriebssysteme Friedrich-Alexander-Universit¨at Erlangen-Nurnberg¨ Betreuer: Prof. Dr.-Ing. habil. Wolfgang Schr¨oder-Preikschat Dipl.-Inf. Fabian Scheler Beginn der Arbeit: 01. Dezember 2008 Ende der Arbeit: 01. September 2009 Hiermit versichere ich, dass ich die Arbeit selbstst¨andig und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ¨ahnlicher Form noch keiner anderen Prufungsbeh¨ ¨orde vorgelegen hat und von dieser als Teil einer Prufungsleistung¨ angenommen wurde. Alle Stellen, die dem Wortlaut oder dem Sinn nach anderen Werken entnommen sind, habe ich durch Angabe der Quelle als Entlehnung kenntlich gemacht. Erlangen, den 01. September 2009 Uberblick¨ Diese Arbeit beschreibt die Entwicklung und Implementierung eines neuen Backends fur¨ das LLVM-Compiler-Framework, um das Erzeugen von Maschinencode fur¨ die TriCore- Prozessorarchitektur zu erm¨oglichen. Die TriCore-Architektur ist eine fortschrittliche Plattform fur¨ eingebettete Systeme, welche die Merkmale eines Mikrocontrollers, einer RISC-CPU und eines digitalen Signal- prozessors auf sich vereint. Sie findet prim¨ar im Automobilbereich und anderen Echtzeit- systemen Verwendung und wird am Lehrstuhl fur¨ Verteilte Systeme und Betriebssysteme der Universit¨at Erlangen-Nurnberg¨ fur¨ diverse Forschungsprojekte eingesetzt. Bei LLVM handelt es sich um eine moderne Compiler-Infrastruktur, bei deren Ent- wurf besonderer Wert auf Modularit¨at und Erweiterbarkeit gelegt wurde. Aus diesem Grund findet LLVM zunehmend Verbreitung in den verschiedensten Projekten { von Codeanalyse-Werkzeugen uber¨ Just-in-time-Compiler bis hin zu vollst¨andigen Allzweck- Systemcompilern.
    [Show full text]
  • Modern Compiler Design 2E.Pdf
    Dick Grune • Kees van Reeuwijk • Henri E. Bal Ceriel J.H. Jacobs • Koen Langendoen Modern Compiler Design Second Edition Dick Grune Ceriel J.H. Jacobs Vrije Universiteit Vrije Universiteit Amsterdam, The Netherlands Amsterdam, The Netherlands Kees van Reeuwijk Koen Langendoen Vrije Universiteit Delft University of Technology Amsterdam, The Netherlands Delft, The Netherlands Henri E. Bal Vrije Universiteit Amsterdam, The Netherlands Additional material to this book can be downloaded from http://extras.springer.com. ISBN 978-1 - 4614 -4698 -9 ISBN 978-1-4614-4699-6 (eBook) DOI 10.1007/978-1 - 4614-4699-6 Springer New York Heidelberg Dordrecht London Library of Congress Control Number: 2012941168 © Springer Science+Business Media New York 2012 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Exempted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Duplication of this publication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location, in its current version, and permission for use must always be obtained from Springer. Permissions for use may be obtained through RightsLink at the Copyright Clearance Center.
    [Show full text]
  • Retargetable Compilers and Architecture Exploration for Embedded Processors
    Retargetable compilers and architecture exploration for embedded processors R. Leupers, M. Hohenauer, J. Ceng, H. Scharwaechter, H. Meyr, G. Ascheid and G. Braun Abstract: Retargetable compilers can generate assembly code for a variety of different target processor architectures. Owing to their use in the design of application-specific embedded processors, they bridge the gap between the traditionally separate disciplines of compiler construction and electronic design automation. In particular, they assist in architecture exploration for tailoring processors towards a certain application domain. The paper reviews the state-of-the-art in retargetable compilers for embedded processors. Based on some essential compiler background, several representative retargetable compiler systems are discussed, while also outlining their use in iterative, profiling-based architecture exploration. The LISATek C compiler is presented as a detailed case study, and promising areas of future work are proposed. 1 Introduction high-performance off-the-shelf processors from the desktop computer domain (together with their well developed Compilers translate high-level language source code into compiler technology) impossible for many applications. machine-specific assembly code. For this task, any compiler As a consequence, hundreds of different domain or even uses a model of the target processor. This model captures application-specific programmable processors have the compiler-relevant machine resources, including the appeared in the semiconductor market, and this trend instruction set, register files and instruction scheduling is expected to continue. Prominent examples include constraints. While in traditional target-specific compilers low-cost=low-energy microcontrollers (e.g. for wireless this model is built-in (i.e. it is hard-coded and probably sensor networks), number-crunching digital signal pro- distributed within the compiler source code), a retargetable cessors (e.g.
    [Show full text]
  • 15-411 Compiler Design: Lab 6 - LLVM Fall 2011
    15-411 Compiler Design: Lab 6 - LLVM Fall 2011 Instructor: Andre Platzer TAs: Josiah Boning and Ryan Pearl Compilers due: 11:59pm, Sunday, December 6, 2011 Term Paper due: 11:59pm, Thursday, December 8, 2011 1 Introduction The main goal of the lab is to explore advanced aspects of compilation. This writeup describes the option of retargeting the compiler to generate LLVM code; other writeups detail the option of implementing garbage collection or optimizing the generated code. The language L4 does not change for this lab and remains the same as in Labs 4 and 5. 2 Requirements You are required to hand in two separate items: (1) the working compiler and runtime system, and (2) a term paper describing and critically evaluating your project. 3 Testing You are not required to hand in new tests. We will use a subset of the tests from the previous labs to test your compiler. However, if you wish to use LLVM to optimize your code, consult the handout for lab6opt for guidelines on how to test your compiler, and what information should be added to the term paper. 4 Compilers Your compilers should treat the language L4 as in Labs 4 and 5. You are required to support safe and unsafe memory semantics. Note that safe memory semantics is technically a valid implemen- tation of unsafe memory semantics; therefore, if you have trouble getting the exception semantics of L4 working in a manner that corresponds directly to x86-64, use the safe semantics as a starting point, and try to remove as much of the overhead as you can.
    [Show full text]
  • Retargeting Open64 to a RISC Processor
    Retargeting Open64 to A RISC processor -- A Student’s Perspective Huimin Cui, Xiaobing Feng Key Laboratory of Computer System and Architecture, Institute of Computing Technology, CAS, 100190 Beijing, China {cuihm, fxb}@ict.ac.cn compiler [6]. Abstract Open64 has been retargeted to a number of This paper presents a student’s experience architectures. Pathscale modified Open64 to in Open64-Mips prototype development, we create EkoPath, a compiler for the AMD64 and summarize three retargeting observations. X8664 architecture. The University of Open64 is easy to be retargeted and the Delaware's Computer Architecture and Parallel procedure takes only a short period. With the Systems Laboratory (CAPSL) modified Open64 retarget procedure done, the compiler can to create the Kylin Compiler, a compiler for achieve good and stable performance. Open64 Intel's X-Scale architecture [1]. Besides the also provides many supports for debugging, with targets mentioned above, there are several other which a beginner can debug the compiler supported targets including PowerPC [6], without difficulty. We also share some NVISA [9], Simplight [10] and Qualcomm[11]. experiences of our retarget, including In this paper, we will discuss three issues methodology of verifying the compiler when retargeting Open64: ease of retarget, framework, attention to switches in Open64, performance, and debuggability. The discussion importance of debugging and reading generated is based on our work in retargeting Open64 to code. the MIPS platform, using the Simplight branch as our starting point, which is a RISC style DSP 1 Introduction with mixed 32/16 bit instruction set. During our discussion, we will use GCC (Mips target) for Open64 receives contributions from a comparison.
    [Show full text]