DOCSLIB.ORG

A Multi-Paradigm C++-Based Hardware Description Language

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Multi-Paradigm C++-Based Hardware Description Language A MULTI-PARADIGM C++-BASED HARDWARE DESCRIPTION LANGUAGE A Thesis Presented to The Academic Faculty by Chad D. Kersey In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy in the School of Electrical and Computer Engineering Georgia Institute of Technology December 2019 Copyright c 2020 by Chad D. Kersey A MULTI-PARADIGM C++-BASED HARDWARE DESCRIPTION LANGUAGE Approved by: Saibal Mukhopadhyay, Committee Chair Tushar Krishna School of Electrical and Computer School Electrical and Computer Engineering Engineering Georgia Institute of Technology Georgia Institute of Technology Sudhakar Yalamanchili, Advisor Hyesoon Kim School of Electrical and Computer School of Electrical and Computer Engineering Engineering Georgia Institute of Technology Georgia Institute of Technology Thomas Conte Richard Vuduc College of Computing School of Computational Science and Georgia Institute of Technology Engineering Georgia Institute of Technology Date Approved: 09/30/2019 For Sudha, without whom none of this would have happened. iii ACKNOWLEDGEMENTS The work that eventually became this dissertation started at the end of 2012, though the influences leading to its creation reach back much further, and the number of people whose input shaped it is staggering. It is difficult to work on something for so many years without owing quite a bit of gratitude. I am sure I will not be able to name every contribution here, but I will attempt to name the names who still come most prominently to mind. Much of the work that would become this dissertation was done in collaboration with the Structural Simulation Toolkit team at Sandia National Laboratories' Computer Science Research Institute and/or funded by the US Department of Energy. Arun Rodriguez es- pecially has been instrumental in his role as a mentor through five separate internships at Sandia, beginning when C++ 11 was still the upcoming C++ 0x standard and ending after C++ 14 had been published. CHDL would have likely been built using another language if it had not been for my work with SST. My many lab mates in Georgia Tech's Computer Architecture and Systems Lab were helpful and supportive, both in matters technical and mundane. Nawaf Almoosa, Eric Anger, Xinwei Chen, Dhruv Choudhary, Greg Diamos, Naila Farooqui, Minhaj Hassan, Andrew Kerr, Si Li, Adam McLaughlin, Karthik Rao, Ifrah Saeed, William Song, Blaise Tine, Jin Wang, Haicheng Wu, and Hugh Xiao all contributed to making my time at Georgia Tech enjoyable and memorable and participated in technical discussions that strengthened the work presented here. Meghana Gupta in particular contributed important work to the HARP architecture used in Harmonica, including contributing a compiler back-end. Jeff Young has been instrumental in the final stages of writing and preparing this document, and his feedback has been a steady pressure forcing text into what would otherwise be voids. My advisor throughout nearly all of this work and for years before it was the late Sudhakar Yalamanchili, whose patient guidance pushed me along this program of research. I would be hard pressed to name a single person who has had more influence on my work iv or who has shaped my career more. Finally, I must acknowledge all of the people who contributed much needed community and camaraderie, including Brian Akers, Josh Cowan, Ryan and Emily Curtin, and John Frey. My wife Ashley and our little trembly mutt Sarah, both of whom will surely be quite happy to spend an evening with me in which I am not staring at a laptop screen, have been a dependable, stabilizing force in my life and a great source of emotional support throughout a long program of study, and for that I cannot thank them enough. v TABLE OF CONTENTS DEDICATION ...................................... iii ACKNOWLEDGEMENTS .............................. iv LIST OF TABLES ................................... x LIST OF FIGURES .................................. xi SUMMARY ........................................ xiii I INTRODUCTION ................................. 1 1.1 Summary of Contributions . .6 II RELATED WORK ................................ 9 2.1 Fixed-Paradigm Hardware Description Systems . 11 2.1.1 Traditional Hardware Description Languages . 11 2.1.2 Data Flow Systems . 12 2.1.3 High-level Synthesis . 14 2.2 Extensible Hardware Description Systems . 17 2.2.1 Simulation and Verification Oriented Systems . 17 2.2.2 Generative Hardware Description Languages . 18 2.3 Extensible Generative Systems . 19 2.3.1 Extending Generative HDLs . 21 2.4 Motivation for Present Work . 21 III DESIGN OF CHDL ................................ 23 3.1 Introduction . 23 3.2 Synchronous Design . 24 3.3 Structure of CHDL . 26 3.3.1 Template Metaprogramming . 27 3.4 CHDL Core Library . 28 3.4.1 Basic Hardware Manipulation . 28 3.4.2 Optimization . 36 3.4.3 Node Types . 40 3.4.4 Logic Functions Library . 43 vi 3.4.5 Inputs, Outputs, and Simulation Interfaces . 47 3.5 CHDL Template Library . 50 3.5.1 Aggregate Data Types: ag and un .................. 50 3.5.2 Directed Data Types: directed, in, out, inout ......... 51 3.5.3 Loadable Module Support . 51 3.5.4 IP Block Generators . 52 3.5.5 Memory System Interfaces and Components . 53 3.5.6 Numeric Types and Operations . 53 3.5.7 RTL Description in CHDL . 54 3.6 Introspection . 55 3.6.1 Applications of Netlist Introspection . 56 3.7 Conclusions . 65 IV THE HARMONICA DATA PARALLEL CORE .............. 66 4.1 Iqyax RISC Core . 66 4.2 Introduction . 66 4.3 Background and Overview . 68 4.3.1 Hybrid Memory Cube (HMC) . 68 4.3.2 Architectural Constraints . 69 4.4 The HARP Architectures . 70 4.4.1 Execution Model . 71 4.4.2 Parameterization . 71 4.4.3 Instruction Set Features . 72 4.4.4 Kernel Launch Model . 75 4.4.5 Exception Support . 76 4.5 The Harmonica Microarchitecture . 76 4.5.1 Pipeline Detail . 77 4.6 Tool Flow . 79 4.6.1 Software Flow . 80 4.6.2 Hardware Flow . 82 4.7 Performance Analysis . 82 4.7.1 Benchmarks . 83 vii 4.7.2 Results . 84 4.7.3 Impact of Cache . 88 4.8 Context . 89 4.9 Conclusion . 90 V GUARDED ATOMIC ACTIONS IN CHDL ................ 91 5.1 The GAA Paradigm . 93 5.2 An Implementation of GAA in CHDL . 93 5.2.1 gaareg<T>: A Templated GAA Register Type . 94 5.2.2 Rule(): Expressing GAA Rules . 95 5.2.3 C++ Classes as Modules . 95 5.2.4 Scheduler Generator . 96 5.3 Applications Implemented Using CHDL GAA . 98 5.3.1 GCD: Euclidean Algorithm . 99 5.3.2 Other Examples . 101 5.4 Conclusions . 102 VI CHEETAH: A PIPELINED HLS ENVIRONMENT WITHIN CHDL 104 6.1 Pipeline-Oriented Hardware Description Language . 106 6.2 Pipeline Model . 107 6.3 Pipeline Description Language API . 109 6.3.1 Pipeline Stages . 109 6.3.2 Pipeline Control Flow . 110 6.3.3 Pipeline-Carried Values . 110 6.4 An Example: Mandelbrot Set Visualization . 111 6.4.1 Constant Declarations . 112 6.4.2 Pipeline Variable Declarations . 112 6.4.3 Spawn Loop . 113 6.4.4 Room for Retiming . 114 6.4.5 Main Iteration Logic . 114 6.4.6 Serialization of Results . 115 6.5 Applicability to Instruction Set Processors . 116 viii 6.5.1 Example Processor Design . 116 6.5.2 Signals . 117 6.5.3 Instruction Fetch . 118 6.5.4 Register File and Scoreboard . 119 6.5.5 Dispatch and Branch Resolution . 120 6.5.6 Pipelined Functional Units . 122 6.5.7 FIFO Input/Output . 123 6.5.8 Register Writeback . 123 6.5.9 Operation . 124 6.5.10 Applicability to Harmonica and Other SIMT Core Designs . 124 VII CONCLUSIONS .................................. 125 7.1 Thesis Contributions Revisited . 125 7.2 Future Directions . 128 7.3 Concluding Remarks . 129 APPENDIX A | HARP INSTRUCTION SET ............... 130 REFERENCES ..................................... 143 VITA ............................................ 148 ix LIST OF TABLES 1 A list of hardware description systems discussed academically taxonomized by levels of abstraction supported and extensibility. 10 2 Utility functions for instantiating memory. 35 3 Logical operations and overloads. 43 4 Bit vector operations and overloads. 44 5 Memory system components provided by the CHDL template library. 53 6 Numeric types defined in the CHDL template library. 53 7 Selected instructions from the HARP instruction sets. 72 8 Some of the calls in the HARP runtime library. 81 9 The benchmarks used in our evaluation of the Harmonica.
Load more

