DOCSLIB.ORG

A Source-To-Source Translator Using Clang/LLVM Libtooling

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Source-To-Source Translator Using Clang/LLVM Libtooling 1 OP2-Clang: A Source-to-Source Translator Using Clang/LLVM LibTooling G.D. Balogh1, G.R. Mudalige2, I.Z. Reguly1, S.F. Antao3, C. Bertolli3 Abstract—Domain Specific Languages or Active Library LibTooling, CUDA, OpenMP, automatic parallelization, frameworks have recently emerged as an important method DSL, OP2, unstructured-mesh for gaining performance portability, where an application I. INTRODUCTION can be efficiently executed on a wide range of HPC architec- tures without significant manual modifications. Embedded Domain Specific Languages or Active Library frame- DSLs such as OP2, provides an API embedded in general works provide higher-level abstraction mechanisms, us- purpose languages such as C/C++/Fortran. They rely on ing which applications can be developed by scientists source-to-source translation and code refactorization to translate the higher-level API calls to platform specific and engineers. Particularly when developing numeri- parallel implementations. OP2 targets the solution of cal simulation programs for parallel high-performance unstructured-mesh computations, where it can generate computing systems, these frameworks boost both pro- a variety of parallel implementations for execution on grammers’ productivity and application performance by architectures such as CPUs, GPUs, distributed memory separating the concerns of programming the numerical clusters and heterogeneous processors making use of a wide range of platform specific optimizations. Compiler solution from its parallel implementation. As such, they tool-chains supporting source-to-source translation of code have recently emerged as an important method for written in mainstream languages currently lack the capabil- gaining performance portability, where an application ities to carry out such wide-ranging code transformations. can be efficiently executed on a wide range of HPC Clang/LLVM’s Tooling library (LibTooling) has long been architectures without significant manual modifications. touted as having such capabilities but have only demon- strated its use in simple source refactoring tasks. Embedded DSLs (eDSLs) such as OP2 provide a In this paper we introduce OP2-Clang, a source-to- domain specific API embedded in C/C++ and For- source translator based on LibTooling, for OP2’s C/C++ tran [1], [2]. The API appears as calls to functions in API, capable of generating target parallel code based on a classical software library to the application developer. SIMD, OpenMP, CUDA and their combinations with MPI. However, OP2 can then make use of extensive source- OP2-Clang is designed to significantly reduce maintenance, to-source translation and code refactorization to translate particularly making it easy to be extended to generate new parallelizations and optimizations for hardware platforms. the higher-level API calls to platform specific parallel In this research, we demonstrate its capabilities including implementations. In the case of OP2, which provides (1) the use of LibTooling’s AST matchers together with a a high-level domain specific abstraction for the solu- simple strategy that use parallelization templates or skele- tion of unstructured-mesh applications, the source-to- tons to significantly reduce the complexity of generating source translation can generate a wide range of parallel radically different and transformed target code and (2) chart the challenges and solution to generating optimized implementations for execution on architectures such as parallelizations for OpenMP, SIMD and CUDA. Results CPUs, GPUs, distributed memory clusters and emerging indicate that OP2-Clang produces near-identical parallel heterogeneous processors. The generated code makes use code to that of OP2’s current source-to-source translator. of parallel programming models/extensions including We believe that the lessons learnt in OP2-Clang can be SIMD-vectorization, OpenMP3.0/4.0, CUDA, OpenACC readily applied to developing other similar source-to-source translators, particularly for DSLs. and their combinations with MPI. Furthermore they implement the best platform specific optimizations, in- Index Terms—Source-to-source translation, Clang, cluding sophisticated orchestration of parallelizations to handle data races, optimized data layout and accesses, *The following names are subject to trademark: LLVM™, CLANG™, NVIDIA™, P100™, CUDA™, INTEL™, embedding of parameters/flags that allow to tune the 1G.D. Balogh and I.Z. Reguly is with the Faculty of In- performance at runtime and even facilitate runtime- formation Technology and Bionics, Pázmány Péter Catholic Uni- optimizations for gaining further performance. versity, Hungary. [email protected], [email protected] Compiler tool-chains supporting source-to-source 2G.R. Mudalige is with the Department of Computer Science, translation of code written in mainstream languages University of Warwick, UK. [email protected] such as C/C++ or Fortran currently lack the capabil- 3C. Bertolli and S.F. Antao is with the IBM T.J. Watson Research Center, USA. [email protected], ities to carry out such wide-ranging code transforma- [email protected] tions. Available tool-chains such as the ROSE compiler 2 framework [3], [4], [5] and others, have suffered from Clang/LLVM. In this research, we chart the development a lack of adoption by both the compilers and HPC of OP2-Clang, outlining its design and architecture. community. This has been a major factor in limiting More specifically we make the following contributions. the wider adoption of DSLs or active libraries with a • We demonstrate how Clang’s LibTooling can be non-conventional source-to-source translator where there used for source-to-source translations as required by is a lack of a significant community of developers OP2 where the target code includes wide-ranging under open governance to maintain it. The result is code transformations such as SIMD-vectorization, often a highly complicated tool with a narrow focus, OpenMP, CUDA and their combinations with MPI. steep learning curve, inflexible for easy extension to Such a wide range of source-to-source target code produce different target code (e.g. new optimizations, generation have not been previously demonstrated new parallelizations for different hardware, etc.) and either using LibTooling nor any other Clang/LLVM issues with long-term maintenance. In other words, the compiler tool. lack of industrial-strength tooling that can be integrated • We present the design, including the use of LibTool- in a DevOps toolchain without any changes provokes a ing’s AST matchers together with a novel strategy lack of growth in the numbers of users and developers that use parallelization templates or skeletons to for DSLs or active libraries, which in turn is the source reduce the complexity of the translator. The use of missing tools themselves, leading to a typical catch- of skeletons allows to significantly reduce the code 22 or deadlock situation. The underlying motivation of that needs to be generated from scratch and help the research presented in this paper is to break this modularize the translator to be easily extensible deadlock by pioneering the introduction of a industrial- with new parallelizations. strength compiler toolchain, to come-up with a standard • OP2-Clang is used for generating parallel code (or a methodology) that can be integrated as is in most for two unstructured mesh applications written DevOps environments. using the OP2 API: (1) an industrial represen- Clang/LLVM’s Tooling library (libTooling) [6] has tative Airfoil [11] CFD application and (2) a long been touted as facilitating source-to-source trans- production-grade Tsunami simulation application lation capabilities but have only demonstrated its use in called Volna [12], [13]. The performance of the simple source refactoring and code generation tasks [7], generated parallelizations is compared to code gen- [8] or in the transformation of a very limited subset of erated by OP2’s current source-to-source translator algorithms without hardware specific optimizations [9]. demonstrating identical performance on a number In this paper we introduce OP2-Clang [10], a source-to- of multi-core/many-core systems. source translator based on Clang’s LibTooling for OP2. The work described in this paper is the first step towards The broader aim is to generate platform specific parallel an application-driven full stack optimizer toolchain codes for unstructured-mesh applications written with based on Clang/LLVM. The rest of this paper is orga- OP2. Two options to achieve this are: (1) translating nized as follows. In SectionII we briefly introduce the programs written with OP2’s C/C++ API, to code with motivation driving this work, including eDSLs such as C++ parallelised with SIMD, OpenMP, CUDA, and their OP2 and limitations of current source-to-source trans- combinations with MPI etc., that can then be compiled lation software. In Section III we chart the design and by conventional platform specific compilers and (2) com- development of OP2-Clang. In SectionIV we illustrate piling programs written with OP2’s C/C++ API to LLVM the ease of extending the tool charting the case for IR. The former case, which is the subject of this paper, the SIMD-vectorization and CUDA code generator. In follows OP2’s current application development process SectionV we evaluate the performance of the gener- and has been shown to deliver significant performance ated parallel code and compare the results to the code improvements. The latter case, which will be explored generated
Load more

