Low-Cost Memory Analyses for Efficient Compilers

Total Page:16

File Type:pdf, Size:1020Kb

Low-Cost Memory Analyses for Efficient Compilers Low-cost memory analyses for efficient compilers Maroua Maalej Kammoun To cite this version: Maroua Maalej Kammoun. Low-cost memory analyses for efficient compilers. Other [cs.OH]. Univer- sité de Lyon, 2017. English. NNT : 2017LYSE1167. tel-01626398v2 HAL Id: tel-01626398 https://tel.archives-ouvertes.fr/tel-01626398v2 Submitted on 11 Dec 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. No d’ordre NNT : 2017LYSE1167 THÈSE DE DOCTORAT DE L’UNIVERSITÉ DE LYON opérée au sein de l’Université Claude Bernard Lyon 1 École Doctorale ED512 InfoMaths Spécialité de doctorat : Informatique Soutenue publiquement le 26/09/2017, par : Maroua MAALEJ KAMMOUN Low-cost memory analyses for efficient compilers Devant le jury composé de : Xavier Urbain, Professeur des Universités, Université Claude Bernard Lyon 1 Examinateur Sanjay Rajopadhye, Professeur, Colorado State University Rapporteur Corinne Ancourt, Maître de Recherches, École supérieure des mines de Paris Rapporteure Alain Girault, Directeur de Recherches, Inria Examinateur Karine Heydemann, Maître de Conférences, Université Pierre et Marie Curie Examinatrice Vincent Loechner, Maître de Conférences, Université de Strasbourg Examinateur Frédéric Vivien, Directeur de Recherches, Inria Directeur de thèse Laure Gonnord, Maître de Conférences, Université Claude Bernard Lyon1 Co-directrice de thèse !" #$% &' & "# $ % &'( %) "# $ ''* "# $ %'*)' "# + **,' ! " "%( " *- ' . & 6 "# $ #3' " "/ *- ! . 6 " $ # &)**3( " 2 6 "# $ # &3 '3)! 3 4 6 " $ # )() ' ) ! &4 6 "# 7# '35 ) ! 5 6 " $ "# !%355 $ &4 % ! 5 4 6 "# # ' "%) &4 6 "# $ # 5%''( & 6 " # '*)7 ' 6 "# % %""3) ) $ 6 "# $ !# <<3%' " 6 "# $ # 53"(3 " 6 "# $ %# &'( %) - 6 "# $ = *'('5 ! 5 - ! 6 "# >#(3**' 3+ ! *- 6 "# &# )'3() - *- 6 "# $ '#')( ' ! - ' 6 "# # ) (*5 ) 5 4 *- 8 6 "# $ # )53( ' ! $ ' 6 "# $ # "3 ()355' ) ! 9 ; 6 "# (# *'&3)!(' Low-cost memory analyses for efficient compilers Remerciments Lors de la préparation et de la soutenance de ma thèse, j’ai bénéficié du soutien et de l’aide de plusieurs personnes. Par ces quelques lignes, je tiens à les remercier. Je voudrais remercier en premier lieu Laure Gonnord qui m’a encadrée tout au long de la thèse avec le sérieux et l’enthousiasme d’une directrice, la complicité d’une amie, et l’affection et la bienveillance d’une mère. Merci pour ses relectures nombreuses du manuscrit et pour la disponibilité dont elle a fait preuve tout au long de ce travail. Je remercie aussi Frédéric Vivien qui m’a accepté dans son équipe ROMA et m’a encadré pour la fin de cette thèse. J’exprime par la même occasion ma grande gratitude à Alain Darte, qui m’a intégré dans son équipe Compsys et assuré le début de ma thèse. Sans eux, cette thèse n’aurait jamais pu avoir lieu. Je tiens ensuite à remercier les membres du jury : merci à Xavier Urbain pour avoir accepté d’être président de mon jury de thèse. Merci aussi aux rapporteurs Sanjay Rajopadhye et Corinne Ancourt et aux examinateurs Alain Girault, Karine Heydemann et Vincent Loechner pour leurs lectures minucieuses du manuscrit et les remarques pertinentes qu’ils m’ont fait parvenir. Je tiens aussi à remercier Fernando Magno Quintão Pereira et Sylvain Collange. J’ai eu l’oppor- tunité d’avoir plusieurs collaborations avec Fernando et ses étudiants m’ont été d’une aide con- sidérable vis-à-vis de l’expertise que j’ai pu acquérir dans le compilateur LLVM. J’ai beaucoup apprécié mes interactions scientifiques avec Sylvain à travers lesquelles j’ai pu me familiariser aux GPUs et découvrir de nouvelles pistes d’applications des analyses de pointeurs. Je remercie également toutes les personnes qui ont indirectement contribué au bon déroulement de ce travail : Alexandre Isoard, mon premier et préféré collègue de bureau mais aussi l’ami qui, même après son départ, a su être là pour me motiver, me conseiller, et m’aider à surmonter des difficultés techniques ; Aurélien Cavelan et Oguz Kaya, mes collègues de bureau pour avoir partagé leur amour de travail, de persévérance et d’acharnement en fin de thèse. J’aimerais aussi exprimer ma profonde gratitude à tous les doctorants que j’ai pu croiser à un moment donné de ma thèse, pour la confiance qu’ils m’ont accordée pour les représenter au conseil du laboratoire et pour les moments de détente qu’on a pu partager ensemble (une pensée spéciale à Issam Rais pour tous les repas qu’on a partagés). Je n’oublie évidemment pas les assistantes des équipes du LIP : Laëtitia Lecot, Evelyne Blesle, Chiraz Benamor Marie Bozo et Sylvie Boyer. Immanquablement de bonne humeur, elles ont toujours des réponses à tout ! Enfin, je remercie bien sûr ma famille : Mes parents Ferdaous et Habib qui m’ont appris le goût de la réussite. Ils ont été toujours et depuis longtemps à mes côtés pour me soutenir, m’encourager et me combler d’amour. Mes deux sœurs, Sonia et Sirine, mes modèles de réussite et de persévérance. Mes beaux-parents Naama et Salah et mes belles-sœurs Yosra et Manel pour avoir cru en moi et m’avoir supportée. Finalement, je remercie à mon grand amour, Adam, d’avoir supporté la distance géographique qui nous séparait tout au long de la thèse, d’avoir accepté mes humeurs et mes doutes, et d’avoir géré mes indisponibilités et mes moments de travail les plus intenses. Maroua MAALEJ 3/142 Low-cost memory analyses for efficient compilers Maroua MAALEJ 4/142 Résumé long Les technologies de l’information sont devenues de plus en plus importantes dans nos vies quo- tidiennes, et maintenant nous vivons en grande partie ce qui a été extrapolé dans les oeuvres de littérature majeures de science fiction. Grâce à la production de massives machines puissantes, de nouvelles tablettes et smartphones, certaines tâches sont devenues moins complexes, et nous ont permis de gagner du temps. Néan- moins, dans le même temps, l’interaction entre les différents systèmes de calcul et d’informations eux-mêmes est devenue complexe, et la manipulation de tels systèmes nécessite de plus en plus une gestion automatisée et optimisée, et donc une meilleure compréhension des problématiques liées aux ressources de calcul et de mémoire, dont dépendent leur efficacité. L’évolution des performances des machines est allée de pair avec ce que l’on appelle “le saut performance-mémoire”. L’agrandissement des capacités de stockage mémoire n’a pas été accom- pagnée d’une diminution substantielle de la durée d’accès aux données. En conséquence, les temps d’accès à la mémoire sont maintenant non négligeables dans le coût d’un calcul. Un compilateur prend en entrée un programme écrit en un langage de haut niveau et génère le code bas niveau qui sera exécuté sur la machine cible. Un des moyens de rendre les programmes performants est de profiter de la rapidité des processeurs tout en diminuant le plus possible le besoin d’accéder à la mémoire. Pour cela, un compilateur peut effectuer des transformations (“optimisations”) plus ou moins automatiquement, à sémantique constante. Dans un compilateur, un des concepts cruciaux est la notion de dépendance entre les variables du programme : cette information sert à valider ou invalider une transformation donnée. Calculer efficacement ces dépendances reste un challenge dans les compilateurs, notamment à cause des problèmes d’aliasing induits par les variables pointeurs. Ces pointeurs sont en effet l’un des fondamentaux des langages de bas niveau comme le C car ils permettent au développeur de manipuler explicitement la mémoire. Ce sont des outils puissants et expressifs. Démontrer que deux pointeurs p et q sont disjoints (n’aliasent pas) permet de garantir qu’une écriture dans p ne modifie pas la valeur pointée par q. Dans le cas contraire, une modification de la région pointée par p a un impact “silencieux” (i.e. non détectable syntaxiquement en regardant les modifications apportées à q) sur q. Par conséquence, toute optimisation utilisant le fait qu’une dépendance de données n’est pas modifiée en changeant une lecture/écriture dans le programme doit vérifier qu’il n’y a pas de dépendance “cachée” par des pointeurs. Les optimisations de code faisant appel à une analyse d’alias sont donc nombreuses ; parmi elles on peut citer la vectorisation, l’élimination de code mort et le déplacement d’instructions dans le code. Ces optimisations sont cruciales à l’intérieur des compilateurs. Fournir aux passes d’optimisation des analyses d’alias précises et sûres (dépourvus de fausses alarmes, ce qui veut dire si l’analyse conclut que p et q sont disjoints, alors ils le sont réellement) est donc d’une extrême importance. Au sein d’un compilateur, une analyse de pointeurs peut être réalisée statiquement (sans exécuter Maroua MAALEJ 5/142 Low-cost memory analyses for efficient compilers le programme), dynamiquement (en exécutant une partie du code), ou de manière hybride. L’état de l’art des analyses statiques de pointeurs est pléthorique, depuis l’analyse d’Andersen [And94] jusqu’aux analyses les plus récentes telles que celle de Zhang et al. [Zha+14]. Les caractéristiques de ces analyses varient. Elles prennent plus ou moins en compte le flot de programme, le contexte d’appel des fonctions et les caractéristiques de structures, induisant des variations en terme de coût et de précision. Cependant, malgré toute l’attention accordée au sujet des analyses d’alias, notre état de l’art démontre que les analyses implémentées dans les compilateurs en production ont de nombreuses faiblesses lorsqu’il s’agit de prendre en compte l’arithmétique de pointeurs.
Recommended publications
  • @ LATTICE,INC. It Is
    @ LATTICE,INC. P. O. BOX 3072 ·GLENÉLLYN·LLNOIS 60138· 3l2/858ñ9!5OU1NX9lO29l-2l9O TECHNICAL BULLETIN TB841101.001 DATE: November 1, 1984 PRODUCT: 8086/8088 C Compiler SUBjECT: Known Bugs in Version 2.14 Recently three bugs concerning the Version 2.14 libraries and startup modules have come to light. Two of these pertain to the sensing and use of the 8087 co-processor, and the other concerns the use of the "malloc'° and "getmem" functions under MS-DOS 1 in the s and P models of the compiler. In addition some code was oMtted from the file " main.c". 1. Floating Point Bugs (a) Sensing cjf the 8087 The technique employed in the run-time library to sense the presence of the 8087 co-processor does not work in V2.14 because the 8087 is not initialized prior to the test. Correcting this problem is rather easy. You need only add a line of code to the file °'c.asm" provided with the compiler and reassemble this to replace the current "c.obj". file In the file "c.asm" you will find a line: CALL JLAIN just prior to this line, insert the fcülowing line DB ODBh,OE3h ; FNINIT instruction Then reassemble "c.asm" for each of the memory models as follows: -- Copy "c.asm" to the appropriate model subdirectory (i.e., \lc\s, \lc\d, \lc\p, or \lc\l) so that is in the same directory as "dos.mac" for it the appropriate memory mcdel. -- Use the command 1 @ LATTICE,1NC. W P. O. BOX 3Q72 ·GL£N ELLYN ·ILLNO1S 60138 · 312/858-7950·TWX9lO291-2 masm c; to assemble "c.asm" into "c.obj".
    [Show full text]
  • DECEMBER 1984 Editorial
    SECRET UJUJUVC!JUJUJlb f5l5CBl!JWVU~ !D~~WCB~ Cf l!l U1 v ffil! f] Ill~(! ffi g 00 (!{il C!J l! '7 00 {iJ U1 ~ [1{iJ w~ NOV-DEC 1984 EO 1. 4. (c) P .L. 86- 36 . TRENDS IN HF COMMUNICATIONS (U) •••••••••••• • ••• J.._ ___---..._.1. \\:>............ 1 • SWITCHBOARD: • PAST, PRESENT AND FUTURE (U) •• ~ ............. I • • \ I .......... 5 \ OUT OF MY DEPTH (U) .......................•............•...; .. i .. \ ... ·........ 7 . • • • • • • • • • • • • • • • • • • • • • • ! I ...\ .......... s 1 EXPLORING A DOS DISKETTE (U)................... I ...... :; , ........ 12 HUMAN FACTORS (U) •••••••••••••••••••••••••••••• I l ........ 22 CAN YOU TOP THIS? (U) ........................... E. Leigh Sawyer ... , \~ ••••••• 24 PERSONAL COMPUTING IN A GROUP (U).............. • •••••• 25 FACTION LINE (U) ••• , •••••••••••••••••••••••• • ••• Cal Q. Lator •••••••••••••• • 35 NSA-CROSTIC NO. 59 (U) •••.•••••••••••••••••••••• D.H.W.;.,, ••••••••••••••••• 36 'flllS BOC\'.JMBNT <JONTl.INS <JOBl'JWORB MATl'JRIAh Ghi'tSSIFIEB BY tfSA/SSSM lH 2 SECRET BEGI:a\-SSIFY 0N. 0r igiriet iug Agency's Betezminatior:t Reqaized Declassified and Approved for Release by NSA on 'I 0- '16-2012 pursuant to E 0 . 13526, MOR Case # 54 77B OCID: 4009933 Published by Pl, Techniques and Standards EO 1. 4. ( c) P~L. 86-36 VOL. XI, No. 11-12 NOVEMBER-DECEMBER 1984 Editorial PUBLISHER BOARD OF EDITORS Edi.tor ...•••......_I _______ ... 1(963-3045s .) Product ion .•....•. I .(963-3369s) . : : : :· Collection .••••••..•••• i------.jc963-396ls) Computer Security •: ' •••••• 1 ,(859-6044) Cryptolinguist ics. l 963-1 f03s) Data Systems .•...•.•• ·l ., 963-4,953s) Information Science " • ..... I lc963-.5111s> Puzzles .......... David H. Williams'f(9637'Il03s) Special Research • ..•. Vera R. Filby;! C968'-7119s) Traffic Analysis •. Robert J. Hanyo!<f! (968-3888s) For subscript ions .. , send name and organizat~on to: I w14I i P.L.
    [Show full text]
  • Compiler and Library Tim Hunter, SAS Institute Inc.; Cary, NC
    An Overview of the SASle· Compiler and Library Tim Hunter, SAS Institute Inc.; Cary, NC ABSTRACT The Compiler This paper describes the major features of the SAS/C® compiler The compiler implemented the C language as described in the and library and discusses the development history oftha product. then definitive book on C, Kernighan and Ritchie's The C Pro­ The enhancements in the current production release are outlined. .gramming Language: Because the compiler was implemented for Some possible enhancements for future releases are described. IBM 370's, it included many features that were thought necessary for that architecture and for programmers who were used to working In that environment. The foliowing list describes some INTRODUCTION of these features: • The generated code IS fully reentrant, even allowing The SAS/C product has had four production reteases in its five modification of external variables. years of development. Each release included many new features and enhancements of existing features. Not only is the compiler • The compiler supports a number of built-in functions. used exclustve1y for Version 6 of the SA&!' System on ISM® main~ These are functions for which the compiler generates frame hosts, it is the leading C compiter in this market. Although instructions directly into the instruction stream, rather than the compiler and IIDrary is heavily orlented to use in large soft­ generating a call to a separately linked version of the ware systems, it is an efficient tool for any software project that function. In this release, the following functions were is written in the C langauge. implemented as built-in functions: The primary elements of the SASIC product are the the compiler strlen memcmpp ,b, strcpy memcP¥P ceil and run-time library.
    [Show full text]
  • CP/M-80 Kaypro
    $3.00 June-July 1985 . No. 24 TABLE OF CONTENTS C'ing Into Turbo Pascal ....................................... 4 Soldering: The First Steps. .. 36 Eight Inch Drives On The Kaypro .............................. 38 Kaypro BIOS Patch. .. 40 Alternative Power Supply For The Kaypro . .. 42 48 Lines On A BBI ........ .. 44 Adding An 8" SSSD Drive To A Morrow MD-2 ................... 50 Review: The Ztime-I .......................................... 55 BDOS Vectors (Mucking Around Inside CP1M) ................. 62 The Pascal Runoff 77 Regular Features The S-100 Bus 9 Technical Tips ........... 70 In The Public Domain... .. 13 Culture Corner. .. 76 C'ing Clearly ............ 16 The Xerox 820 Column ... 19 The Slicer Column ........ 24 Future Tense The KayproColumn ..... 33 Tidbits. .. .. 79 Pascal Procedures ........ 57 68000 Vrs. 80X86 .. ... 83 FORTH words 61 MSX In The USA . .. 84 On Your Own ........... 68 The Last Page ............ 88 NEW LOWER PRICES! NOW IN "UNKIT"* FORM TOO! "BIG BOARD II" 4 MHz Z80·A SINGLE BOARD COMPUTER WITH "SASI" HARD·DISK INTERFACE $795 ASSEMBLED & TESTED $545 "UNKIT"* $245 PC BOARD WITH 16 PARTS Jim Ferguson, the designer of the "Big Board" distributed by Digital SIZE: 8.75" X 15.5" Research Computers, has produced a stunning new computer that POWER: +5V @ 3A, +-12V @ 0.1A Cal-Tex Computers has been shipping for a year. Called "Big Board II", it has the following features: • "SASI" Interface for Winchester Disks Our "Big Board II" implements the Host portion of the "Shugart Associates Systems • 4 MHz Z80-A CPU and Peripheral Chips Interface." Adding a Winchester disk drive is no harder than attaching a floppy-disk The new Ferguson computer runs at 4 MHz.
    [Show full text]
  • Topic 1D Slides
    Topic I (d): Static Single Assignment Form (SSA) 621-10F/Topic-1d-SSA 1 Reading List Slides: Topic Ix Other readings as assigned in class 621-10F/Topic-1d-SSA 2 ABET Outcome Ability to apply knowledge of SSA technique in compiler optimization An ability to formulate and solve the basic SSA construction problem based on the techniques introduced in class. Ability to analyze the basic algorithms using SSA form to express and formulate dataflow analysis problem A Knowledge on contemporary issues on this topic. 621-10F/Topic-1d-SSA 3 Roadmap Motivation Introduction: SSA form Construction Method Application of SSA to Dataflow Analysis Problems PRE (Partial Redundancy Elimination) and SSAPRE Summary 621-10F/Topic-1d-SSA 4 Prelude SSA: A program is said to be in SSA form iff Each variable is statically defined exactly only once, and each use of a variable is dominated by that variable’s definition. So, is straight line code in SSA form ? 621-10F/Topic-1d-SSA 5 Example 푿ퟏ In general, how to transform an arbitrary program into SSA form? Does the definition of X 푿ퟐ 2 dominate its use in the example? 푿ퟑ 흓 (푿ퟏ, 푿ퟐ) 푿 ퟒ 621-10F/Topic-1d-SSA 6 SSA: Motivation Provide a uniform basis of an IR to solve a wide range of classical dataflow problems Encode both dataflow and control flow information A SSA form can be constructed and maintained efficiently Many SSA dataflow analysis algorithms are more efficient (have lower complexity) than their CFG counterparts. 621-10F/Topic-1d-SSA 7 Algorithm Complexity Assume a 1 GHz machine, and an algorithm that takes f(n) steps (1 step = 1 nanosecond).
    [Show full text]
  • A General Compiler Framework for Speculative Optimizations Using Data Speculative Code Motion
    A General Compiler Framework for Speculative Optimizations Using Data Speculative Code Motion Xiaoru Dai, Antonia Zhai, Wei-Chung Hsu, Pen-Chung Yew Department of Computer Science and Engineering University of Minnesota Minneapolis, MN 55455 {dai, zhai, hsu, yew}@cs.umn.edu Abstract obtaining precise data dependence analysis is both difficult and expensive for languages such as C in which Data speculative optimization refers to code dynamic and pointer-based data structures are frequently transformations that allow load and store instructions to used. When the data dependence analysis is unable to be moved across potentially dependent memory show that there is definitely no data dependence between operations. Existing research work on data speculative two memory references, the compiler must assume that optimizations has mainly focused on individual code there is a data dependence between them. It is quite often transformation. The required speculative analysis that that such an assumption is overly conservative. The identifies data speculative optimization opportunities and examples in Figure 1 illustrate how such conservative data the required recovery code generation that guarantees the dependences may affect compiler optimizations. correctness of their execution are handled separately for each optimization. This paper proposes a new compiler S1: = *q while ( p ){ while( p ){ framework to facilitate the design and implementation of S2: *p= b 1 S1: if (p->f==0) S1: if (p->f == 0) general data speculative optimizations such as dead store
    [Show full text]
  • The Atari™ Compendium ©1992 Software Development Systems Written by Scott Sanders Not for Public Distribution
    The Atari™ Compendium ©1992 Software Development Systems Written by Scott Sanders Not for Public Distribution Introduction The following pages are a work in progress. The Atari™ Compendium (working title) is designed to be a comprehensive reference manual for Atari software and hardware designers of all levels of expertise. At the very least, it will (hopefully) be the first book available that documents all operating system functions, including any modifications or bugs that were associated with them, from TOS 1.00 to whatever the final release version of Falcon TOS ends up being. GEMDOS, BIOS, XBIOS (including sound and DSP calls), VDI, GDOS, LINE-A, FSM, AES, MetaDOS, AHDI and MiNT will be documented. Hardware information to the extent that information is useful to a software programmer will also be covered. This volume will not include hardware specifications used in the creation of hardware add-ons, a programming introduction designed for beginners, or an application style guide. All of the aforementioned exclusions will be created separately as demand for them arise. In addition, I also plan to market a comprehensive spiral- bound mini-reference book to complement this volume. By providing early copies of the text of this volume I hope to accomplish several goals: 1. Present a complete, error-free, professionally written and typeset document of reference. 2. Encourage compatible and endorsed programming practices. 3. Clear up any misunderstandings or erroneous information I may have regarding the information contained within. 4. Avoid any legal problems stemming from non-disclosure or copyright questions. A comprehensive Bibliograpy will be a part of this volume.
    [Show full text]
  • Effective Representation of Aliases and Indirect Memory Operations in SSA Form
    Effective Representation of Aliases and Indirect Memory Operations in SSA Form Fred Chow, Sun Chan, Shin-Ming Liu, Raymond Lo, Mark Streich Silicon Graphics Computer Systems 2011 N. Shoreline Blvd. Mountain View, CA 94043 Contact: Fred Chow (E-mail: [email protected], Phone: USA (415) 933-4270) Abstract. This paper addresses the problems of representing aliases and indirect memory operations in SSA form. We propose a method that prevents explosion in the number of SSA variable versions in the presence of aliases. We also present a technique that allows indirect memory operations to be globally commonized. The result is a precise and compact SSA representation based on global value numbering, called HSSA, that uniformly handles both scalar variables and indi- rect memory operations. We discuss the capabilities of the HSSA representation and present measurements that show the effects of implementing our techniques in a production global optimizer. Keywords. Aliasing, Factoring dependences, Hash tables, Indirect memory oper- ations, Program representation, Static single assignment, Value numbering. 1 Introduction The Static Single Assignment (SSA) form [CFR+91] is a popular and efficient represen- tation for performing analyses and optimizations involving scalar variables. Effective algorithms based on SSA have been developed to perform constant propagation, redun- dant computation detection, dead code elimination, induction variable recognition, and others [AWZ88, RWZ88, WZ91, Wolfe92]. But until now, SSA has only been used mostly for distinct variable names in the program. When applied to indirect variable constructs, the representation is not straight-forward, and results in added complexities in the optimization algorithms that operate on the representation [CFR+91, CG93, CCF94].
    [Show full text]
  • Latticemico32 Tutorial
    LatticeMico32 Tutorial June 2015 Copyright Copyright © 2015 Lattice Semiconductor Corporation. All rights reserved. This document may not, in whole or part, be reproduced, modified, distributed, or publicly displayed without prior written consent from Lattice Semiconductor Corporation (“Lattice”). Trademarks All Lattice trademarks are as listed at www.latticesemi.com/legal. Synopsys and Synplify Pro are trademarks of Synopsys, Inc. Aldec and Active-HDL are trademarks of Aldec, Inc. All other trademarks are the property of their respective owners. Disclaimers NO WARRANTIES: THE INFORMATION PROVIDED IN THIS DOCUMENT IS “AS IS” WITHOUT ANY EXPRESS OR IMPLIED WARRANTY OF ANY KIND INCLUDING WARRANTIES OF ACCURACY, COMPLETENESS, MERCHANTABILITY, NONINFRINGEMENT OF INTELLECTUAL PROPERTY, OR FITNESS FOR ANY PARTICULAR PURPOSE. IN NO EVENT WILL LATTICE OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER (WHETHER DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL, INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OF OR INABILITY TO USE THE INFORMATION PROVIDED IN THIS DOCUMENT, EVEN IF LATTICE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME JURISDICTIONS PROHIBIT THE EXCLUSION OR LIMITATION OF CERTAIN LIABILITY, SOME OF THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU. Lattice may make changes to these materials, specifications, or information, or to the products described herein, at any time without notice. Lattice makes no commitment to update this documentation. Lattice reserves the right to discontinue any product or service without notice and assumes no obligation to correct any errors contained herein or to advise any user of this document of any correction if such be made.
    [Show full text]
  • Compiler Construction
    Compiler construction PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 10 Dec 2011 02:23:02 UTC Contents Articles Introduction 1 Compiler construction 1 Compiler 2 Interpreter 10 History of compiler writing 14 Lexical analysis 22 Lexical analysis 22 Regular expression 26 Regular expression examples 37 Finite-state machine 41 Preprocessor 51 Syntactic analysis 54 Parsing 54 Lookahead 58 Symbol table 61 Abstract syntax 63 Abstract syntax tree 64 Context-free grammar 65 Terminal and nonterminal symbols 77 Left recursion 79 Backus–Naur Form 83 Extended Backus–Naur Form 86 TBNF 91 Top-down parsing 91 Recursive descent parser 93 Tail recursive parser 98 Parsing expression grammar 100 LL parser 106 LR parser 114 Parsing table 123 Simple LR parser 125 Canonical LR parser 127 GLR parser 129 LALR parser 130 Recursive ascent parser 133 Parser combinator 140 Bottom-up parsing 143 Chomsky normal form 148 CYK algorithm 150 Simple precedence grammar 153 Simple precedence parser 154 Operator-precedence grammar 156 Operator-precedence parser 159 Shunting-yard algorithm 163 Chart parser 173 Earley parser 174 The lexer hack 178 Scannerless parsing 180 Semantic analysis 182 Attribute grammar 182 L-attributed grammar 184 LR-attributed grammar 185 S-attributed grammar 185 ECLR-attributed grammar 186 Intermediate language 186 Control flow graph 188 Basic block 190 Call graph 192 Data-flow analysis 195 Use-define chain 201 Live variable analysis 204 Reaching definition 206 Three address
    [Show full text]
  • Techniques for Effectively Exploiting a Zero Overhead Loop Buffer
    Techniques for Effectively Exploiting a Zero Overhead Loop Buffer Gang-Ryung Uh1, Yuhong Wang2, David Whalley2, Sanjay Jinturkar1, Chris Burns1, and Vincent Cao1 1 Lucent Technologies, Allentown, PA 18103, U.S.A. {uh,sjinturkar,cpburns,vpcao}@lucent.com 2 Computer Science Dept., FloridaStateUniv. Tallahassee, FL 32306-4530, U.S.A. {yuhong,whalley}@cs.fsu.edu Abstract. A Zero Overhead Loop Buffer (ZOLB) is an architectural feature that is commonly found in DSP processors. This buffer can be viewed as a compiler managed cache that contains a sequence of instruc- tions that will be executed a specified number of times. Unlike loop un- rolling, a loop buffer can be used to minimize loop overhead without the penalty of increasing code size. In addition, a ZOLB requires relatively little space and power, which are both important considerations for most DSP applications. This paper describes strategies for generating code to effectively use a ZOLB. The authors have found that many common im- proving transformations used by optimizing compilers to improve code on conventional architectures can be exploited (1) to allow more loops to be placed in a ZOLB, (2) to further reduce loop overhead of the loops placed in a ZOLB, and (3) to avoid redundant loading of ZOLB loops. The results given in this paper demonstrate that this architectural fea- ture can often be exploited with substantial improvements in execution time and slight reductions in code size. 1 Introduction The number of DSP processors is growing every year at a much faster rate than general-purpose computer processors. For many applications, a large percentage of the execution time is spent in the innermost loops of a program [1].
    [Show full text]
  • Application of Microcomputers 1N Bridge Design
    Transportation Research Record 1072 15 Application of Microcomputers 1n Bridge Design RONALD A. LOVE, FURMAN W. BARTON, and WALLACE T. McKEEL, Jr. ABSTRACT The use of microcomputers in bridge design activities in state transportation departments was evaluated through contacts with 32 state agencies. Although pres­ ent use of microcomputers was found to be 1 imi tea, subsequent research showed that the current generation of 16-bit machines offers significant advantages in complementing existing computing facilities in a manner that fully uses the power of both mainframe and microcomputer. The ability of microcomputers to run large bridge design applications in a stand-alone mode was demonstrated by successfully downloading and converting four mainframe programs. Running design and analysis programs in a stand-alone mode frees the mainframe CPU and increases access to software that can be run repetitively without consideration of mainframe costs. When access to larger applications on the mainframe is required, the microcomputer used as an intelligent terminal can process input data locally and send them to the mainframe for processing. Output data, in return, can be downloaded to the microcomputer and reviewed off-line or input into microcomputer applications such as spreadsheets or graphics packages for further processing. Computer applications in engineering design have had preferred alternative for using much of the bridge a dramatic effect on the analysis and design process design software available. In Virginia, as in many in general. Automating analysis and design proce­ other states, many bridge design activities have dures has relegated much of the computational burden been decentralized in district offices across the to machines, allowing the engineer more time to state.
    [Show full text]