Recommended publications
  • Co-Simulation Between Cλash and Traditional Hdls
    MASTER THESIS CO-SIMULATION BETWEEN CλASH AND TRADITIONAL HDLS Author: John Verheij Faculty of Electrical Engineering, Mathematics and Computer Science (EEMCS) Computer Architecture for Embedded Systems (CAES) Exam committee: Dr. Ir. C.P.R. Baaij Dr. Ir. J. Kuper Dr. Ir. J.F. Broenink Ir. E. Molenkamp August 19, 2016 Abstract CλaSH is a functional hardware description language (HDL) developed at the CAES group of the University of Twente. CλaSH borrows both the syntax and semantics from the general-purpose functional programming language Haskell, meaning that circuit de- signers can define their circuits with regular Haskell syntax. CλaSH contains a compiler for compiling circuits to traditional hardware description languages, like VHDL, Verilog, and SystemVerilog. Currently, compiling to traditional HDLs is one-way, meaning that CλaSH has no simulation options with the traditional HDLs. Co-simulation could be used to simulate designs which are defined in multiple lan- guages. With co-simulation it should be possible to use CλaSH as a verification language (test-bench) for traditional HDLs. Furthermore, circuits defined in traditional HDLs, can be used and simulated within CλaSH. In this thesis, research is done on the co-simulation of CλaSH and traditional HDLs. Traditional hardware description languages are standardized and include an interface to communicate with foreign languages. This interface can be used to include foreign func- tions, or to make verification and co-simulation possible. Because CλaSH also has possibilities to communicate with foreign languages, through Haskell foreign function interface (FFI), it is possible to set up co-simulation. The Verilog Procedural Interface (VPI), as defined in the IEEE 1364 standard, is used to set-up the communication and to control a Verilog simulator.
    [Show full text]
  • An Open-Source Python-Based Hardware Generation, Simulation
    An Open-Source Python-Based Hardware Generation, Simulation, and Verification Framework Shunning Jiang Christopher Torng Christopher Batten School of Electrical and Computer Engineering, Cornell University, Ithaca, NY { sj634, clt67, cbatten }@cornell.edu pytest coverage.py hypothesis ABSTRACT Host Language HDL We present an overview of previously published features and work (Python) (Verilog) in progress for PyMTL, an open-source Python-based hardware generation, simulation, and verification framework that brings com- FL DUT pelling productivity benefits to hardware design and verification. CL DUT generate Verilog synth RTL DUT PyMTL provides a natural environment for multi-level modeling DUT' using method-based interfaces, features highly parametrized static Sim FPGA/ elaboration and analysis/transform passes, supports fast simulation cosim ASIC and property-based random testing in pure Python environment, Test Bench Sim and includes seamless SystemVerilog integration. Figure 1: PyMTL’s workflow – The designer iteratively refines the hardware within the host Python language, with the help from 1 INTRODUCTION pytest, coverage.py, and hypothesis. The same test bench is later There have been multiple generations of open-source hardware reused for co-simulating the generated Verilog. FL = functional generation frameworks that attempt to mitigate the increasing level; CL = cycle level; RTL = register-transfer level; DUT = design hardware design and verification complexity. These frameworks under test; DUT’ = generated DUT; Sim = simulation. use a high-level general-purpose programming language to ex- press a hardware-oriented declarative or procedural description level (RTL), along with verification and evaluation using Python- and explicitly generate a low-level HDL implementation. Our pre- based simulation and the same TB.
    [Show full text]
  • Download the Compiled Program File Onto the Chip
    International Journal of Computer Science & Information Technology (IJCSIT) Vol 4, No 2, April 2012 MPP SOCGEN: A FRAMEWORK FOR AUTOMATIC GENERATION OF MPP SOC ARCHITECTURE Emna Kallel, Yassine Aoudni, Mouna Baklouti and Mohamed Abid Electrical department, Computer Embedded System Laboratory, ENIS School, Sfax, Tunisia ABSTRACT Automatic code generation is a standard method in software engineering since it improves the code consistency and reduces the overall development time. In this context, this paper presents a design flow for automatic VHDL code generation of mppSoC (massively parallel processing System-on-Chip) configuration. Indeed, depending on the application requirements, a framework of Netbeans Platform Software Tool named MppSoCGEN was developed in order to accelerate the design process of complex mppSoC. Starting from an architecture parameters design, VHDL code will be automatically generated using parsing method. Configuration rules are proposed to have a correct and valid VHDL syntax configuration. Finally, an automatic generation of Processor Elements and network topologies models of mppSoC architecture will be done for Stratix II device family. Our framework improves its flexibility on Netbeans 5.5 version and centrino duo Core 2GHz with 22 Kbytes and 3 seconds average runtime. Experimental results for reduction algorithm validate our MppSoCGEN design flow and demonstrate the efficiency of generated architectures. KEYWORD MppSoC, Automatic code generation; mppSoC configuration;parsing ; MppSoCGEN; 1. INTRODUCTION Parallel machines are most often used in many modern applications that need regular parallel algorithms and high computing resources, such as image processing and signal processing. Massively parallel architectures, in particular Single Instruction Multiple Data (SIMD) systems, have shown to be powerful executers for data-intensive applications [1].
    [Show full text]
  • Edsger W. Dijkstra: a Commemoration
    Edsger W. Dijkstra: a Commemoration Krzysztof R. Apt1 and Tony Hoare2 (editors) 1 CWI, Amsterdam, The Netherlands and MIMUW, University of Warsaw, Poland 2 Department of Computer Science and Technology, University of Cambridge and Microsoft Research Ltd, Cambridge, UK Abstract This article is a multiauthored portrait of Edsger Wybe Dijkstra that consists of testimo- nials written by several friends, colleagues, and students of his. It provides unique insights into his personality, working style and habits, and his influence on other computer scientists, as a researcher, teacher, and mentor. Contents Preface 3 Tony Hoare 4 Donald Knuth 9 Christian Lengauer 11 K. Mani Chandy 13 Eric C.R. Hehner 15 Mark Scheevel 17 Krzysztof R. Apt 18 arXiv:2104.03392v1 [cs.GL] 7 Apr 2021 Niklaus Wirth 20 Lex Bijlsma 23 Manfred Broy 24 David Gries 26 Ted Herman 28 Alain J. Martin 29 J Strother Moore 31 Vladimir Lifschitz 33 Wim H. Hesselink 34 1 Hamilton Richards 36 Ken Calvert 38 David Naumann 40 David Turner 42 J.R. Rao 44 Jayadev Misra 47 Rajeev Joshi 50 Maarten van Emden 52 Two Tuesday Afternoon Clubs 54 2 Preface Edsger Dijkstra was perhaps the best known, and certainly the most discussed, computer scientist of the seventies and eighties. We both knew Dijkstra |though each of us in different ways| and we both were aware that his influence on computer science was not limited to his pioneering software projects and research articles. He interacted with his colleagues by way of numerous discussions, extensive letter correspondence, and hundreds of so-called EWD reports that he used to send to a select group of researchers.
    [Show full text]
  • Glossary of Technical and Scientific Terms (French / English
    Glossary of Technical and Scientific Terms (French / English) Version 11 (Alphabetical sorting) Jean-Luc JOULIN October 12, 2015 Foreword Aim of this handbook This glossary is made to help for translation of technical words english-french. This document is not made to be exhaustive but aim to understand and remember the translation of some words used in various technical domains. Words are sorted alphabetically. This glossary is distributed under the licence Creative Common (BY NC ND) and can be freely redistributed. For further informations about the licence Creative Com- mon (BY NC ND), browse the site: http://creativecommons.org If you are interested by updates of this glossary, send me an email to be on my diffusion list : • [email protected] • [email protected] Warning Translations given in this glossary are for information only and their use is under the responsability of the reader. If you see a mistake in this document, thank in advance to report it to me so i can correct it in further versions of this document. Notes Sorting of words Words are sorted by alphabetical order and are associated to their main category. Difference of terms Some words are different between the "British" and the "American" english. This glossary show the most used terms and are generally coming from the "British" english Words coming from the "American" english are indicated with the suffix : US . Difference of spelling There are some difference of spelling in accordance to the country, companies, universities, ... Words finishing by -ise, -isation and -yse can also be written with -ize, Jean-Luc JOULIN1 Glossary of Technical and Scientific Terms -ization and -yze.
    [Show full text]
  • Intro to Programmable Logic and Fpgas
    CS 296-33: Intro to Programmable Logic and FPGAs ADEL EJJEH UNIVERSITY OF ILLINOIS URBANA-CHAMPAIGN © Adel Ejjeh, UIUC, 2015 2 Digital Logic • In CS 233: • Logic Gates • Build Logic Circuits • Sum of Products ?? F = (A’.B)+(B.C)+(A.C’) A B Black F Box C © Adel Ejjeh, UIUC, 2015 3 Programmable Logic Devices (PLDs) PLD PLA PAL CPLD FPGA (Programmable (Programmable (Complex PLD) (Field Prog. Logic Array) Array Logic) Gate Array) •2-level structure of •Enhanced PLAs •For large designs •Has a much larger # of AND-OR gates with reduced costs •Collection of logic blocks with programmable multiple PLDs with •Larger interconnection connections an interconnection networK structure •Largest manufacturers: Xilinx - Altera Slide taken from Prof. Chehab, American University of Beirut © Adel Ejjeh, UIUC, 2015 4 Combinational Programmable Logic Devices PLAs, CPLDs © Adel Ejjeh, UIUC, 2015 5 Programmable Logic Arrays (PLAs) • 2-level AND-OR device • Programmable connections • Used to generate SOP • Ex: 4x3 PLA Slide adapted from Prof. Chehab, American University of Beirut © Adel Ejjeh, UIUC, 2015 6 PLAs contd • O1 = I1.I2’ + I4.I3’ • O2 = I2.I3.I4’ + I4.I3’ • O3 = I1.I2’ + I2.I1’ Slide adapted from Prof. Chehab, American University of Beirut © Adel Ejjeh, UIUC, 2015 7 Programmable Array Logic (PALs) • More Versatile than PLAs • User Programmable AND array followed by fixed OR gates • Flip-flops/Buffers with feedback transforming output ports into I/O ports © Adel Ejjeh, UIUC, 2015 8 Complex PLDs (CPLD) • Programmable PLD blocks (PALs) I/O Block I/O I/O
    [Show full text]
  • A Pythonic Approach for Rapid Hardware Prototyping and Instrumentation
    A Pythonic Approach for Rapid Hardware Prototyping and Instrumentation John Clow, Georgios Tzimpragos, Deeksha Dangwal, Sammy Guo, Joseph McMahan and Timothy Sherwood University of California, Santa Barbara, CA, 93106 USA Email: fjclow, gtzimpragos, deeksha, sguo, jmcmahan, [email protected] Abstract—We introduce PyRTL, a Python embedded hardware To achieve these goals, PyRTL intentionally restricts users design language that helps concisely and precisely describe to a set of reasonable digital design practices. PyRTL’s small digital hardware structures. Rather than attempt to infer a and well-defined internal core structure makes it easy to add good design via HLS, PyRTL provides a wrapper over a well- defined “core” set of primitives in a way that empowers digital new functionality that works across every design, including hardware design teaching and research. The proposed system logic transforms, static analysis, and optimizations. Features takes advantage of the programming language features of Python such as elaboration-through-execution (e.g. introspection), de- to allow interesting design patterns to be expressed succinctly, and sign and simulation without leaving Python, and the option encourage the rapid generation of tooling and transforms over to export to, or import from, common HDLs (Verilog-in via a custom intermediate representation. We describe PyRTL as a language, its core semantics, the transform generation interface, Yosys [1] and BLIF-in, Verilog-out) are also supported. More and explore its application to several different design patterns and information about PyRTL’s high level flow can be found in analysis tools. Also, we demonstrate the integration of PyRTL- Figure 1. generated hardware overlays into Xilinx PYNQ platform.
    [Show full text]
  • Lecture 10: Fault Tolerance Fault Tolerant Concurrent Computing
    02/12/2014 Lecture 10: Fault Tolerance Fault Tolerant Concurrent Computing • The main principles of fault tolerant programming are: – Fault Detection - Knowing that a fault exists – Fault Recovery - having atomic instructions that can be rolled back in the event of a failure being detected. • System’s viewpoint it is quite possible that the fault is in the program that is attempting the recovery. • Attempting to recover from a non-existent fault can be as disastrous as a fault occurring. CA463 Lecture Notes (Martin Crane 2014) 26 1 02/12/2014 Fault Tolerant Concurrent Computing (cont’d) • Have seen replication used for tasks to allow a program to recover from a fault causing a task to abruptly terminate. • The same principle is also used at the system level to build fault tolerant systems. • Critical systems are replicated, and system action is based on a majority vote of the replicated sub systems. • This redundancy allows the system to successfully continue operating when several sub systems develop faults. CA463 Lecture Notes (Martin Crane 2014) 27 Types of Failures in Concurrent Systems • Initially dead processes ( benign fault ) – A subset of the processes never even start • Crash model ( benign fault ) – Process executes as per its local algorithm until a certain point where it stops indefinitely – Never restarts • Byzantine behaviour (malign fault ) – Algorithm may execute any possible local algorithm – May arbitrarily send/receive messages CA463 Lecture Notes (Martin Crane 2014) 28 2 02/12/2014 A Hierarchy of Failure Types • Dead process – This is a special case of crashed process – Case when the crashed process crashes before it starts executing • Crashed process – This is a special case of Byzantine process – Case when the Byzantine process crashes, and then keeps staying in that state for all future transitions CA463 Lecture Notes (Martin Crane 2014) 29 Types of Fault Tolerance Algorithms • Robust algorithms – Correct processes should continue behaving thus, despite failures.
    [Show full text]
  • White Paper - Investigate the High-Level HDL Chisel
    White Paper - Investigate the high-level HDL Chisel Florian Heilmann, Christian Brugger, Norbert Wehn Microelectronics Research Group, University Kaiserslautern Kaiserslautern, Germany [email protected], [email protected], [email protected] Abstract— Chisel (Constructing Hardware in a Scala designer can simply not use it. Another approach involves embedded language) is a new programming language, which using a language suited for the domain of the target application. embedded in Scala, used for hardware synthesis. It aims to Examples include Esterel [4], which has been modeled for increase productivity when creating hardware by enabling reactive programs and DIL[5], which is an intermediate designers to use features present in higher level programming programming language used to target pipelined reconfigurable languages to build complex hardware blocks. In this paper, the architectures like PipeRench. Moreover, there are languages most advertised features of Chisel are investigated and compared like BlueSpec[6] which is essentially a subset of to their VHDL counterparts, if present. Afterwards, the authors’ SystemVerilog putting emphasis on avoiding race conditions opinion if a switch to Chisel is worth considering is presented. by automatically generating scheduling and arbitration logic Additionally, results from a related case study on Chisel are from a set of “rules” which express synthesizable behavior. briefly summarized. The author concludes that, while Chisel has promising features, it is not yet ready for use in the industry. These languages are usually designed to support a specific design domain. This, however, leads to these approaches performing poorly when used outside the domain they were intended for. Keywords—Hardware design; Chisel; VHDL; HDL III.
    [Show full text]
  • Actor-Based Concurrency by Srinivas Panchapakesan
    Concurrency in Java and Actor- based concurrency using Scala By, Srinivas Panchapakesan Concurrency Concurrent computing is a form of computing in which programs are designed as collections of interacting computational processes that may be executed in parallel. Concurrent programs can be executed sequentially on a single processor by interleaving the execution steps of each computational process, or executed in parallel by assigning each computational process to one of a set of processors that may be close or distributed across a network. The main challenges in designing concurrent programs are ensuring the correct sequencing of the interactions or communications between different computational processes, and coordinating access to resources that are shared among processes. Advantages of Concurrency Almost every computer nowadays has several CPU's or several cores within one CPU. The ability to leverage theses multi-cores can be the key for a successful high-volume application. Increased application throughput - parallel execution of a concurrent program allows the number of tasks completed in certain time period to increase. High responsiveness for input/output-intensive applications mostly wait for input or output operations to complete. Concurrent programming allows the time that would be spent waiting to be used for another task. More appropriate program structure - some problems and problem domains are well-suited to representation as concurrent tasks or processes. Process vs Threads Process: A process runs independently and isolated of other processes. It cannot directly access shared data in other processes. The resources of the process are allocated to it via the operating system, e.g. memory and CPU time. Threads: Threads are so called lightweight processes which have their own call stack but an access shared data.
    [Show full text]
  • C++ Metastring Library and Its Applications⋆
    C++ Metastring Library and its Applications! Zal´anSz˝ugyi, Abel´ Sinkovics, Norbert Pataki, and Zolt´anPorkol´ab Department of Programming Languages and Compilers, E¨otv¨osLor´andUniversity P´azm´any P´eter s´et´any 1/C H-1117 Budapest, Hungary {lupin, abel, patakino, gsd}@elte.hu Abstract. C++ template metaprogramming is an emerging direction of generative programming: with proper template definitions wecanenforce the C++ compiler to execute algorithms at compilation time. Template metaprograms have become essential part of today’s C++ programs of industrial size; they provide code adoptions, various optimizations, DSL embedding, etc. Besides the compilation time algorithms, template metaprogram data-structures are particularly important. From simple typelists to more advanced STL-like data types there are a variety of such constructs. Interesting enough, until recently string, as one of the most widely used data type of programming, has not been supported. Al- though, boost::mpl::string is an advance in this area, it still lacks the most fundamental string operations. In this paper, we analysed the pos- sibilities of handling string objects at compilation time with a metastring library. We created a C++ template metaprogram library that provides the common string operations, like creating sub-strings, concatenation, replace, and similar. To provide real-life use-cases we implemented two applications on top of our Metastring library. One use case utilizes com- pilation time inspection of input in the domain of pattern matching al- gorithms, thus we are able to select the more optimal search method at compilation time. The other use-case implements safePrint, a type-safe version of printf –awidelyinvestigatedproblem.Wepresentboththe performance improvements and extended functionality we haveachieved in the applications of our Metastring library.
    [Show full text]
  • 13 Templates-Generics.Pdf
    CS 242 2012 Generic programming in OO Languages Reading Text: Sections 9.4.1 and 9.4.3 J Koskinen, Metaprogramming in C++, Sections 2 – 5 Gilad Bracha, Generics in the Java Programming Language Questions • If subtyping and inheritance are so great, why do we need type parameterization in object- oriented languages? • The great polymorphism debate – Subtype polymorphism • Apply f(Object x) to any y : C <: Object – Parametric polymorphism • Apply generic <T> f(T x) to any y : C Do these serve similar or different purposes? Outline • C++ Templates – Polymorphism vs Overloading – C++ Template specialization – Example: Standard Template Library (STL) – C++ Template metaprogramming • Java Generics – Subtyping versus generics – Static type checking for generics – Implementation of Java generics Polymorphism vs Overloading • Parametric polymorphism – Single algorithm may be given many types – Type variable may be replaced by any type – f :: tt => f :: IntInt, f :: BoolBool, ... • Overloading – A single symbol may refer to more than one algorithm – Each algorithm may have different type – Choice of algorithm determined by type context – Types of symbol may be arbitrarily different – + has types int*intint, real*realreal, ... Polymorphism: Haskell vs C++ • Haskell polymorphic function – Declarations (generally) require no type information – Type inference uses type variables – Type inference substitutes for variables as needed to instantiate polymorphic code • C++ function template – Programmer declares argument, result types of fctns – Programmers
    [Show full text]