Recommended publications
  • Compilers & Translator Writing Systems
    Compilers & Translators Compilers & Translator Writing Systems Prof. R. Eigenmann ECE573, Fall 2005 http://www.ece.purdue.edu/~eigenman/ECE573 ECE573, Fall 2005 1 Compilers are Translators Fortran Machine code C Virtual machine code C++ Transformed source code Java translate Augmented source Text processing language code Low-level commands Command Language Semantic components Natural language ECE573, Fall 2005 2 ECE573, Fall 2005, R. Eigenmann 1 Compilers & Translators Compilers are Increasingly Important Specification languages Increasingly high level user interfaces for ↑ specifying a computer problem/solution High-level languages ↑ Assembly languages The compiler is the translator between these two diverging ends Non-pipelined processors Pipelined processors Increasingly complex machines Speculative processors Worldwide “Grid” ECE573, Fall 2005 3 Assembly code and Assemblers assembly machine Compiler code Assembler code Assemblers are often used at the compiler back-end. Assemblers are low-level translators. They are machine-specific, and perform mostly 1:1 translation between mnemonics and machine code, except: – symbolic names for storage locations • program locations (branch, subroutine calls) • variable names – macros ECE573, Fall 2005 4 ECE573, Fall 2005, R. Eigenmann 2 Compilers & Translators Interpreters “Execute” the source language directly. Interpreters directly produce the result of a computation, whereas compilers produce executable code that can produce this result. Each language construct executes by invoking a subroutine of the interpreter, rather than a machine instruction. Examples of interpreters? ECE573, Fall 2005 5 Properties of Interpreters “execution” is immediate elaborate error checking is possible bookkeeping is possible. E.g. for garbage collection can change program on-the-fly. E.g., switch libraries, dynamic change of data types machine independence.
    [Show full text]
  • Source-To-Source Translation and Software Engineering
    Journal of Software Engineering and Applications, 2013, 6, 30-40 http://dx.doi.org/10.4236/jsea.2013.64A005 Published Online April 2013 (http://www.scirp.org/journal/jsea) Source-to-Source Translation and Software Engineering David A. Plaisted Department of Computer Science, University of North Carolina at Chapel Hill, Chapel Hill, USA. Email: [email protected] Received February 5th, 2013; revised March 7th, 2013; accepted March 15th, 2013 Copyright © 2013 David A. Plaisted. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. ABSTRACT Source-to-source translation of programs from one high level language to another has been shown to be an effective aid to programming in many cases. By the use of this approach, it is sometimes possible to produce software more cheaply and reliably. However, the full potential of this technique has not yet been realized. It is proposed to make source- to-source translation more effective by the use of abstract languages, which are imperative languages with a simple syntax and semantics that facilitate their translation into many different languages. By the use of such abstract lan- guages and by translating only often-used fragments of programs rather than whole programs, the need to avoid writing the same program or algorithm over and over again in different languages can be reduced. It is further proposed that programmers be encouraged to write often-used algorithms and program fragments in such abstract languages. Libraries of such abstract programs and program fragments can then be constructed, and programmers can be encouraged to make use of such libraries by translating their abstract programs into application languages and adding code to join things together when coding in various application languages.
    [Show full text]
  • The LLVM Instruction Set and Compilation Strategy
    The LLVM Instruction Set and Compilation Strategy Chris Lattner Vikram Adve University of Illinois at Urbana-Champaign lattner,vadve ¡ @cs.uiuc.edu Abstract This document introduces the LLVM compiler infrastructure and instruction set, a simple approach that enables sophisticated code transformations at link time, runtime, and in the field. It is a pragmatic approach to compilation, interfering with programmers and tools as little as possible, while still retaining extensive high-level information from source-level compilers for later stages of an application’s lifetime. We describe the LLVM instruction set, the design of the LLVM system, and some of its key components. 1 Introduction Modern programming languages and software practices aim to support more reliable, flexible, and powerful software applications, increase programmer productivity, and provide higher level semantic information to the compiler. Un- fortunately, traditional approaches to compilation either fail to extract sufficient performance from the program (by not using interprocedural analysis or profile information) or interfere with the build process substantially (by requiring build scripts to be modified for either profiling or interprocedural optimization). Furthermore, they do not support optimization either at runtime or after an application has been installed at an end-user’s site, when the most relevant information about actual usage patterns would be available. The LLVM Compilation Strategy is designed to enable effective multi-stage optimization (at compile-time, link-time, runtime, and offline) and more effective profile-driven optimization, and to do so without changes to the traditional build process or programmer intervention. LLVM (Low Level Virtual Machine) is a compilation strategy that uses a low-level virtual instruction set with rich type information as a common code representation for all phases of compilation.
    [Show full text]
  • Tdb: a Source-Level Debugger for Dynamically Translated Programs
    Tdb: A Source-level Debugger for Dynamically Translated Programs Naveen Kumar†, Bruce R. Childers†, and Mary Lou Soffa‡ †Department of Computer Science ‡Department of Computer Science University of Pittsburgh University of Virginia Pittsburgh, Pennsylvania 15260 Charlottesville, Virginia 22904 {naveen, childers}@cs.pitt.edu [email protected] Abstract single stepping through program execution, watching for par- ticular conditions and requests to add and remove breakpoints. Debugging techniques have evolved over the years in response In order to respond, the debugger has to map the values and to changes in programming languages, implementation tech- statements that the user expects using the source program niques, and user needs. A new type of implementation vehicle viewpoint, to the actual values and locations of the statements for software has emerged that, once again, requires new as found in the executable program. debugging techniques. Software dynamic translation (SDT) As programming languages have evolved, new debugging has received much attention due to compelling applications of techniques have been developed. For example, checkpointing the technology, including software security checking, binary and time stamping techniques have been developed for lan- translation, and dynamic optimization. Using SDT, program guages with concurrent constructs [6,19,30]. The pervasive code changes dynamically, and thus, debugging techniques use of code optimizations to improve performance has necessi- developed for statically generated code cannot be used to tated techniques that can respond to queries even though the debug these applications. In this paper, we describe a new optimization may have changed the number of statement debug architecture for applications executing with SDT sys- instances and the order of execution [15,25,29].
    [Show full text]
  • Virtual Machine Part II: Program Control
    Virtual Machine Part II: Program Control Building a Modern Computer From First Principles www.nand2tetris.org Elements of Computing Systems, Nisan & Schocken, MIT Press, www.nand2tetris.org , Chapter 8: Virtual Machine, Part II slide 1 Where we are at: Human Abstract design Software abstract interface Thought Chapters 9, 12 hierarchy H.L. Language Compiler & abstract interface Chapters 10 - 11 Operating Sys. Virtual VM Translator abstract interface Machine Chapters 7 - 8 Assembly Language Assembler Chapter 6 abstract interface Computer Machine Architecture abstract interface Language Chapters 4 - 5 Hardware Gate Logic abstract interface Platform Chapters 1 - 3 Electrical Chips & Engineering Hardware Physics hierarchy Logic Gates Elements of Computing Systems, Nisan & Schocken, MIT Press, www.nand2tetris.org , Chapter 8: Virtual Machine, Part II slide 2 The big picture Some . Some Other . Jack language language language Chapters Some Jack compiler Some Other 9-13 compiler compiler Implemented in VM language Projects 7-8 VM implementation VM imp. VM imp. VM over the Hack Chapters over CISC over RISC emulator platforms platforms platform 7-8 A Java-based emulator CISC RISC is included in the course written in Hack software suite machine machine . a high-level machine language language language language Chapters . 1-6 CISC RISC other digital platforms, each equipped Any Hack machine machine with its VM implementation computer computer Elements of Computing Systems, Nisan & Schocken, MIT Press, www.nand2tetris.org , Chapter 8: Virtual Machine,
    [Show full text]
  • What Is LLVM? and a Status Update
    What is LLVM? And a Status Update. Approved for public release Hal Finkel Leadership Computing Facility Argonne National Laboratory Clang, LLVM, etc. ✔ LLVM is a liberally-licensed(*) infrastructure for creating compilers, other toolchain components, and JIT compilation engines. ✔ Clang is a modern C++ frontend for LLVM ✔ LLVM and Clang will play significant roles in exascale computing systems! (*) Now under the Apache 2 license with the LLVM Exception LLVM/Clang is both a research platform and a production-quality compiler. 2 A role in exascale? Current/Future HPC vendors are already involved (plus many others)... Apple + Google Intel (Many millions invested annually) + many others (Qualcomm, Sony, Microsoft, Facebook, Ericcson, etc.) ARM LLVM IBM Cray NVIDIA (and PGI) Academia, Labs, etc. AMD 3 What is LLVM: LLVM is a multi-architecture infrastructure for constructing compilers and other toolchain components. LLVM is not a “low-level virtual machine”! LLVM IR Architecture-independent simplification Architecture-aware optimization (e.g. vectorization) Assembly printing, binary generation, or JIT execution Backends (Type legalization, instruction selection, register allocation, etc.) 4 What is Clang: LLVM IR Clang is a C++ frontend for LLVM... Code generation Parsing and C++ Source semantic analysis (C++14, C11, etc.) Static analysis ● For basic compilation, Clang works just like gcc – using clang instead of gcc, or clang++ instead of g++, in your makefile will likely “just work.” ● Clang has a scalable LTO, check out: https://clang.llvm.org/docs/ThinLTO.html 5 The core LLVM compiler-infrastructure components are one of the subprojects in the LLVM project. These components are also referred to as “LLVM.” 6 What About Flang? ● Started as a collaboration between DOE and NVIDIA/PGI.
    [Show full text]
  • A DSL for Resource Checking Using Finite State Automaton-Driven Symbolic Execution Code
    Open Comput. Sci. 2021; 11:107–115 Research Article Endre Fülöp and Norbert Pataki* A DSL for Resource Checking Using Finite State Automaton-Driven Symbolic Execution https://doi.org/10.1515/comp-2020-0120 code. Compilers validate the syntactic elements, referred Received Mar 31, 2020; accepted May 28, 2020 variables, called functions to name a few. However, many problems may remain undiscovered. Abstract: Static analysis is an essential way to find code Static analysis is a widely-used method which is by smells and bugs. It checks the source code without exe- definition the act of uncovering properties and reasoning cution and no test cases are required, therefore its cost is about software without observing its runtime behaviour, lower than testing. Moreover, static analysis can help in restricting the scope of tools to those which operate on the software engineering comprehensively, since static anal- source representation, the code written in a single or mul- ysis can be used for the validation of code conventions, tiple programming languages. While most static analysis for measuring software complexity and for executing code methods are designed to detect anomalies (called bugs) in refactorings as well. Symbolic execution is a static analy- software code, the methods they employ are varied [1]. One sis method where the variables (e.g. input data) are inter- major difference is the level of abstraction at which the preted with symbolic values. code is represented [2]. Because static analysis is closely Clang Static Analyzer is a powerful symbolic execution related to the compilation of the code, the formats used engine based on the Clang compiler infrastructure that to represent the different abstractions are not unique to can be used with C, C++ and Objective-C.
    [Show full text]
  • SMT-Based Refutation of Spurious Bug Reports in the Clang Static Analyzer
    SMT-Based Refutation of Spurious Bug Reports in the Clang Static Analyzer Mikhail R. Gadelha∗, Enrico Steffinlongo∗, Lucas C. Cordeiroy, Bernd Fischerz, and Denis A. Nicole∗ ∗University of Southampton, UK. yUniversity of Manchester, UK. zStellenbosch University, South Africa. Abstract—We describe and evaluate a bug refutation extension bit in a is one, and (a & 1) ˆ 1 inverts the last bit in a. for the Clang Static Analyzer (CSA) that addresses the limi- The analyzer, however, produces the following (spurious) bug tations of the existing built-in constraint solver. In particular, report when analyzing the program: we complement CSA’s existing heuristics that remove spurious bug reports. We encode the path constraints produced by CSA as Satisfiability Modulo Theories (SMT) problems, use SMT main.c:4:12: warning: Dereference of null solvers to precisely check them for satisfiability, and remove pointer (loaded from variable ’z’) bug reports whose associated path constraints are unsatisfi- return *z; able. Our refutation extension refutes spurious bug reports in ˆ˜ 8 out of 12 widely used open-source applications; on aver- age, it refutes ca. 7% of all bug reports, and never refutes 1 warning generated. any true bug report. It incurs only negligible performance overheads, and on average adds 1.2% to the runtime of the The null pointer dereference reported here means that CSA full Clang/LLVM toolchain. A demonstration is available at claims to nevertheless have found a path where the dereference https://www.youtube.com/watch?v=ylW5iRYNsGA. of z is reachable. Such spurious bug reports are in practice common; in our I.
    [Show full text]
  • CUDA Flux: a Lightweight Instruction Profiler for CUDA Applications
    CUDA Flux: A Lightweight Instruction Profiler for CUDA Applications Lorenz Braun Holger Froning¨ Institute of Computer Engineering Institute of Computer Engineering Heidelberg University Heidelberg University Heidelberg, Germany Heidelberg, Germany [email protected] [email protected] Abstract—GPUs are powerful, massively parallel processors, hardware, it lacks verbosity when it comes to analyzing the which require a vast amount of thread parallelism to keep their different types of instructions executed. This problem is aggra- thousands of execution units busy, and to tolerate latency when vated by the recently frequent introduction of new instructions, accessing its high-throughput memory system. Understanding the behavior of massively threaded GPU programs can be for instance floating point operations with reduced precision difficult, even though recent GPUs provide an abundance of or special function operations including Tensor Cores for ma- hardware performance counters, which collect statistics about chine learning. Similarly, information on the use of vectorized certain events. Profiling tools that assist the user in such analysis operations is often lost. Characterizing workloads on PTX for their GPUs, like NVIDIA’s nvprof and cupti, are state-of- level is desirable as PTX allows us to determine the exact types the-art. However, instrumentation based on reading hardware performance counters can be slow, in particular when the number of the instructions a kernel executes. On the contrary, nvprof of metrics is large. Furthermore, the results can be inaccurate as metrics are based on a lower-level representation called SASS. instructions are grouped to match the available set of hardware Still, even if there was an exact mapping, some information on counters.
    [Show full text]
  • A Brief History of Just-In-Time Compilation
    A Brief History of Just-In-Time JOHN AYCOCK University of Calgary Software systems have been using “just-in-time” compilation (JIT) techniques since the 1960s. Broadly, JIT compilation includes any translation performed dynamically, after a program has started execution. We examine the motivation behind JIT compilation and constraints imposed on JIT compilation systems, and present a classification scheme for such systems. This classification emerges as we survey forty years of JIT work, from 1960–2000. Categories and Subject Descriptors: D.3.4 [Programming Languages]: Processors; K.2 [History of Computing]: Software General Terms: Languages, Performance Additional Key Words and Phrases: Just-in-time compilation, dynamic compilation 1. INTRODUCTION into a form that is executable on a target platform. Those who cannot remember the past are con- What is translated? The scope and na- demned to repeat it. ture of programming languages that re- George Santayana, 1863–1952 [Bartlett 1992] quire translation into executable form covers a wide spectrum. Traditional pro- This oft-quoted line is all too applicable gramming languages like Ada, C, and in computer science. Ideas are generated, Java are included, as well as little lan- explored, set aside—only to be reinvented guages [Bentley 1988] such as regular years later. Such is the case with what expressions. is now called “just-in-time” (JIT) or dy- Traditionally, there are two approaches namic compilation, which refers to trans- to translation: compilation and interpreta- lation that occurs after a program begins tion. Compilation translates one language execution. into another—C to assembly language, for Strictly speaking, JIT compilation sys- example—with the implication that the tems (“JIT systems” for short) are com- translated form will be more amenable pletely unnecessary.
    [Show full text]
  • Implementing Continuation Based Language in LLVM and Clang
    Implementing Continuation based language in LLVM and Clang Kaito TOKUMORI Shinji KONO University of the Ryukyus University of the Ryukyus Email: [email protected] Email: [email protected] Abstract—The programming paradigm which use data seg- 1 __code f(Allocate allocate){ 2 allocate.size = 0; ments and code segments are proposed. This paradigm uses 3 goto g(allocate); Continuation based C (CbC), which a slight modified C language. 4 } 5 Code segments are units of calculation and Data segments are 6 // data segment definition sets of typed data. We use these segments as units of computation 7 // (generated automatically) 8 union Data { and meta computation. In this paper we show the implementation 9 struct Allocate { of CbC on LLVM and Clang 3.7. 10 long size; 11 } allocate; 12 }; I. A PRACTICAL CONTINUATION BASED LANGUAGE TABLE I The proposed units of programming are named code seg- CBCEXAMPLE ments and data segments. Code segments are units of calcu- lation which have no state. Data segments are sets of typed data. Code segments are connected to data segments by a meta data segment called a context. After the execution of a code have input data segments and output data segments. Data segment and its context, the next code segment (continuation) segments have two kind of dependency with code segments. is executed. First, Code segments access the contents of data segments Continuation based C (CbC) [1], hereafter referred to as using field names. So data segments should have the named CbC, is a slight modified C which supports code segments.
    [Show full text]
  • Language Translators
    Student Notes Theory LANGUAGE TRANSLATORS A. HIGH AND LOW LEVEL LANGUAGES Programming languages Low – Level Languages High-Level Languages Example: Assembly Language Example: Pascal, Basic, Java Characteristics of LOW Level Languages: They are machine oriented : an assembly language program written for one machine will not work on any other type of machine unless they happen to use the same processor chip. Each assembly language statement generally translates into one machine code instruction, therefore the program becomes long and time-consuming to create. Example: 10100101 01110001 LDA &71 01101001 00000001 ADD #&01 10000101 01110001 STA &71 Characteristics of HIGH Level Languages: They are not machine oriented: in theory they are portable , meaning that a program written for one machine will run on any other machine for which the appropriate compiler or interpreter is available. They are problem oriented: most high level languages have structures and facilities appropriate to a particular use or type of problem. For example, FORTRAN was developed for use in solving mathematical problems. Some languages, such as PASCAL were developed as general-purpose languages. Statements in high-level languages usually resemble English sentences or mathematical expressions and these languages tend to be easier to learn and understand than assembly language. Each statement in a high level language will be translated into several machine code instructions. Example: number:= number + 1; 10100101 01110001 01101001 00000001 10000101 01110001 B. GENERATIONS OF PROGRAMMING LANGUAGES 4th generation 4GLs 3rd generation High Level Languages 2nd generation Low-level Languages 1st generation Machine Code Page 1 of 5 K Aquilina Student Notes Theory 1. MACHINE LANGUAGE – 1ST GENERATION In the early days of computer programming all programs had to be written in machine code.
    [Show full text]