SIMULA Session
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Typology of Programming Languages E Early Languages E
Typology of programming languages e Early Languages E Typology of programming languages Early Languages 1 / 71 The Tower of Babel Typology of programming languages Early Languages 2 / 71 Table of Contents 1 Fortran 2 ALGOL 3 COBOL 4 The second wave 5 The finale Typology of programming languages Early Languages 3 / 71 IBM Mathematical Formula Translator system Fortran I, 1954-1956, IBM 704, a team led by John Backus. Typology of programming languages Early Languages 4 / 71 IBM 704 (1956) Typology of programming languages Early Languages 5 / 71 IBM Mathematical Formula Translator system The main goal is user satisfaction (economical interest) rather than academic. Compiled language. a single data structure : arrays comments arithmetics expressions DO loops subprograms and functions I/O machine independence Typology of programming languages Early Languages 6 / 71 FORTRAN’s success Because: programmers productivity easy to learn by IBM the audience was mainly scientific simplifications (e.g., I/O) Typology of programming languages Early Languages 7 / 71 FORTRAN I C FIND THE MEAN OF N NUMBERS AND THE NUMBER OF C VALUES GREATER THAN IT DIMENSION A(99) REAL MEAN READ(1,5)N 5 FORMAT(I2) READ(1,10)(A(I),I=1,N) 10 FORMAT(6F10.5) SUM=0.0 DO 15 I=1,N 15 SUM=SUM+A(I) MEAN=SUM/FLOAT(N) NUMBER=0 DO 20 I=1,N IF (A(I) .LE. MEAN) GOTO 20 NUMBER=NUMBER+1 20 CONTINUE WRITE (2,25) MEAN,NUMBER 25 FORMAT(11H MEAN = ,F10.5,5X,21H NUMBER SUP = ,I5) STOP TypologyEND of programming languages Early Languages 8 / 71 Fortran on Cards Typology of programming languages Early Languages 9 / 71 Fortrans Typology of programming languages Early Languages 10 / 71 Table of Contents 1 Fortran 2 ALGOL 3 COBOL 4 The second wave 5 The finale Typology of programming languages Early Languages 11 / 71 ALGOL, Demon Star, Beta Persei, 26 Persei Typology of programming languages Early Languages 12 / 71 ALGOL 58 Originally, IAL, International Algebraic Language. -
Intel Technology Journal
Intel® Technology Journal | Volume 14, Issue 1, 2010 Intel Technology Journal Publisher Managing Editor Content Architect Richard Bowles Andrew Binstock Herman D’Hooge Esther Baldwin Program Manager Technical Editor Technical Illustrators Stuart Douglas Marian Lacey InfoPros Technical and Strategic Reviewers Maria Bezaitis Ashley McCorkle Xing Su John Gustafson Milan Milenkovic Rahul Sukthankar Horst Haussecker David O‘Hallaron Allison Woodruff Badarinah Kommandur Trevor Pering Jianping Zhou Anthony LaMarca Matthai Philipose Scott Mainwaring Uttam Sengupta Intel® Technology Journal | 1 Intel® Technology Journal | Volume 14, Issue 1, 2010 Intel Technology Journal Copyright © 2010 Intel Corporation. All rights reserved. ISBN 978-1-934053-28-7, ISSN 1535-864X Intel Technology Journal Volume 14, Issue 1 No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744. Requests to the Publisher for permission should be addressed to the Publisher, Intel Press, Intel Corporation, 2111 NE 25th Avenue, JF3-330, Hillsboro, OR 97124-5961. E mail: [email protected]. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold with the understanding that the publisher is not engaged in professional services. If professional advice or other expert assistance is required, the services of a competent professional person should be sought. -
A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book)
A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book) R. w. BEMER Introduction This is an admittedly fragmentary chronicle of events in the develop ment of the algorithmic language ALGOL. Nevertheless, it seems perti nent, while we await the advent of a technical and conceptual history, to outline the matrix of forces which shaped that history in a political and social sense. Perhaps the author's role is only that of recorder of visible events, rather than the complex interplay of ideas which have made ALGOL the force it is in the computational world. It is true, as Professor Ershov stated in his review of a draft of the present work, that "the reading of this history, rich in curious details, nevertheless does not enable the beginner to understand why ALGOL, with a history that would seem more disappointing than triumphant, changed the face of current programming". I can only state that the time scale and my own lesser competence do not allow the tracing of conceptual development in requisite detail. Books are sure to follow in this area, particularly one by Knuth. A further defect in the present work is the relatively lesser availability of European input to the log, although I could claim better access than many in the U.S.A. This is regrettable in view of the relatively stronger support given to ALGOL in Europe. Perhaps this calmer acceptance had the effect of reducing the number of significant entries for a log such as this. Following a brief view of the pattern of events come the entries of the chronology, or log, numbered for reference in the text. -
Object-Oriented Programming Basics with Java
Object-Oriented Programming Object-Oriented Programming Basics With Java In his keynote address to the 11th World Computer Congress in 1989, renowned computer scientist Donald Knuth said that one of the most important lessons he had learned from his years of experience is that software is hard to write! Computer scientists have struggled for decades to design new languages and techniques for writing software. Unfortunately, experience has shown that writing large systems is virtually impossible. Small programs seem to be no problem, but scaling to large systems with large programming teams can result in $100M projects that never work and are thrown out. The only solution seems to lie in writing small software units that communicate via well-defined interfaces and protocols like computer chips. The units must be small enough that one developer can understand them entirely and, perhaps most importantly, the units must be protected from interference by other units so that programmers can code the units in isolation. The object-oriented paradigm fits these guidelines as designers represent complete concepts or real world entities as objects with approved interfaces for use by other objects. Like the outer membrane of a biological cell, the interface hides the internal implementation of the object, thus, isolating the code from interference by other objects. For many tasks, object-oriented programming has proven to be a very successful paradigm. Interestingly, the first object-oriented language (called Simula, which had even more features than C++) was designed in the 1960's, but object-oriented programming has only come into fashion in the 1990's. -
Security Applications of Formal Language Theory
Dartmouth College Dartmouth Digital Commons Computer Science Technical Reports Computer Science 11-25-2011 Security Applications of Formal Language Theory Len Sassaman Dartmouth College Meredith L. Patterson Dartmouth College Sergey Bratus Dartmouth College Michael E. Locasto Dartmouth College Anna Shubina Dartmouth College Follow this and additional works at: https://digitalcommons.dartmouth.edu/cs_tr Part of the Computer Sciences Commons Dartmouth Digital Commons Citation Sassaman, Len; Patterson, Meredith L.; Bratus, Sergey; Locasto, Michael E.; and Shubina, Anna, "Security Applications of Formal Language Theory" (2011). Computer Science Technical Report TR2011-709. https://digitalcommons.dartmouth.edu/cs_tr/335 This Technical Report is brought to you for free and open access by the Computer Science at Dartmouth Digital Commons. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Dartmouth Digital Commons. For more information, please contact [email protected]. Security Applications of Formal Language Theory Dartmouth Computer Science Technical Report TR2011-709 Len Sassaman, Meredith L. Patterson, Sergey Bratus, Michael E. Locasto, Anna Shubina November 25, 2011 Abstract We present an approach to improving the security of complex, composed systems based on formal language theory, and show how this approach leads to advances in input validation, security modeling, attack surface reduction, and ultimately, software design and programming methodology. We cite examples based on real-world security flaws in common protocols representing different classes of protocol complexity. We also introduce a formalization of an exploit development technique, the parse tree differential attack, made possible by our conception of the role of formal grammars in security. These insights make possible future advances in software auditing techniques applicable to static and dynamic binary analysis, fuzzing, and general reverse-engineering and exploit development. -
Verifiable Semantic Difference Languages
Verifiable Semantic Difference Languages Thibaut Girka David Mentré Yann Régis-Gianas Mitsubishi Electric R&D Centre Mitsubishi Electric R&D Centre Univ Paris Diderot, Sorbonne Paris Europe Europe Cité, IRIF/PPS, UMR 8243 CNRS, PiR2, Rennes, France Rennes, France INRIA Paris-Rocquencourt Paris, France ABSTRACT 1 INTRODUCTION Program differences are usually represented as textual differences Let x be a strictly positive natural number. Consider the following on source code with no regard to its syntax or its semantics. In two (almost identical) imperative programs: this paper, we introduce semantic-aware difference languages. A difference denotes a relation between program reduction traces. A s = 0 ; 1 s = 0 ; 1 difference language for the toy imperative programming language d = x ; 2 d = x − 1 ; 2 while (d>0) { 3 while (d>0) { 3 Imp is given as an illustration. i f (x%d== 0) 4 i f (x%d== 0) 4 To certify software evolutions, we want to mechanically verify s = s + d ; 5 s = s + d ; 5 − − that a difference correctly relates two given programs. Product pro- d = d 1 ; 6 d = d 1 ; 6 } 7 } 7 grams and correlating programs are effective proof techniques for s = s − x 8 8 relational reasoning. A product program simulates, in the same programming language as the compared programs, a well-chosen The program P1 (on the left) stores in s the sum of the proper interleaving of their executions to highlight a specific relation be- divisors of the integer x. To that end, it iterates over the integers tween their reduction traces. While this approach enables the use from x to 1 using the variable d and accumulates in the variable s of readily-available static analysis tools on the product program, it the values of d that divide x. -
Simula Mother Tongue for a Generation of Nordic Programmers
Simula! Mother Tongue! for a Generation of! Nordic Programmers! Yngve Sundblad HCI, CSC, KTH! ! KTH - CSC (School of Computer Science and Communication) Yngve Sundblad – Simula OctoberYngve 2010Sundblad! Inspired by Ole-Johan Dahl, 1931-2002, and Kristen Nygaard, 1926-2002" “From the cold waters of Norway comes Object-Oriented Programming” " (first line in Bertrand Meyer#s widely used text book Object Oriented Software Construction) ! ! KTH - CSC (School of Computer Science and Communication) Yngve Sundblad – Simula OctoberYngve 2010Sundblad! Simula concepts 1967" •# Class of similar Objects (in Simula declaration of CLASS with data and actions)! •# Objects created as Instances of a Class (in Simula NEW object of class)! •# Data attributes of a class (in Simula type declared as parameters or internal)! •# Method attributes are patterns of action (PROCEDURE)! •# Message passing, calls of methods (in Simula dot-notation)! •# Subclasses that inherit from superclasses! •# Polymorphism with several subclasses to a superclass! •# Co-routines (in Simula Detach – Resume)! •# Encapsulation of data supporting abstractions! ! KTH - CSC (School of Computer Science and Communication) Yngve Sundblad – Simula OctoberYngve 2010Sundblad! Simula example BEGIN! REF(taxi) t;" CLASS taxi(n); INTEGER n;! BEGIN ! INTEGER pax;" PROCEDURE book;" IF pax<n THEN pax:=pax+1;! pax:=n;" END of taxi;! t:-NEW taxi(5);" t.book; t.book;" print(t.pax)" END! Output: 7 ! ! KTH - CSC (School of Computer Science and Communication) Yngve Sundblad – Simula OctoberYngve 2010Sundblad! -
Trends in Electrical Efficiency in Computer Performance
ASSESSING TRENDS IN THE ELECTRICAL EFFICIENCY OF COMPUTATION OVER TIME Jonathan G. Koomey*, Stephen Berard†, Marla Sanchez††, Henry Wong** * Lawrence Berkeley National Laboratory and Stanford University †Microsoft Corporation ††Lawrence Berkeley National Laboratory **Intel Corporation Contact: [email protected], http://www.koomey.com Final report to Microsoft Corporation and Intel Corporation Submitted to IEEE Annals of the History of Computing: August 5, 2009 Released on the web: August 17, 2009 EXECUTIVE SUMMARY Information technology (IT) has captured the popular imagination, in part because of the tangible benefits IT brings, but also because the underlying technological trends proceed at easily measurable, remarkably predictable, and unusually rapid rates. The number of transistors on a chip has doubled more or less every two years for decades, a trend that is popularly (but often imprecisely) encapsulated as “Moore’s law”. This article explores the relationship between the performance of computers and the electricity needed to deliver that performance. As shown in Figure ES-1, computations per kWh grew about as fast as performance for desktop computers starting in 1981, doubling every 1.5 years, a pace of change in computational efficiency comparable to that from 1946 to the present. Computations per kWh grew even more rapidly during the vacuum tube computing era and during the transition from tubes to transistors but more slowly during the era of discrete transistors. As expected, the transition from tubes to transistors shows a large jump in computations per kWh. In 1985, the physicist Richard Feynman identified a factor of one hundred billion (1011) possible theoretical improvement in the electricity used per computation. -
Internet Engineering Jan Nikodem, Ph.D. Software Engineering
Internet Engineering Jan Nikodem, Ph.D. Software Engineering Theengineering paradigm Software Engineering Lecture 3 The term "software crisis" was coined at the first NATO Software Engineering Conference in 1968 by: Friedrich. L. Bauer Nationality;German, mathematician, theoretical physicist, Technical University of Munich Friedrich L. Bauer 1924 3/24 The term "software crisis" was coined at the first NATO Software Engineering Conference in 1968 by: Peter Naur Nationality;Dutch, astronomer, Regnecentralen, Niels Bohr Institute, Technical University of Denmark, University of Copenhagen. Peter Naur 1928 4/24 Whatshouldbe ourresponse to software crisis which provided with too little quality, too late deliver and over budget? Nationality;Dutch, astronomer, Regnecentralen, Niels Bohr Institute, Technical University of Denmark, University of Copenhagen. Peter Naur 1928 5/24 Software should following an engineering paradigm NATO conference in Garmisch-Partenkirchen, 1968 Peter Naur 1928 6/24 The hope is that the progress in hardware will cure all software ills. The Oberon System User Guide and Programmer's Manual. ACM Press Nationality;Swiss, electrical engineer, computer scientist ETH Zürich, IBM Zürich Research Laboratory, Institute for Media Communications Martin Reiser 7/24 However, a critical observer may notethat software manages to outgrow hardware in size and sluggishness. The Oberon System User Guide and Programmer's Manual. ACM Press Nationality;Swiss, electrical engineer, computer scientist ETH Zürich, IBM Zürich Research Laboratory, Institute for Media Communications Martin Reiser 8/24 Wirth's computing adage Software is getting slower more rapidly than hardware becomes faster. Nationality;Swiss, electronic engineer, computer scientist ETH Zürich, University of California, Berkeley, Stanford University University of Zurich. Xerox PARC. -
CMPS 161 – Algorithm Design and Implementation I Current Course Description
CMPS 161 – Algorithm Design and Implementation I Current Course Description: Credit 3 hours. Prerequisite: Mathematics 161 or 165 or permission of the Department Head. Basic concepts of computer programming, problem solving, algorithm development, and program coding using a high-level, block structured language. Credit may be given for both Computer Science 110 and 161. Minimum Topics: • Fundamental programming constructs: Syntax and semantics of a higher-level language; variables, types, expressions, and assignment; simple I/O; conditional and iterative control structures; functions and parameter passing; structured decomposition • Algorithms and problem-solving: Problem-solving strategies; the role of algorithms in the problem- solving process; implementation strategies for algorithms; debugging strategies; the concept and properties of algorithms • Fundamental data structures: Primitive types; single-dimension and multiple-dimension arrays; strings and string processing • Machine level representation of data: Bits, bytes and words; numeric data representation; representation of character data • Human-computer interaction: Introduction to design issues • Software development methodology: Fundamental design concepts and principles; structured design; testing and debugging strategies; test-case design; programming environments; testing and debugging tools Learning Objectives: Students will be able to: • Analyze and explain the behavior of simple programs involving the fundamental programming constructs covered by this unit. • Modify and expand short programs that use standard conditional and iterative control structures and functions. • Design, implement, test, and debug a program that uses each of the following fundamental programming constructs: basic computation, simple I/O, standard conditional and iterative structures, and the definition of functions. • Choose appropriate conditional and iteration constructs for a given programming task. • Apply the techniques of structured (functional) decomposition to break a program into smaller pieces. -
Skepu 2: Flexible and Type-Safe Skeleton Programming for Heterogeneous Parallel Systems
Int J Parallel Prog DOI 10.1007/s10766-017-0490-5 SkePU 2: Flexible and Type-Safe Skeleton Programming for Heterogeneous Parallel Systems August Ernstsson1 · Lu Li1 · Christoph Kessler1 Received: 30 September 2016 / Accepted: 10 January 2017 © The Author(s) 2017. This article is published with open access at Springerlink.com Abstract In this article we present SkePU 2, the next generation of the SkePU C++ skeleton programming framework for heterogeneous parallel systems. We critically examine the design and limitations of the SkePU 1 programming interface. We present a new, flexible and type-safe, interface for skeleton programming in SkePU 2, and a source-to-source transformation tool which knows about SkePU 2 constructs such as skeletons and user functions. We demonstrate how the source-to-source compiler transforms programs to enable efficient execution on parallel heterogeneous systems. We show how SkePU 2 enables new use-cases and applications by increasing the flexibility from SkePU 1, and how programming errors can be caught earlier and easier thanks to improved type safety. We propose a new skeleton, Call, unique in the sense that it does not impose any predefined skeleton structure and can encapsulate arbitrary user-defined multi-backend computations. We also discuss how the source- to-source compiler can enable a new optimization opportunity by selecting among multiple user function specializations when building a parallel program. Finally, we show that the performance of our prototype SkePU 2 implementation closely matches that of -
Software Requirements Implementation and Management
Software Requirements Implementation and Management Juho Jäälinoja¹ and Markku Oivo² 1 VTT Technical Research Centre of Finland P.O. Box 1100, 90571 Oulu, Finland [email protected] tel. +358-40-8415550 2 University of Oulu P.O. Box 3000, 90014 University of Oulu, Finland [email protected] tel. +358-8-553 1900 Abstract. Proper elicitation, analysis, and documentation of requirements at the beginning of a software development project are considered important preconditions for successful software development. Furthermore, successful development requires that the requirements be correctly implemented and managed throughout the rest of the development. This latter success criterion is discussed in this paper. The paper presents a taxonomy for requirements implementation and management (RIM) and provides insights into the current state of these practices in the software industry. Based on the taxonomy and the industrial observations, a model for RIM is elaborated. The model describes the essential elements needed for successful implementation and management of requirements. In addition, three critical elements of the model with which the practitioners are currently struggling are discussed. These elements were identified as (1) involvement of software developers in system level requirements allocation, (2) work product verification with reviews, and (3) requirements traceability. Keywords: Requirements engineering, software requirements, requirements implementation, requirements management 1/9 1. INTRODUCTION Among the key concepts of efficient software development are proper elicitation, analysis, and documentation of requirements at the beginning of a project and correct implementation and management of these requirements in the later stages of the project. In this paper, the latter issue related to the life of software requirements beyond their initial development is discussed.