DOCSLIB.ORG

Branching in Data-Parallel Languages Using Predication with LLVM

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Branching in Data-Parallel Languages Using Predication with LLVM Branching in Data-Parallel Languages using Predication with LLVM Marcello Maggioni Codeplay Software Ltd. EuroLLVM 2014 M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 1 / 46 Outline 1 Introduction Data-Parallel Languages SIMD Architectures SIMD + Data-Parallel Approach 2 Implementation Predicating Instructions Determining an execution schedule Execution mask allocation Mask Handling Insertion CFG Linearization Predicate instructions Optimizations Advantages M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 2 / 46 Introduction Data-Parallel Languages Outline 1 Introduction Data-Parallel Languages SIMD Architectures SIMD + Data-Parallel Approach 2 Implementation Predicating Instructions Determining an execution schedule Execution mask allocation Mask Handling Insertion CFG Linearization Predicate instructions Optimizations Advantages M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 3 / 46 Introduction Data-Parallel Languages Data-Parallel Languages OpenCL, CUDA, Renderscript ... Heavily parallel Many threads running the same code/program on a varying dataset SIMD-architecture friendly M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 4 / 46 Introduction SIMD Architectures Outline 1 Introduction Data-Parallel Languages SIMD Architectures SIMD + Data-Parallel Approach 2 Implementation Predicating Instructions Determining an execution schedule Execution mask allocation Mask Handling Insertion CFG Linearization Predicate instructions Optimizations Advantages M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 5 / 46 Introduction SIMD Architectures SIMD Architectures Heavily Parallel Very efficient at running data parallel workloads with uniform control flow Very common today (Today’s CPUs all have SIMD capabilities. Most GPUs are SIMD at heart) M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 6 / 46 Introduction SIMD + Data-Parallel Approach Outline 1 Introduction Data-Parallel Languages SIMD Architectures SIMD + Data-Parallel Approach 2 Implementation Predicating Instructions Determining an execution schedule Execution mask allocation Mask Handling Insertion CFG Linearization Predicate instructions Optimizations Advantages M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 7 / 46 Introduction SIMD + Data-Parallel Approach SIMD + Data-Parallel Approach Each SIMD processing unit (PU) runs a different Data-Parallel thread SIMD Processor Thread 0 Thread 1 Thread 2 Thread 3 M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 8 / 46 Introduction SIMD + Data-Parallel Approach SIMD + Data-Parallel: Challenges Divergent branching happens when different SIMD PUs want to follow different code paths Needs special handling on many SIMD hardware as each individual unit is not independent. SIMD units share the same PC (need to execute the same instructions) M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 9 / 46 Introduction SIMD + Data-Parallel Approach Branching on SIMD: Principles We want to auto-vectorize the entire instruction stream over all the PUs of the SIMD Processor. Linearize the entire CFG after register allocation After linearization Basic Blocks that shouldn’t run on a certain SIMD PU should have the execution of the instructions in that Basic Block disabled BB#0: entry entry T F BB#1: if.else if.then if.else BB#2: if.then if.end CFG for 'kern0' function BB#3: if.end CFG for 'kern0' function M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 10 / 46 Introduction SIMD + Data-Parallel Approach Branching on SIMD: Principles SIMD Processor BB#0: entry entry SIMD Processor T F BB#1: if.else if.then if.else BB#2: if.then if.end CFG for 'kern0' function BB#3: if.end CFG for 'kern0' function M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 11 / 46 Introduction SIMD + Data-Parallel Approach Branching on SIMD: Principles SIMD Processor BB#0: entry entry SIMD Processor T F BB#1: if.else if.then if.else BB#2: if.then if.end CFG for 'kern0' function BB#3: if.end CFG for 'kern0' function M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 12 / 46 Introduction SIMD + Data-Parallel Approach Branching on SIMD: Principles SIMD Processor BB#0: entry entry SIMD Processor T F BB#1: if.else if.then if.else BB#2: if.then if.end CFG for 'kern0' function BB#3: if.end CFG for 'kern0' function M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 13 / 46 Introduction SIMD + Data-Parallel Approach Approaches IR-approach Preferred if the architecture doesn’t support full-predication Needs special handling for side-effected instructions (trapped instructions, function calls ...) Backend-approaches Can make full use of the features of the hardware Hardware predication can be exploited M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 14 / 46 Introduction SIMD + Data-Parallel Approach Predication Predication is an hardware cmp m0 , r0 , r 1 setmask m0 feature that conditionally // Execute only i f mask for unit is true disables side effects of addvp r0, r1, r2 instructions M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 15 / 46 Implementation Predicating Instructions Outline 1 Introduction Data-Parallel Languages SIMD Architectures SIMD + Data-Parallel Approach 2 Implementation Predicating Instructions Determining an execution schedule Execution mask allocation Mask Handling Insertion CFG Linearization Predicate instructions Optimizations Advantages M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 16 / 46 Implementation Predicating Instructions Predicating instructions Predicable instructions are defined in TableGen with an additional predicate operand in the backend The predicate operand has a default value which typically equals to the “always execute” predicate M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 17 / 46 Implementation Predicating Instructions Predicating instructions (2) d e f LDRT_POST : ARMAsmPseudo<"ldrt${q}␣$Rt ,␣$addr" , (ins addr_offset_none:$addr , pred:$q), (outs GPR:$Rt)>; M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 18 / 46 Implementation Predicating Instructions Predicating instructions (3) // ARM Predicate operand. Default to 14 = always (AL). Second part is CC // register whose default is 0 (no register). def CondCodeOperand : AsmOperandClass { let Name = "CondCode"; } def pred : PredicateOperand<OtherVT, (ops i32imm, i32imm), (ops (i32 14), (i32 zero_reg))> { let PrintMethod = "printPredicateOperand"; let ParserMatchClass = CondCodeOperand; let DecoderMethod = "DecodePredicateOperand"; } M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 19 / 46 Implementation Determining an execution schedule Outline 1 Introduction Data-Parallel Languages SIMD Architectures SIMD + Data-Parallel Approach 2 Implementation Predicating Instructions Determining an execution schedule Execution mask allocation Mask Handling Insertion CFG Linearization Predicate instructions Optimizations Advantages M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 20 / 46 Implementation Determining an execution schedule Determining an execution schedule The execution schedule is the order of execution in the linearized CFG. BB#0: entry entry The schedule needs to be chosen T F such that every possible BB#1: if.else if.then if.else predecessor of a BB is executed BB#2: if.then before the BB itself if.end The Reverse Post Order CFG for 'kern0' function BB#3: if.end CFG for 'kern0' function traversal of the CFG follows this rule (Can use the Reverse Post Order Iterator from LLVM) M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 21 / 46 Implementation Determining an execution schedule Determining an execution schedule (2) Structurizing the CFG in this phase generates naturally a valid execution schedule and simplifies later passes. Can be done using the StructurizeCFG pass from LLVM M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 22 / 46 Implementation Determining an execution schedule StructurizeCFG %0 %0 T F T F %5 i n t main ( ) { T F volatile int a = 5 ; %4 volatile int b = 6 ; T F %12 i f (a==5 || b< 2) { b = 6 ; Flow1 } e l s e { b = 7 ; } %7 %8 Flow T F r e t u r n 0 ; } %10 %9 %13 CFG for 'main' function CFG for 'main' function M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 23 / 46 Implementation Determining an execution schedule StructurizeCFG (2) i n t main ( ) { %0 T F volatile int a = 5 ; volatile int b = 6 ; %0 %8 T F i f ( a < 5) { a = 5 ; Flow %4 %6 T F } e l s e { b = 1 0 ; } %7 %6 CFG for 'main' function r e t u r n 0 ; %9 CFG for 'main' function } M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 24 / 46 Implementation Execution mask allocation Outline 1 Introduction Data-Parallel Languages SIMD Architectures SIMD + Data-Parallel Approach 2 Implementation Predicating Instructions Determining an execution schedule Execution mask allocation Mask Handling Insertion CFG Linearization Predicate instructions Optimizations Advantages M. Maggioni (Codeplay Software Ltd.) Branching with Predication EuroLLVM 2014 25 / 46 Implementation Execution mask allocation Execution Mask Allocation To each basic-block
Load more

