DOCSLIB.ORG

Compiler Design: Theory, Tools, and Examples

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Rowan University Rowan University Rowan Digital Works Open Educational Resources University Libraries 5-1-2017 Compiler Design: Theory, Tools, and Examples Seth D. Bergmann Rowan University, [email protected] Follow this and additional works at: https://rdw.rowan.edu/oer Part of the Computer Sciences Commons Let us know how access to this document benefits ouy - share your thoughts on our feedback form. Recommended Citation Bergmann, Seth D., "Compiler Design: Theory, Tools, and Examples" (2017). Open Educational Resources. 1. https://rdw.rowan.edu/oer/1 This Book is brought to you for free and open access by the University Libraries at Rowan Digital Works. It has been accepted for inclusion in Open Educational Resources by an authorized administrator of Rowan Digital Works. For more information, please contact [email protected]. Compiler Design: Theory, Tools, and Examples Seth D. Bergmann February 12, 2016 2 Contents Preface v 1 Introduction 1 1.1 WhatisaCompiler?......................... 1 1.1.1 Exercises ........................... 7 1.2 ThePhasesofaCompiler ...................... 8 1.2.1 Lexical Analysis (Scanner) - Finding the Word Boundaries 8 1.2.2 SyntaxAnalysisPhase. 10 1.2.3 Global Optimization . 12 1.2.4 CodeGeneration ....................... 13 1.2.5 Local Optimization . 15 1.2.6 Exercises ........................... 17 1.3 ImplementationTechniques . 19 1.3.1 Bootstrapping ........................ 20 1.3.2 Cross Compiling . 21 1.3.3 Compiling To Intermediate Form . 22 1.3.4 Compiler-Compilers . 24 1.3.5 Exercises ........................... 24 1.4 CaseStudy:Decaf .......................... 25 1.5 ChapterSummary .......................... 27 2 Lexical Analysis 28 2.0 FormalLanguages .......................... 28 2.0.1 LanguageElements.. .. .. .. .. .. .. .. .. 28 2.0.2 Finite State Machines . 29 2.0.3 RegularExpressions . .. .. .. .. .. .. .. .. 33 2.0.4 Exercises ........................... 36 2.1 LexicalTokens ............................ 38 2.1.1 Exercises ........................... 41 2.2 Implementation with Finite State Machines . 42 2.2.1 Examples of Finite State Machines for Lexical Analysis . 42 2.2.2 Actions for Finite State Machines . 44 2.2.3 Exercises ........................... 46 2.3 LexicalTables............................. 47 i ii CONTENTS 2.3.1 SequentialSearch.. .. .. .. .. .. .. .. .. .. 47 2.3.2 BinarySearchTree. .. .. .. .. .. .. .. .. .. 48 2.3.3 HashTable .......................... 49 2.3.4 Exercises ........................... 49 2.4 Lexical Analysis with SableCC . 51 2.4.1 SableCC Input File . 51 2.4.2 RunningSableCC ...................... 59 2.4.3 Exercises ........................... 62 2.5 CaseStudy: LexicalAnalysisforDecaf. 62 2.5.1 Exercises ........................... 65 2.6 ChapterSummary .......................... 65 3 Syntax Analysis 67 3.0 Grammars,Languages,and Pushdown Machines . 68 3.0.1 Grammars........................... 68 3.0.2 ClassesofGrammars. 70 3.0.3 Context-FreeGrammars . 73 3.0.4 PushdownMachines .. .. .. .. .. .. .. .. .. 75 3.0.5 Correspondence Between Machines and Classes of Languages 79 3.0.6 Exercises ........................... 84 3.1 Ambiguities in Programming Languages . 87 3.1.1 Exercises ........................... 89 3.2 TheParsingProblem......................... 90 3.3 Summary ............................... 91 4 Top Down Parsing 93 4.0 RelationsandClosure ........................ 94 4.0.1 Exercises ........................... 96 4.1 SimpleGrammars .......................... 97 4.1.1 Parsing Simple Languages with Pushdown Machines . 98 4.1.2 Recursive Descent Parsers for Simple Grammars . 100 4.1.3 Exercises ........................... 104 4.2 Quasi-SimpleGrammars. 105 4.2.1 Pushdown Machines for Quasi-Simple Grammars . 107 4.2.2 Recursive Descent for Quasi-Simple Grammars . 107 4.2.3 A Final Remark on ǫ Rules ................. 108 4.2.4 Exercises ........................... 111 4.3 LL(1)Grammars ........................... 111 4.3.1 Pushdown Machinesfor LL(1)Grammars . 116 4.3.2 RecursiveDescentforLL(1)Grammars . 118 4.3.3 Exercises ........................... 120 4.4 ParsingArithmeticExpressionsTopDown. 121 4.4.1 Exercises ........................... 130 4.5 Syntax-DirectedTranslation. 131 4.5.1 Implementing Translation Grammars with Pushdown Translators132 4.5.2 Implementing Translation Grammars with Recursive Descent134 CONTENTS iii 4.5.3 Exercises ........................... 137 4.6 AttributedGrammars . 137 4.6.1 Implementing Attributed Grammars with Recursive Descent139 4.6.2 Exercises ........................... 142 4.7 An Attributed Translation Grammar for Expressions . 143 4.7.1 Translating Expressions with Recursive Descent . 144 4.7.2 Exercises ........................... 147 4.8 DecafExpressions .......................... 147 4.8.1 LBL,JMP,TST,andMOVatoms . 148 4.8.2 Booleanexpressions . 148 4.8.3 Assignment .......................... 150 4.8.4 Exercises ........................... 152 4.9 TranslatingControlStructures . 153 4.9.1 Exercises ........................... 158 4.10 CaseStudy: ATopDownParserforDecaf . 159 4.10.1 Exercises ........................... 161 4.11 ChapterSummary . .. .. .. .. .. .. .. .. .. .. 162 5 Bottom Up Parsing 164 5.1 ShiftReduceParsing. .. .. .. .. .. .. .. .. .. .. 164 5.1.1 Exercises ........................... 170 5.2 LRParsingWithTables . .. .. .. .. .. .. .. .. .. 171 5.2.1 Exercises ........................... 176 5.3 SableCC................................177 5.3.1 OverviewofSableCC . 177 5.3.2 StructureoftheSableCCSourceFiles . 177 5.3.3 An Example Using SableCC . 179 5.3.4 Exercises ........................... 187 5.4 Arrays.................................192 5.4.1 Exercises ........................... 196 5.5 CaseStudy: SyntaxAnalysisforDecaf . 197 5.5.1 Exercises ........................... 199 5.6 ChapterSummary .......................... 200 6 Code Generation 202 6.1 IntroductiontoCodeGeneration . 202 6.1.1 Exercises ........................... 205 6.2 ConvertingAtomstoInstructions. 206 6.2.1 Exercises ........................... 208 6.3 Single Pass vs. Multiple Passes . 209 6.3.1 Exercises ........................... 214 6.4 Register Allocation . 215 6.4.1 Exercises ........................... 219 6.5 Case Study: A Code Generator for the Mini Architecture . 219 6.5.1 Mini: The Simulated Architecture . 220 6.5.2 TheInputtotheCodeGenerator. 222 iv CONTENTS 6.5.3 TheCodeGeneratorforMini . 223 6.5.4 Exercises ........................... 224 6.6 ChapterSummary .......................... 225 7 Optimization 227 7.1 Introduction and View of Optimization . 227 7.1.1 Exercises ........................... 229 7.2 Global Optimization . 230 7.2.1 BasicBlocksandDAGs . 230 7.2.2 Other Global Optimization Techniques . 237 7.2.3 Exercises ........................... 242 7.3 LocalOptimization.......................... 246 7.3.1 Exercises ........................... 248 7.4 ChapterSummary .......................... 250 Glossary 251 Appendix A - Decaf Grammar 263 Appendix B - Decaf Compiler 266 B.1 InstallingDecaf............................ 266 B.2 SourceCodeforDecaf . 267 B.3 CodeGenerator............................ 285 Appendix C - Mini Simulator 291 Bibliography 298 Index 301 Preface Compiler design is a subject which many believe to be fundamental and vital to computer science. It is a subject which has been studied intensively since the early 1950’s and continues to be an important research field today. Compiler design is an important part of the undergraduate curriculum for many reasons: (1) It provides students with a better understanding of and appreciation for programming languages. (2) The techniques used in compilers can be used in other applications with command languages. (3) It provides motivation for the study of theoretic topics. (4) It is a good vehicle for an extended programming project. There are several compiler design textbooks available today, but most have been written for graduate students. Here at Rowan University, our students have had difficulty reading these books. However, I felt it was not the subject matter that was the problem, but the way it was presented. I was sure that if concepts were presented at a slower pace, with sample problems and diagrams to illustrate the concepts, that our students would be able to master the concepts. This is what I have attempted to do in writing this book. This book is a revision of earlier editions that were written for Pascal and C++ based curricula. As many computer science departments have moved to Java as the primary language in the undergraduate curriculum, I have produced this edition to accommodate those departments. This book is not intended to be strictly an object- oriented approach to compiler design. Though most Java compilers compile to an intermediate form known as Byte Code, the approach taken here is a more traditional one in which we compile to native code for a particular machine. The most essential prerequisites for this book are courses in Java application programming, Data Structures, Assembly Language or Computer Architecture, and possibly Programming Languages. If the student has not studied formal languages and automata, this book includes introductory sections on these the- oretic topics, but in this case it is not likely that all seven chapters will be covered in a one semester course. Students who have studied the theory will be able to skip the preliminary sections (2.0, 3.0, 4.0) without loss of continuity. The concepts of compiler
Recommended publications
  • Ece351 Lab Manual

    Ece351 Lab Manual

    DEREK RAYSIDE & ECE351 STAFF ECE351 LAB MANUAL UNIVERSITYOFWATERLOO 2 derek rayside & ece351 staff Copyright © 2014 Derek Rayside & ECE351 Staff Compiled March 6, 2014 acknowledgements: • Prof Paul Ward suggested that we look into something with vhdl to have synergy with ece327. • Prof Mark Aagaard, as the ece327 instructor, consulted throughout the development of this material. • Prof Patrick Lam generously shared his material from the last offering of ece251. • Zhengfang (Alex) Duanmu & Lingyun (Luke) Li [1b Elec] wrote solutions to most labs in txl. • Jiantong (David) Gao & Rui (Ray) Kong [3b Comp] wrote solutions to the vhdl labs in antlr. • Aman Muthrej and Atulan Zaman [3a Comp] wrote solutions to the vhdl labs in Parboiled. • TA’s Jon Eyolfson, Vajih Montaghami, Alireza Mortezaei, Wenzhu Man, and Mohammed Hassan. • TA Wallace Wu developed the vhdl labs. • High school students Brian Engio and Tianyu Guo drew a number of diagrams for this manual, wrote Javadoc comments for the code, and provided helpful comments on the manual. Licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) version 2.5 or greater. http://creativecommons.org/licenses/by-sa/2.5/ca/ http://creativecommons.org/licenses/by-sa/3.0/ Contents 0 Overview 9 Compiler Concepts: call stack, heap 0.1 How the Labs Fit Together . 9 Programming Concepts: version control, push, pull, merge, SSH keys, IDE, 0.2 Learning Progressions . 11 debugger, objects, pointers 0.3 How this project compares to CS241, the text book, etc. 13 0.4 Student work load . 14 0.5 How this course compares to MIT 6.035 .......... 15 0.6 Where do I learn more? .
  • Implementation of Processing in Racket 1 Introduction

    Implementation of Processing in Racket 1 Introduction

    P2R Implementation of Processing in Racket Hugo Correia [email protected] Instituto Superior T´ecnico University of Lisbon Abstract. Programming languages are being introduced in several ar- eas of expertise, including design and architecture. Processing is an ex- ample of one of these languages that was created to teach architects and designers how to program. In spite of offering a wide set of features, Pro- cessing does not support the use of traditional computer-aided design applications, which are heavily used in the architecture industry. Rosetta is a generative design tool based on the Racket language that attempts to solve this problem. Rosetta provides a novel approach to de- sign creation, offering a set of programming languages that generate de- signs in different computer-aided design applications. However, Rosetta does not support Processing. Therefore, the goal is to add Processing to Rosetta's language set, offering architects that know Processing, an alternative solution that supports computer-aided design applications. In order to achieve this goal, a source-to-source compiler that translates Processing into Racket will be developed. This will also give the Racket community the ability to use Processing in the Racket environment, and, at the same time, will allow the Processing community to take advantage of Racket's libraries and development environment. In this report, an analysis of different language implementation mecha- nisms will be presented, focusing on the different steps of the compilation phase, as well as higher-level solutions, including Language Workbenches. In order to gain insight of source-to-source compiler creation, relevant existing source-to-source compilers are presented.
  • Adaptive LL(*) Parsing: the Power of Dynamic Analysis

    Adaptive LL(*) Parsing: the Power of Dynamic Analysis

    Adaptive LL(*) Parsing: The Power of Dynamic Analysis Terence Parr Sam Harwell Kathleen Fisher University of San Francisco University of Texas at Austin Tufts University [email protected] [email protected] kfi[email protected] Abstract PEGs are unambiguous by definition but have a quirk where Despite the advances made by modern parsing strategies such rule A ! a j ab (meaning “A matches either a or ab”) can never as PEG, LL(*), GLR, and GLL, parsing is not a solved prob- match ab since PEGs choose the first alternative that matches lem. Existing approaches suffer from a number of weaknesses, a prefix of the remaining input. Nested backtracking makes de- including difficulties supporting side-effecting embedded ac- bugging PEGs difficult. tions, slow and/or unpredictable performance, and counter- Second, side-effecting programmer-supplied actions (muta- intuitive matching strategies. This paper introduces the ALL(*) tors) like print statements should be avoided in any strategy that parsing strategy that combines the simplicity, efficiency, and continuously speculates (PEG) or supports multiple interpreta- predictability of conventional top-down LL(k) parsers with the tions of the input (GLL and GLR) because such actions may power of a GLR-like mechanism to make parsing decisions. never really take place [17]. (Though DParser [24] supports The critical innovation is to move grammar analysis to parse- “final” actions when the programmer is certain a reduction is time, which lets ALL(*) handle any non-left-recursive context- part of an unambiguous final parse.) Without side effects, ac- free grammar. ALL(*) is O(n4) in theory but consistently per- tions must buffer data for all interpretations in immutable data forms linearly on grammars used in practice, outperforming structures or provide undo actions.
  • 9. Optimization

    9. Optimization

    9. Optimization Marcus Denker Optimization Roadmap > Introduction > Optimizations in the Back-end > The Optimizer > SSA Optimizations > Advanced Optimizations © Marcus Denker 2 Optimization Roadmap > Introduction > Optimizations in the Back-end > The Optimizer > SSA Optimizations > Advanced Optimizations © Marcus Denker 3 Optimization Optimization: The Idea > Transform the program to improve efficiency > Performance: faster execution > Size: smaller executable, smaller memory footprint Tradeoffs: 1) Performance vs. Size 2) Compilation speed and memory © Marcus Denker 4 Optimization No Magic Bullet! > There is no perfect optimizer > Example: optimize for simplicity Opt(P): Smallest Program Q: Program with no output, does not stop Opt(Q)? © Marcus Denker 5 Optimization No Magic Bullet! > There is no perfect optimizer > Example: optimize for simplicity Opt(P): Smallest Program Q: Program with no output, does not stop Opt(Q)? L1 goto L1 © Marcus Denker 6 Optimization No Magic Bullet! > There is no perfect optimizer > Example: optimize for simplicity Opt(P): Smallest ProgramQ: Program with no output, does not stop Opt(Q)? L1 goto L1 Halting problem! © Marcus Denker 7 Optimization Another way to look at it... > Rice (1953): For every compiler there is a modified compiler that generates shorter code. > Proof: Assume there is a compiler U that generates the shortest optimized program Opt(P) for all P. — Assume P to be a program that does not stop and has no output — Opt(P) will be L1 goto L1 — Halting problem. Thus: U does not exist. > There will
  • Value Numbering

    Value Numbering

    SOFTWARE—PRACTICE AND EXPERIENCE, VOL. 0(0), 1–18 (MONTH 1900) Value Numbering PRESTON BRIGGS Tera Computer Company, 2815 Eastlake Avenue East, Seattle, WA 98102 AND KEITH D. COOPER L. TAYLOR SIMPSON Rice University, 6100 Main Street, Mail Stop 41, Houston, TX 77005 SUMMARY Value numbering is a compiler-based program analysis method that allows redundant computations to be removed. This paper compares hash-based approaches derived from the classic local algorithm1 with partitioning approaches based on the work of Alpern, Wegman, and Zadeck2. Historically, the hash-based algorithm has been applied to single basic blocks or extended basic blocks. We have improved the technique to operate over the routine’s dominator tree. The partitioning approach partitions the values in the routine into congruence classes and removes computations when one congruent value dominates another. We have extended this technique to remove computations that define a value in the set of available expressions (AVA IL )3. Also, we are able to apply a version of Morel and Renvoise’s partial redundancy elimination4 to remove even more redundancies. The paper presents a series of hash-based algorithms and a series of refinements to the partitioning technique. Within each series, it can be proved that each method discovers at least as many redundancies as its predecessors. Unfortunately, no such relationship exists between the hash-based and global techniques. On some programs, the hash-based techniques eliminate more redundancies than the partitioning techniques, while on others, partitioning wins. We experimentally compare the improvements made by these techniques when applied to real programs. These results will be useful for commercial compiler writers who wish to assess the potential impact of each technique before implementation.
  • Language and Compiler Support for Dynamic Code Generation by Massimiliano A

    Language and Compiler Support for Dynamic Code Generation by Massimiliano A

    Language and Compiler Support for Dynamic Code Generation by Massimiliano A. Poletto S.B., Massachusetts Institute of Technology (1995) M.Eng., Massachusetts Institute of Technology (1995) Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of Doctor of Philosophy at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY September 1999 © Massachusetts Institute of Technology 1999. All rights reserved. A u th or ............................................................................ Department of Electrical Engineering and Computer Science June 23, 1999 Certified by...............,. ...*V .,., . .* N . .. .*. *.* . -. *.... M. Frans Kaashoek Associate Pro essor of Electrical Engineering and Computer Science Thesis Supervisor A ccepted by ................ ..... ............ ............................. Arthur C. Smith Chairman, Departmental CommitteA on Graduate Students me 2 Language and Compiler Support for Dynamic Code Generation by Massimiliano A. Poletto Submitted to the Department of Electrical Engineering and Computer Science on June 23, 1999, in partial fulfillment of the requirements for the degree of Doctor of Philosophy Abstract Dynamic code generation, also called run-time code generation or dynamic compilation, is the cre- ation of executable code for an application while that application is running. Dynamic compilation can significantly improve the performance of software by giving the compiler access to run-time infor- mation that is not available to a traditional static compiler. A well-designed programming interface to dynamic compilation can also simplify the creation of important classes of computer programs. Until recently, however, no system combined efficient dynamic generation of high-performance code with a powerful and portable language interface. This thesis describes a system that meets these requirements, and discusses several applications of dynamic compilation.
  • Regular Expressions with a Brief Intro to FSM

    Regular Expressions with a Brief Intro to FSM

    Regular Expressions with a brief intro to FSM 15-123 Systems Skills in C and Unix Case for regular expressions • Many web applications require pattern matching – look for <a href> tag for links – Token search • A regular expression – A pattern that defines a class of strings – Special syntax used to represent the class • Eg; *.c - any pattern that ends with .c Formal Languages • Formal language consists of – An alphabet – Formal grammar • Formal grammar defines – Strings that belong to language • Formal languages with formal semantics generates rules for semantic specifications of programming languages Automaton • An automaton ( or automata in plural) is a machine that can recognize valid strings generated by a formal language . • A finite automata is a mathematical model of a finite state machine (FSM), an abstract model under which all modern computers are built. Automaton • A FSM is a machine that consists of a set of finite states and a transition table. • The FSM can be in any one of the states and can transit from one state to another based on a series of rules given by a transition function. Example What does this machine represents? Describe the kind of strings it will accept. Exercise • Draw a FSM that accepts any string with even number of A’s. Assume the alphabet is {A,B} Build a FSM • Stream: “I love cats and more cats and big cats ” • Pattern: “cat” Regular Expressions Regex versus FSM • A regular expressions and FSM’s are equivalent concepts. • Regular expression is a pattern that can be recognized by a FSM. • Regex is an example of how good theory leads to good programs Regular Expression • regex defines a class of patterns – Patterns that ends with a “*” • Regex utilities in unix – grep , awk , sed • Applications – Pattern matching (DNA) – Web searches Regex Engine • A software that can process a string to find regex matches.
  • Conflict Resolution in a Recursive Descent Compiler Generator

    Conflict Resolution in a Recursive Descent Compiler Generator

    LL(1) Conflict Resolution in a Recursive Descent Compiler Generator Albrecht Wöß, Markus Löberbauer, Hanspeter Mössenböck Johannes Kepler University Linz, Institute of Practical Computer Science, Altenbergerstr. 69, 4040 Linz, Austria {woess,loeberbauer,moessenboeck}@ssw.uni-linz.ac.at Abstract. Recursive descent parsing is restricted to languages whose grammars are LL(1), i.e., which can be parsed top-down with a single lookahead symbol. Unfortunately, many languages such as Java, C++, or C# are not LL(1). There- fore recursive descent parsing cannot be used or the parser has to make its deci- sions based on semantic information or a multi-symbol lookahead. In this paper we suggest a systematic technique for resolving LL(1) conflicts in recursive descent parsing and show how to integrate it into a compiler gen- erator (Coco/R). The idea is to evaluate user-defined boolean expressions, in order to allow the parser to make its parsing decisions where a one symbol loo- kahead does not suffice. Using our extended compiler generator we implemented a compiler front end for C# that can be used as a framework for implementing a variety of tools. 1 Introduction Recursive descent parsing [16] is a popular top-down parsing technique that is sim- ple, efficient, and convenient for integrating semantic processing. However, it re- quires the grammar of the parsed language to be LL(1), which means that the parser must always be able to select between alternatives with a single symbol lookahead. Unfortunately, many languages such as Java, C++ or C# are not LL(1) so that one either has to resort to bottom-up LALR(1) parsing [5, 1], which is more powerful but less convenient for semantic processing, or the parser has to resolve the LL(1) con- flicts using semantic information or a multi-symbol lookahead.
  • Transparent Dynamic Optimization: the Design and Implementation of Dynamo

    Transparent Dynamic Optimization: the Design and Implementation of Dynamo

    Transparent Dynamic Optimization: The Design and Implementation of Dynamo Vasanth Bala, Evelyn Duesterwald, Sanjeev Banerjia HP Laboratories Cambridge HPL-1999-78 June, 1999 E-mail: [email protected] dynamic Dynamic optimization refers to the runtime optimization optimization, of a native program binary. This report describes the compiler, design and implementation of Dynamo, a prototype trace selection, dynamic optimizer that is capable of optimizing a native binary translation program binary at runtime. Dynamo is a realistic implementation, not a simulation, that is written entirely in user-level software, and runs on a PA-RISC machine under the HPUX operating system. Dynamo does not depend on any special programming language, compiler, operating system or hardware support. Contrary to intuition, we demonstrate that it is possible to use a piece of software to improve the performance of a native, statically optimized program binary, while it is executing. Dynamo not only speeds up real application programs, its performance improvement is often quite significant. For example, the performance of many +O2 optimized SPECint95 binaries running under Dynamo is comparable to the performance of their +O4 optimized version running without Dynamo. Internal Accession Date Only Ó Copyright Hewlett-Packard Company 1999 Contents 1 INTRODUCTION ........................................................................................... 7 2 RELATED WORK ......................................................................................... 9 3 OVERVIEW
  • Optimizing for Reduced Code Space Using Genetic Algorithms

    Optimizing for Reduced Code Space Using Genetic Algorithms

    Optimizing for Reduced Code Space using Genetic Algorithms Keith D. Cooper, Philip J. Schielke, and Devika Subramanian Department of Computer Science Rice University Houston, Texas, USA {keith | phisch | devika}@cs.rice.edu Abstract is virtually impossible to select the best set of optimizations to run on a particular piece of code. Historically, compiler Code space is a critical issue facing designers of software for embedded systems. Many traditional compiler optimiza- writers have made one of two assumptions. Either a fixed tions are designed to reduce the execution time of compiled optimization order is “good enough” for all programs, or code, but not necessarily the size of the compiled code. Fur- giving the user a large set of flags that control optimization ther, different results can be achieved by running some opti- is sufficient, because it shifts the burden onto the user. mizations more than once and changing the order in which optimizations are applied. Register allocation only com- Interplay between optimizations occurs frequently. A plicates matters, as the interactions between different op- transformation can create opportunities for other transfor- timizations can cause more spill code to be generated. The mations. Similarly, a transformation can eliminate oppor- compiler for embedded systems, then, must take care to use tunities for other transformations. These interactions also the best sequence of optimizations to minimize code space. Since much of the code for embedded systems is compiled depend on the program being compiled, and they are of- once and then burned into ROM, the software designer will ten difficult to predict. Multiple applications of the same often tolerate much longer compile times in the hope of re- transformation at different points in the optimization se- ducing the size of the compiled code.
  • Generating Context-Free Grammars Using Classical Planning

    Generating Context-Free Grammars Using Classical Planning

    Proceedings of the Twenty-Sixth International Joint Conference on Artificial Intelligence (IJCAI-17) Generating Context-Free Grammars using Classical Planning Javier Segovia-Aguas1, Sergio Jimenez´ 2, Anders Jonsson 1 1 Universitat Pompeu Fabra, Barcelona, Spain 2 University of Melbourne, Parkville, Australia [email protected], [email protected], [email protected] Abstract S ! aSa S This paper presents a novel approach for generating S ! bSb /|\ Context-Free Grammars (CFGs) from small sets of S ! a S a /|\ input strings (a single input string in some cases). a S a Our approach is to compile this task into a classical /|\ planning problem whose solutions are sequences b S b of actions that build and validate a CFG compli- | ant with the input strings. In addition, we show that our compilation is suitable for implementing the two canonical tasks for CFGs, string produc- (a) (b) tion and string recognition. Figure 1: (a) Example of a context-free grammar; (b) the corre- sponding parse tree for the string aabbaa. 1 Introduction A formal grammar is a set of symbols and rules that describe symbols in the grammar and (2), a bounded maximum size of how to form the strings of certain formal language. Usually the rules in the grammar (i.e. a maximum number of symbols two tasks are defined over formal grammars: in the right-hand side of the grammar rules). Our approach is compiling this inductive learning task into • Production : Given a formal grammar, generate strings a classical planning task whose solutions are sequences of ac- that belong to the language represented by the grammar.
  • Keyword Based Search Engine for Web Applications Using Lucene and Javacc Priyesh Wani, Nikita Shah, Kapil Thombare, Chaitalee Zade

    Keyword Based Search Engine for Web Applications Using Lucene and Javacc Priyesh Wani, Nikita Shah, Kapil Thombare, Chaitalee Zade

    Priyesh Wani et al IJCSET |April 2012| Vol 2, Issue 4,1143-1146 Keyword based Search Engine for Web Applications Using Lucene and JavaCC Priyesh Wani, Nikita Shah, Kapil Thombare, Chaitalee Zade Information Technology, Computer Science University of Pune [email protected] [email protected] [email protected] [email protected] Abstract—Past Few years IT industry has taken leap towards functionality to an application or website. Lucene is able to developing Web based Applications. The need aroused due to achieve fast search responses because, instead of searching increasing globalization. Web applications has revolutionized the text directly, it searches an index instead. Which is the way business processes. It provides scalability and equivalent to retrieving pages in a book related to a extensibility in managing different processes in respective keyword by searching the index at the back of a book, as domains. With evolving standard of these web applications some functionalities has become part of that standard, Search opposed to searching the words in each page of the book. Engine being one of them. Organization dealing with large JavacCC: Java Compiler Compiler (JavaCC) is the most number of clients has to face an overhead of maintaining huge popular parser generator for use with Java applications. A databases. Retrieval of data in that case becomes difficult from parser generator is a tool that reads a grammar specification developer’s point of view. In this paper we have presented an and converts it to a Java program that can recognize efficient way of implementing keyword based search engine matches to the grammar.