DOCSLIB.ORG

Retargeting a C Compiler for a DSP Processor

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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. This is called retargeting. This thesis describes how this was done with the LCC C compiler for the Motorola DSP56002 processor. Table of contents 1 Introduction 1 1.1 Background . 1 1.2 Purpose and goal. 1 1.3 The reader. 2 1.4 Reading guidelines . 2 2 DSP 3 2.1 Introduction . 3 2.2 Motorola DSP56002. 4 2.2.1 Data buses . 5 2.2.2 Address buses. 5 2.2.3 Data ALU . 5 2.2.4 Address generation unit . 5 2.2.5 Program control unit . 6 2.3 Instruction set . 6 2.4 Assembly . 6 3 Compilers 9 3.1 Introduction . 9 3.2 The analysis-synthesis model . 9 3.3 Phases . 10 3.4 Analysis . 11 3.4.1 Lexical analysis. 11 3.4.2 Syntax analysis . 11 3.4.3 Semantic analysis . 14 3.5 Synthesis. 15 3.5.1 Intermediate code generation . 15 3.5.2 Code optimization . 16 3.5.3 Code generation . 18 3.6 Symbol table. 18 3.7 Error handler . 19 3.8 Front and back end . 19 3.9 Environment . 20 ix 3.9.1 Preprocessor . 20 3.9.2 Assembler . 20 3.9.3 Linker and loader. 21 3.10 Compiler tools . 21 4 LCC 23 4.1 Introduction . 23 4.2 C. 24 4.3 The compiler . 24 4.3.1 Lexical analysis. 24 4.3.2 Syntax analysis . 26 4.3.3 Semantic analysis . 29 4.3.4 Intermediate code generation . 29 4.3.5 Back end . 30 5 Implementation 33 5.1 Introduction . 33 5.2 The compiler . 33 5.2.1 Data types and sizes . 34 5.2.2 Register usage. 35 5.2.3 Memory usage . 36 5.2.4 Frame layout. 37 5.2.5 Calling convention. 38 5.2.6 Naming convention . 39 5.3 Retargeting . 39 5.3.1 Configuration . 40 5.3.2 Declarations . 40 5.3.3 Rules. 40 5.3.4 C code . 40 5.4 Special features . 44 5.5 Other changes to LCC. 45 5.6 The environment . 45 5.7 crt0 . 46 5.8 Problems. 46 5.8.1 Register targeting. 46 5.8.2 48-bit registers . 48 5.8.3 Address registers . 48 5.9 Improvements . 49 6 Conclusions 51 6.1 Retargeting . 51 6.2 Future work . 51 References 53 x Table of contents Appendix A: Instructions 55 A.1 Arithmetic instructions . 55 A.2 Logical instructions . 56 A.3 Bit manipulation instructions . 57 A.4 Loop instructions . 57 A.5 Move instructions . 57 A.6 Program control instructions . 58 Appendix B: Sample code 59 B.1 sample.c . 59 B.2 sample.asm . 60 Appendix C: dsp56k.md 61 Index 79 xi xii 1 Introduction 1.1 Background The division of Electronics Systems (ES) at the department of Electri- cal Engineering (ISY) at Linköping University (LiU) is currently run- ning a project aiming at developing a DSP processor. The goal of this project is to make a DSP with a scalable structure that is instruction level compatible with the Motorola DSP56002 processor. The scalabil- ity refers to variable data word length and addition or removal of memories and instructions. The goal with scalability is to reduce the power consumption. Currently this project is nearly finished. In order to increase the usabil- ity of the DSP a C compiler is needed. It was decided that the best way to create a C compiler was to retarget an existing C compiler. Creating a compiler from scratch is a big undertaking that requires a lot of work. Retargeting a compiler is a rel- atively easy task compared to developing an entire compiler. 1.2 Purpose and goal The purpose of this thesis is to retarget a C compiler to the Motorola DSP56002 processor. The resulting compiler should from one or more C source files produce an executable file that can execute on the DSP. The only requirement on the compiler is that it should generate code 1 1.3 – The reader that works correctly and functions as intended. There are no require- ments on the performance or the size of the generated code. The compiler should also be compatible with Motorola’s C compiler and tools for the DSP56002. This makes it possible to mix generated code from the two compilers. It also means that the tools from Motorola can be used for the new compiler. 1.3 The reader It is assumed that the reader of this thesis has basic knowledge of the C programming language and some knowledge of assembly lan- guage. It is also assumed that the reader has a general knowledge of how processors work and what function a compiler has. 1.4 Reading guidelines This is a brief description of the chapters: • Chapter 1 contains an introduction and states the purpose of the thesis. • Chapter 2 describes how the DSP56002 processor works and how it can be used. • Chapter 3 contains general compiler theory that is needed to understand how a compiler works. • Chapter 4 describes the compiler LCC that was used in this thesis. • Chapter 5 describes the implementation and modifications that were done to LCC. • Chapter 6 lists the conclusions that were made and suggests fur- ther work. 2 2 DSP This chapter contains a description of how the Motorola DSP56002 processor works. This information is collected from [4]. 2.1 Introduction Digital signal processing is, as the term suggests, the processing of sig- nals by digital means. The signal is normally an electrical signal car- ried on a wire, but it can represent almost any kind of information and it can be processed in a wide variety of ways. Examples of digital sig- nal processing include the following: • Filtering of signals. • Convolution, which is the mixing of two signals. • Correlation, which is the comparison of two signals. • Rectification, amplification and transformation of a signal. All of these tasks have earlier been performed by using analog cir- cuits. Nowadays integrated circuits have enough processing power to perform these and many other functions. The devices performing these tasks are called.
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]
  • 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]
  • Instrew: Leveraging LLVM for High Performance Dynamic Binary Instrumentation
    Instrew: Leveraging LLVM for High Performance Dynamic Binary Instrumentation Alexis Engelke Martin Schulz Technical University of Munich {engelke,schulzm}@in.tum.de Abstract ACM Reference Format: Dynamic binary instrumentation frameworks are popular Alexis Engelke and Martin Schulz. 2020. Instrew: Leveraging LLVM tools to enhance programs with additional analysis, debug- for High Performance Dynamic Binary Instrumentation. In 16th ACM SIGPLAN/SIGOPS International Conference on Virtual Execu- ging, or profiling facilities or to add optimizations or trans- tion Environments (VEE ’20), March 17, 2020, Lausanne, Switzerland. lations without requiring recompilation or access to source ACM, New York, NY, USA, 13 pages. https://doi.org/10.1145/3381052. code. They analyze the binary code, translate into a—typically 3381319 low-level—intermediate representation, add the needed in- strumentation or transformation and then generate new code on-demand and at run-time. Most tools thereby focus on a fast code rewriting process at the cost of lower quality code, 1 Introduction leading to a significant slowdown in the instrumented code. Tools for rewriting binaries dynamically at run-time are fre- Further, most tools run in the application’s address space, quently used for program analysis, debugging and portability. making their development cumbersome. During rewriting, such tools may also add additional instru- We propose a novel dynamic binary instrumentation frame- mentation code to perform their analysis, code specialization work, Instrew, which closes these gaps by (a) leveraging the or even code translation. The advantage over adding such LLVM compiler infrastructure for high-quality code opti- transformations at compile-time lies in the fact that instru- mization and generation and (b) enables process isolation mentation is possible on the fly and without recompiling the between the target code and the instrumenter.
    [Show full text]