Recommended publications
  • Three Architectural Models for Compiler-Controlled Speculative
    Three Architectural Mo dels for Compiler-Controlled Sp eculative Execution Pohua P. Chang Nancy J. Warter Scott A. Mahlke Wil liam Y. Chen Wen-mei W. Hwu Abstract To e ectively exploit instruction level parallelism, the compiler must move instructions across branches. When an instruction is moved ab ove a branch that it is control dep endent on, it is considered to b e sp eculatively executed since it is executed b efore it is known whether or not its result is needed. There are p otential hazards when sp eculatively executing instructions. If these hazards can b e eliminated, the compiler can more aggressively schedule the co de. The hazards of sp eculative execution are outlined in this pap er. Three architectural mo dels: re- stricted, general and b o osting, whichhave increasing amounts of supp ort for removing these hazards are discussed. The p erformance gained by each level of additional hardware supp ort is analyzed using the IMPACT C compiler which p erforms sup erblo ckscheduling for sup erscalar and sup erpip elined pro cessors. Index terms - Conditional branches, exception handling, sp eculative execution, static co de scheduling, sup erblo ck, sup erpip elining, sup erscalar. The authors are with the Center for Reliable and High-Performance Computing, University of Illinois, Urbana- Champaign, Illinoi s, 61801. 1 1 Intro duction For non-numeric programs, there is insucient instruction level parallelism available within a basic blo ck to exploit sup erscalar and sup erpip eli ned pro cessors [1][2][3]. Toschedule instructions b eyond the basic blo ck b oundary, instructions havetobemoved across conditional branches.
    [Show full text]
  • Opportunities and Open Problems for Static and Dynamic Program Analysis Mark Harman∗, Peter O’Hearn∗ ∗Facebook London and University College London, UK
    1 From Start-ups to Scale-ups: Opportunities and Open Problems for Static and Dynamic Program Analysis Mark Harman∗, Peter O’Hearn∗ ∗Facebook London and University College London, UK Abstract—This paper1 describes some of the challenges and research questions that target the most productive intersection opportunities when deploying static and dynamic analysis at we have yet witnessed: that between exciting, intellectually scale, drawing on the authors’ experience with the Infer and challenging science, and real-world deployment impact. Sapienz Technologies at Facebook, each of which started life as a research-led start-up that was subsequently deployed at scale, Many industrialists have perhaps tended to regard it unlikely impacting billions of people worldwide. that much academic work will prove relevant to their most The paper identifies open problems that have yet to receive pressing industrial concerns. On the other hand, it is not significant attention from the scientific community, yet which uncommon for academic and scientific researchers to believe have potential for profound real world impact, formulating these that most of the problems faced by industrialists are either as research questions that, we believe, are ripe for exploration and that would make excellent topics for research projects. boring, tedious or scientifically uninteresting. This sociological phenomenon has led to a great deal of miscommunication between the academic and industrial sectors. I. INTRODUCTION We hope that we can make a small contribution by focusing on the intersection of challenging and interesting scientific How do we transition research on static and dynamic problems with pressing industrial deployment needs. Our aim analysis techniques from the testing and verification research is to move the debate beyond relatively unhelpful observations communities to industrial practice? Many have asked this we have typically encountered in, for example, conference question, and others related to it.
    [Show full text]
  • A Parallel Program Execution Model Supporting Modular Software Construction
    A Parallel Program Execution Model Supporting Modular Software Construction Jack B. Dennis Laboratory for Computer Science Massachusetts Institute of Technology Cambridge, MA 02139 U.S.A. [email protected] Abstract as a guide for computer system design—follows from basic requirements for supporting modular software construction. A watershed is near in the architecture of computer sys- The fundamental theme of this paper is: tems. There is overwhelming demand for systems that sup- port a universal format for computer programs and software The architecture of computer systems should components so users may benefit from their use on a wide reflect the requirements of the structure of pro- variety of computing platforms. At present this demand is grams. The programming interface provided being met by commodity microprocessors together with stan- should address software engineering issues, in dard operating system interfaces. However, current systems particular, the ability to practice the modular do not offer a standard API (application program interface) construction of software. for parallel programming, and the popular interfaces for parallel computing violate essential principles of modular The positions taken in this presentation are contrary to or component-based software construction. Moreover, mi- much conventional wisdom, so I have included a ques- croprocessor architecture is reaching the limit of what can tion/answer dialog at appropriate places to highlight points be done usefully within the framework of superscalar and of debate. We start with a discussion of the nature and VLIW processor models. The next step is to put several purpose of a program execution model. Our Parallelism processors (or the equivalent) on a single chip.
    [Show full text]
  • Visual Representations of Executing Programs
    Visual Representations of Executing Programs Steven P. Reiss Department of Computer Science Brown University Providence, RI 02912-1910 401-863-7641, FAX: 401-863-7657 {spr}@cs.brown.edu Abstract Programmers have always been curious about what their programs are doing while it is exe- cuting, especially when the behavior is not what they are expecting. Since program execution is intricate and involved, visualization has long been used to provide the programmer with appro- priate insights into program execution. This paper looks at the evolution of on-line visual repre- sentations of executing programs, showing how they have moved from concrete representations of relatively small programs to abstract representations of larger systems. Based on this examina- tion, we describe the challenges implicit in future execution visualizations and methodologies that can meet these challenges. 1. Introduction An on-line visual representation of an executing program is a graphical display that provides information about what a program is doing as the program does it. Visualization is used to make the abstract notion of a computer executing a program concrete in the mind of the programmer. The concurrency of the visualization in con- junction with the execution lets the programmer correlate real time events (e.g., inputs, button presses, error messages, or unexpected delays) with the visualization, making the visualization more useful and meaningful. Visual representations of executing programs have several uses. First, they have traditionally been used for program understanding as can be seen from their use in most algorithm animation systems [37,52]. Second, in various forms they have been integrated into debuggers and used for debugging [2,31].
    [Show full text]
  • Identifying Executable Plans
    Identifying executable plans Tania Bedrax-Weiss∗ Jeremy D. Frank Ari K. J´onssony Conor McGann∗ NASA Ames Research Center, MS 269-2 Moffett Field, CA 94035-1000, ftania,frank,jonsson,[email protected] Abstract AI solutions for planning and plan execution often use declarative models to describe the domain of interest. Generating plans for execution imposes a different set The planning system typically uses an abstract, long- of requirements on the planning process than those im- term model and the execution system typically uses a posed by planning alone. In highly unpredictable ex- ecution environments, a fully-grounded plan may be- concrete, short-term model. In most systems that deal come inconsistent frequently when the world fails to with planning and execution, the language used in the behave as expected. Intelligent execution permits mak- declarative model for planning is different than the lan- ing decisions when the most up-to-date information guage used in the execution model. This approach en- is available, ensuring fewer failures. Planning should forces a rigid separation between the planning model acknowledge the capabilities of the execution system, and the execution model. The execution system and the both to ensure robust execution in the face of uncer- planning system have to agree on the semantics of the tainty, which also relieves the planner of the burden plan, and having two separate models requires the sys- of making premature commitments. We present Plan tem designer to replicate the information contained in Identification Functions (PIFs), which formalize what the planning model in the execution model.
    [Show full text]
  • INTRODUCTION to .NET FRAMEWORK NET Framework .NET Framework Is a Complete Environment That Allows Developers to Develop, Run, An
    INTRODUCTION TO .NET FRAMEWORK NET Framework .NET Framework is a complete environment that allows developers to develop, run, and deploy the following applications: Console applications Windows Forms applications Windows Presentation Foundation (WPF) applications Web applications (ASP.NET applications) Web services Windows services Service-oriented applications using Windows Communication Foundation (WCF) Workflow-enabled applications using Windows Workflow Foundation (WF) .NET Framework also enables a developer to create sharable components to be used in distributed computing architecture. NET Framework supports the object-oriented programming model for multiple languages, such as Visual Basic, Visual C#, and Visual C++. NET Framework supports multiple programming languages in a manner that allows language interoperability. This implies that each language can use the code written in some other language. The main components of .NET Framework? The following are the key components of .NET Framework: .NET Framework Class Library Common Language Runtime Dynamic Language Runtimes (DLR) Application Domains Runtime Host Common Type System Metadata and Self-Describing Components Cross-Language Interoperability .NET Framework Security Profiling Side-by-Side Execution Microsoft Intermediate Language (MSIL) The .NET Framework is shipped with compilers of all .NET programming languages to develop programs. Each .NET compiler produces an intermediate code after compiling the source code. 1 The intermediate code is common for all languages and is understandable only to .NET environment. This intermediate code is known as MSIL. IL Intermediate Language is also known as MSIL (Microsoft Intermediate Language) or CIL (Common Intermediate Language). All .NET source code is compiled to IL. IL is then converted to machine code at the point where the software is installed, or at run-time by a Just-In-Time (JIT) compiler.
    [Show full text]
  • EXE: Automatically Generating Inputs of Death
    EXE: Automatically Generating Inputs of Death Cristian Cadar, Vijay Ganesh, Peter M. Pawlowski, David L. Dill, Dawson R. Engler Computer Systems Laboratory Stanford University Stanford, CA 94305, U.S.A {cristic, vganesh, piotrek, dill, engler} @cs.stanford.edu ABSTRACT 1. INTRODUCTION This paper presents EXE, an effective bug-finding tool that Attacker-exposed code is often a tangled mess of deeply- automatically generates inputs that crash real code. Instead nested conditionals, labyrinthine call chains, huge amounts of running code on manually or randomly constructed input, of code, and frequent, abusive use of casting and pointer EXE runs it on symbolic input initially allowed to be “any- operations. For safety, this code must exhaustively vet in- thing.” As checked code runs, EXE tracks the constraints put received directly from potential attackers (such as sys- on each symbolic (i.e., input-derived) memory location. If a tem call parameters, network packets, even data from USB statement uses a symbolic value, EXE does not run it, but sticks). However, attempting to guard against all possible instead adds it as an input-constraint; all other statements attacks adds significant code complexity and requires aware- run as usual. If code conditionally checks a symbolic ex- ness of subtle issues such as arithmetic and buffer overflow pression, EXE forks execution, constraining the expression conditions, which the historical record unequivocally shows to be true on the true branch and false on the other. Be- programmers reason about poorly. cause EXE reasons about all possible values on a path, it Currently, programmers check for such errors using a com- has much more power than a traditional runtime tool: (1) bination of code review, manual and random testing, dy- it can force execution down any feasible program path and namic tools, and static analysis.
    [Show full text]
  • Code Transformation and Analysis Using Clang and LLVM Static and Dynamic Analysis
    Code transformation and analysis using Clang and LLVM Static and Dynamic Analysis Hal Finkel1 and G´abor Horv´ath2 Computer Science Summer School 2017 1 Argonne National Laboratory 2 Ericsson and E¨otv¨osLor´adUniversity Table of contents 1. Introduction 2. Static Analysis with Clang 3. Instrumentation and More 1 Introduction Space of Techniques During this set of lectures we'll cover a space of techniques for the analysis and transformation of code using LLVM. Each of these techniques have overlapping areas of applicability: Static Analysis LLVM Instrumentation Source Transformation 2 Space of Techniques When to use source-to-source transformation: • When you need to use the instrumented code with multiple compilers. • When you intend for the instrumentation to become a permanent part of the code base. You'll end up being concerned with the textual formatting of the instrumentation if humans also need to maintain or enhance this same code. 3 Space of Techniques When to use Clang's static analysis: • When the analysis can be performed on an AST representation. • When you'd like to maintain a strong connection to the original source code. • When false negatives are acceptable (i.e. it is okay if you miss problems). https://clang-analyzer.llvm.org/ 4 Space of Techniques When to use IR instrumentation: • When the necessary conditions can be (or can only be) detected at runtime (often in conjunction with a specialized runtime library). • When you require stronger coverage guarantees than static analysis. • When you'd like to reduce the cost of the instrumentation by running optimizations before the instrumentation is inserted, after the instrumentation is inserted, or both.
    [Show full text]
  • The Trusted Execution Module: Commodity General-Purpose Trusted Computing
    The Trusted Execution Module: Commodity General-Purpose Trusted Computing Victor Costan, Luis F. G. Sarmenta, Marten van Dijk, and Srinivas Devadas MIT Computer Science and Artificial Intelligence Laboratory, Cambridge, USA [email protected], {lfgs,marten,devadas}@mit.edu Abstract. This paper introduces the Trusted Execution Module (TEM); a high-level specification for a commodity chip that can execute user- supplied procedures in a trusted environment. The TEM is capable of se- curely executing partially-encrypted procedures/closures expressing ar- bitrary computation. These closures can be generated by any (potentially untrusted) party who knows the TEM’s public encryption key. Compared to a conventional smartcard, which is typically used by pre-programming a limited set of domain- or application- specific commands onto the smartcard, and compared to the Trusted Platform Module (TPM), which is limited to a fixed set of cryptographic functions that cannot be com- bined to provide general-purpose trusted computing, the TEM is sig- nificantly more flexible. Yet we present a working implementation us- ing existing inexpensive Javacard smartcards that does not require any export-restricted technology. The TEM’s design enables a new style of programming, which in turn enables new applications. We show that the TEM’s guarantees of secure execution enable exciting applications that include, but are not limited to, mobile agents, peer-to-peer multiplayer online games, and anonymous offline payments. 1 Introduction The Trusted Execution Module (TEM) is a Trusted Computing Base (TCB) de- signed for the low-resource environments of inexpensive commercially-available secure chips. The TEM can securely execute small computations expressed as partially-encrypted compiled closures.
    [Show full text]
  • Embedded System Tools Reference Manual (UG1043)
    Embedded System Tools Reference Manual UG1043 (v2016.3)(v2016.1) OctoberApril 06, 5, 2016 2016 Revision History The10/05/2016: following Released table shows with Vivado the revi Designsion history Suite 2016.3 for this wi thoutdocument. changes from 2016.1. Date Version Revision 04/06/2016 2016.1 Added information about the supported processors and compilers. Added references to Zynq® UltraScale+™ MPSoC related documentation. Embedded System Tools Reference Manual www.xilinx.com Send Feedback 2 UG1043 (v2016.3)(v2016.1) October April 06, 5, 2016 2016 Table of Contents Revision History . 2 Chapter 1: Embedded System and Tools Architecture Overview Design Process Overview. 6 Vivado Design Suite Overview . 8 Software Development Kit . 9 Chapter 2: GNU Compiler Tools Overview . 12 Compiler Framework . 12 Common Compiler Usage and Options . 14 MicroBlaze Compiler Usage and Options. 29 ARM Cortex-A9 Compiler Usage and Options . 46 Other Notes . 48 Chapter 3: Xilinx System Debugger SDK System Debugger . 50 Xilinx System Debugger Command-Line Interface (XSDB) . 51 Chapter 4: Flash Memory Programming Overview . 52 Program Flash Utility . 53 Other Notes . 55 Appendix A: GNU Utilities General Purpose Utility for MicroBlaze Processors. 60 Utilities Specific to MicroBlaze Processors. 60 Other Programs and Files . 63 Appendix B: Additional Resources and Legal Notices Xilinx Resources . 64 Solution Centers. 64 Documentation Navigator and Design Hubs . 64 Embedded System Tools Reference Manual www.xilinx.com Send Feedback 3 UG1043 (v2016.3)(v2016.1) October April 06, 5, 2016 2016 References . 65 Training Resources. 65 Please Read: Important Legal Notices . 66 Embedded System Tools Reference Manual www.xilinx.com Send Feedback 4 UG1043 (v2016.3)(v2016.1) October April 06, 5, 2016 2016 Chapter 1 Embedded System and Tools Architecture Overview This guide describes the architecture of the embedded system tools and flows provided in the Xilinx® Vivado® Design Suite for developing systems based on the MicroBlaze™ embedded processor and the Cortex A9, A53 and R5 ARM processors.
    [Show full text]
  • Effective Compiler Support for Predicated Execution Using the Hyperblock
    Effective Compiler Support for Predicated Execution Using the Hyperblock Scott A. Mahlke David C. Lin’ William Y. Chen Richard E. Hank Roger A. Bringmann Center for Reliable and High-Performance Computing University of Illinois Urbana-Champaign, IL 61801 Abstract on the branch are then converted to predicated instructions dependent on the value of the corresponding predicate. In Predicated execution is an effective technique for dealing this manner, control dependences are converted to data de- with conditional branches in application programs. How- pendences in the code. If-conversion can eliminate all non- ever, there are several problems associated with conventional loop backward branches from a program. compiler support for predicated execution. First, all paths Predicated execution support has been used effectively for of control are combined into a single path regardless of their scheduling both numeric and non-numeric applications. For execution frequency and size with conventional if-conversion numeric code, overlapping the execution of multiple loop it- techniques. Second, speculative execution is difficult to com- erations using software pipeline scheduling can achieve high- bine with predicated execution. In this paper, we propose performance on superscalar and VLIW processors [4] [5] [6]. the use of a new structure, referred to as the hyperblock, With the abiity to remove branches with predicated exe- to overcome these problems. The hyperblock is an efficient cution support, more compact schedules and reduced code structure to utilize predicated execution for both compile- expansion are achieved with software pipelining. Software time optimization and scheduling. Preliminary experimen- pipelining taking advantage of predicated execution sup- tal results show that the hyperblock is highly effective for a port is productized in the Cydra 5 compiler [7] [8].
    [Show full text]
  • Symbolic Execution of Java Byte-Code
    Symbolic Execution of Java Byte-code Corina Pãsãreanu Perot Systems/NASA Ames Research ISSTA’08 paper: “Combining Unit-level Symbolic Execution and System-level Concrete Execution for Testing NASA Software” Corina Pãsãreanu, Peter Mehlitz, David Bushnell, Karen Gundy-Burlet, Michael Lowry (NASA Ames) Suzette Person (University of Nebraska, Lincoln) Mark Pape (NASA JSC) Automatic Test Input Generation • Objective: – Develop automated techniques for error detection in complex, flight control software for manned space missions • Solutions: – Model checking – automatic, exhaustive; suffers from scalability issues – Static analysis – automatic, scalable, exhaustive; reported errors may be spurious – Testing – reported errors are real; may miss errors; widely used • Our solution: Symbolic Java PathFinder (Symbolic JPF) – Symbolic execution with model checking and constraint solving for automatic test input generation – Generates test suites that obtain high coverage for flexible (user-definable) coverage metrics – During test generation process, checks for errors – Uses the analysis engine of the Ames JPF tool – Freely available at: http://javapathfinder.sourceforge.net (symbc extension) Symbolic JPF • Implements a non-standard interpreter of byte-codes – To enable JPF to perform symbolic analysis • Symbolic information: – Stored in attributes associated with the program data – Propagated dynamically during symbolic execution • Handles: – Mixed integer/real constraints – Complex Math functions – Pre-conditions, multithreading • Allows for mixed concrete and symbolic execution – Start symbolic execution at any point in the program and at any time during execution – Dynamic modification of execution semantics – Changing mid-stream from concrete to symbolic execution • Application: – Testing a prototype NASA flight software component – Found serious bug that resulted in design changes to the software Background: Model Checking vs.
    [Show full text]