DOCSLIB.ORG

CS 52 / LECTURENOTES on a COURSE in SYSTEMS PROGRAMMING . BY. . AIANC. SHAW DECEMBER 9, 1966 COMPUTER SCIENCE DEPARTMENT School

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

CS 52 / , / . LECTURENOTES ON A COURSE iN SYSTEMS PROGRAMMING . BY. AIANC. SHAW $F) pq WEET n+KLUWD --. K~~NICALREPORT NO. 52 DECEMBER 9, 1966 These notes are based on the lecturei of Professor Niklaus Wirth which were given during the winter and spring of 1965/66 as CS 236a and part of CS 236b, Computer Science Department, Stanford University. COMPUTER SCIENCE DEPARTMENT School of Humanities and Sciences STANFORD UNIVERSITY . ,’ January 15, 1967 ERRATA in . ALAN c. SHAW, LECTURE NOTES.CN A COURSE IN SYSTEMS PROGRAMMING * . CS TR No. 52, Dec. 9, 1966 P* 17, line 5, read "Si+l'! for "Si+k" . P* 34, line 4, read "operand[O:m];" for "operands[O:m];" . P* 35, line 3, read "real or" for "real of" . P* 39, line -7, read "KDF-9" for "KDK-9" . P* 50, line -8, read "careful" for "cardful" . P* 5% add an arrow from "Data Channel" to "Memory" in the diagram. P* 74, last box on page, read "TSXf, 4" for "TSX 4,r" in all cases. P* 75, diagram, read "SQRT" for "S$RT" . P* 86, line 10, append "~2 := s2 + a[j] X b[jl;" , line -10, read "C[l:&l:n];" for "C[l:.!,l:m];" . F* 91, last paragraph, replace by 11 "Dijkstra has developed a solution to the more general problem where there are n processes, instead of only 2, operating in parallel. See K.nuth13 for a discussion and extension of Dijkstra's solution.". p. 100, left, insert between lines -6 and -7, "TRA EQ" . left, line -2, read "1" for "7" . p. 105, Example, read " A X" for ",AX " l i.2 LDQ kf P* 117, second diagram, read " mx!-] f " for 'i-q--q-qq " . p. 119, line -7, read "u,v (possibly empty)" for "u,w (possibly emtpy)". p. 120, line 1, append to-first sentence 1 "where the elements of 6' - are of the form: U' x(x f u, u&, xdf*) l 0 , .: / CS 52 ERRATA, Alan C!. Shaw p. 131, lines 1 and 2, interchange "it&rative" and "recursive". p. replace-program by 136, . (( So := PO; i := O;k := 1; while Pk /= ‘I' & begin i := j := i+l; Si := Pk; k := k+l; while Si .> Pk do' begin while Sj,-l k Sj do j := j-l; S l - Leftpart(S . S,); i := j j l .- j end end --_ p. 137, replace (b) by I b A ‘ A A 9 9 9 I I 4 <head> <head> -II <head> <head> 1 1 <head> <strin@ 1 <head> 1 <strin@ 1' . line -2, read "of KstringX ." for "of Xstring> ." p. 140, line -3, insert "The word "simple" is henceforth omitted.". p. 147, lines 5 through 9, replace by "directly reducible substrings (a)1 S..e..Sk and (b) Sj....S1 . It follows from the definition of precedence relations that S. Q S J-l j and Sk 4 Sk+l . Nowif i<j, then also k < j, since i<j<k l s If i=j and k<_L, then k=l, since implies S j-l= j' jLk<l implies Sk A sk+l ." . p. 151, line -13, read "conditional" for "condition" . p. 154, line -7, read "<digit>" for "<digit" e ' p. 179, insert between lines -4 and -5 "procedure Q(n); integer r-q" 2 - I Lecture Notes on a Course in SYSTEMS PROGRAMMING -. Decerriber 9, 1966 These notes are based on the lectures of Professor Niklaus Wirth which were given during the winter and spring of 1965/66 as CS 236a and part of CS 236b, Com- puter Science Department, Stanford University. Alan C. Shaw i SYSTEMS PROGRAMMING Page I* Introduction . e o 0 . e o e . 0 1 I-l* Advanced Programming . e . ., . o 0 0 e . 1 I-2. Purpose and Prerequisites of the course D e ., o e . 2 1730 Translators . D + a e . o . D o 0 2 I-4. References . o o . D . , 0 * , . e o . 0 . 4 II. Assemblers--. D e Q o o . ., ., . o Q . 0 . e D D ., 0 o 5 II-l. Basic Concepts . o . a ,, . e ., . o e 0 o 5 11-2. Multi-Pass Systems . a . ., e . o . o 0 ., 0 7 11-3. Organizing and Searching Symbol Tables . D . 0 . e 11 11-3.1 UnorderedTables ..e o e.O o o o O.. 12 II+2 Ordered Tables . 0 . 0 . o a o 12 11-3-3 Sorting . o . o . e . e 0 o . o 14 11-3.3.1 Bubble Sort o a e a a D o o o e ., m 14 11-3.3.2 Ranking By Insertion . o e . Q o D 16 11-3.3.3 Other Common Methods D . 0 ., o 0 o 3-7 II-3.4 Scrambling Methods D . e 0 o . o o o Q o o a 17 11-k. One-Pass Assembly . o e Q q 9 o . D 0 D 0 e D o o . 18 II+ Block Structure in Assemblers e . 0 e 0 ., e . o D o 21 11-6. References a o o 0 o ., d ., o a a . o o . e ., . 0 . 26 11-7. Problems . ., ., ., 0 . e o . o q a ., D o . 26 ii Page III* Interpreters . 30 III-l* Definition and Examples .............. 30 11X-2. Basic Interpreter of Sequential Code ........ 31 111-3. Interpreter for a von Neumann Machine . 33 III-b. Polish String or Stack Organized Machines . 38 111-5. Interpretive Computers ............... 41 111-6. References ..................... 43 111-7. Problems. 43 IV. Input-O'Wut Progr=ing. 48 IV-l. The Input-Output Problem ............. 48 IV-2. Immediate I-O. .................. 49 IV-2*1 No "Busy" Flag. .............. 50 IV-2.2 "~sY~ Flag. 50 IV-3. Indirect I-O . 51 IV-3.1 Channels . , .I. 52 IV-3.2 CPU Interrogates Channel . ,53 IV-3.3 Channei Interrupts CPU . l l . l e l 57 . Iv-4. I-O Processors. , . 66 w-5. .Experimental Comparison of Several Methods of I-O. Organiiation. +. 66 IV-~. I-O and Systems Programming. 68 V. Supervisory Programs (Monitors). , . 69 V-l. Monitor Tasks l '* . l l . 69 v-2. Types of Monitors. l . 71 V-2.1 Batch Processing Monitors . 71 iii Page V-2.2 Real Time Monitors . 71 V-2.3 Time Sharing Monitors . 72 v-3. Storage Allocation Methods . 73 V-3.1 Static Relocation . 74 V-3.2. Dynamic Relocation . , s . l . 76 V-3.2.1 Ferranti ATLAS Method . '78 V-3.2.2 Burroughs B5500 . 80 V-3.2.3 Arden, et al. Scheme . 0 . a 80 V-3.3 Memory Protection . o . e 82 V-3.4 Invariant Procedures o . 0 . e 83 v-4 . --' Loosely Connected Parallel Processes . 85 V-4 .l Programming Conventions for Parallel Processing . 86 V-4.2 The Control Problem for Loosely Connected Processes . l . 87 V-4.3 Solving the Problem . e . o . 88 V-4.4 The Use of Semaphores . o . 92 V-4.4.1 Two Processes Communicating via an Unbounded Buffer . 93 v-4.4.2 Processes Communicating via a Bounded Buffer. 97 v-5. References . e . e . o . 0 . 97 v-6. Problem. -. c . e . e . *. 99 VI. Compilers - An Introduction . Q . 100 VI-l. Tasks of a Compiler . Q . 100 VI-2. Heuristic Techniques for Expression Compilation . 103 iv Page VI-23 Rutishauser (1952) . 103 VI-2.2 FORTRAN Compiler (1954+) ......... l@b VI-23 NELIAC (a dialect-of ALGOL 58) ...... 105 VI-2.4 Samelson and Bauer (1959) ......... 106 VI-2.5 Dijkstra (1960) .............. 106 VI-30 Compilation of Expressions Using a Stack ..... 106 m-4. Phrase Structure Methods . 111 VI-5. References .................... 112 VI-~. Problems. .................... 112 --_ VII. Phrase Structure Programming Languages . 114 VII-l. Introduction . 114 VII-20 Representation of Syntax ............. 115 VII+ Notation and Definitions ............. 119 VII-b. Chomsky's Classification of Languages ....... 122 VII-5. The Parsing Problem ................ 122 VII-~. Irons' Classification of Languages According to . Parsing Difficulty . l l . l . + l l . 126 VII-7. Parsing Methods . .' . 128 VII-?*1 A "Top Down" Method . 128 VII-7.2 Eickel, Paul, Bauer, and Samelson . 131 ~11-8. Precedence Phrase Structure Systems . 133 ~11-8.1 Precedence Relations and the Parsing Algorithm . 133 ~11-8.2 Finding the Precedence Relations . 138 ~11-8.3 Use of Precedence Functions ....... 141 VII-8.4 Ambiguities ............... 145 Page ~11-9. Association of Semantics with Syntax. 147 VII-9.1 Mechanism for Expressing Semantics. 147 VII+2 Handling of Declarations . 150 VII 9.3 Conditional Statements and Expressions. 151 VII-9.4 GO TO and Labelled Statements . 153 VII+5 Constants . o 154 VII-lo. References . 155 VII-11. Problems . 156 VIII- Algal Compilation ..................... 166 VIII-l.--' Problems of Analysisand Synthesis ........ 166 VIII-29 Run Time,Storage Administration. ......... 167 VIII+ Treatment of Procedures ............. 170 VIII-k. Arrays ...................... 176 VIII-50 References .................... 178 ~111-6. Problems. .................... 178 vi --. I. INTRODUCTION I-l. Advanced Programming194 1 In attempting to define "Advanced. Programming", E. W. Dijkstra described the purpose of the subject to be "Advancing Programming"; he stressed "those efforts and considerations which try to improve 'the state of the art' of programming, maybe to such an extent that at some time in the future we may speak of 'the state of the Science of Program- ming."' Until recently, the design of machines almost always preceded any serious thought about programming them; this had the unfortunate result that programming-. languages and translators had to be severely restricted to fit into the constraints imposed by machine designers. Programming beyond these restrictions succeeded only' "by using the ma- chine in all kinds of curious and tricky ways which were completely unintended and not even foreseen by the designers." Programmers "have concocted thousands and thousands of ingenious tricks but they have made this chaotic contribution without a mechanism to appreciate or evaluate these tricks, or to sort them out." a Dijkstra's remarks were made in 1962.
Recommended publications
  • Computer Managed Instruction in Navy Training. INSTITUTION Naval Training Equipment Center, Orlando, Fla

    Computer Managed Instruction in Navy Training. INSTITUTION Naval Training Equipment Center, Orlando, Fla

    DOCUMENT RESUME ED 089 780 IR 000 505 AUTHOR Middleton, Morris G.; And Others TITLE Computer Managed Instruction in Navy Training. INSTITUTION Naval Training Equipment Center, Orlando, Fla. Training Analysis and Evaluation Group. REPORT NO NAVTRADQUIPCEN-TAEG-14 PUB DATE Mar 74 NOTE 107p. ERRS PRICE MF-$0.75 HC-$5.40 PLUS POSTAGE DESCRIPTORS *Computer Assisted Instruction; Computers; Cost Effectiveness; Costs; *Educational Programs; *Feasibility Studies; Individualized Instruction; *Management; *Military Training; Pacing; Programing Languages; State of the Art Reviews IDENTIFIERS CMI; *Computer Managed Instruction; Minicomputers; Shipboard Computers; United States Navy ABSTRACT An investigation was made of the feasibility of computer-managed instruction (CMI) for the Navy. Possibilities were examined regarding a centralized computer system for all Navy training, minicomputers for remote classes, and shipboard computers for on-board training. The general state of the art and feasibility of CMI were reviewed, alternative computer languages and terminals studied, and criteria developed for selecting courses for CMI. Literature reviews, site visits, and a questionnaire survey were conducted. Results indicated that despite its high costs, CMI was necessary if a significant number of the more than 4000 Navy training courses were to become individualized and self-paced. It was concluded that the cost of implementing a large-scale centralized computer system for all training courses was prohibitive, but that the use of minicomputers for particular courses and for small, remote classes was feasible. It was also concluded that the use of shipboard computers for training was both desirable and technically feasible, but that this would require the acquisition of additional minicomputers for educational purposes since the existing shipboard equipment was both expensive to convert and already heavily used for other purposes.
  • Typology of Programming Languages E Early Languages E

    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.
  • PL/I List Processing • PL/I Language Lacked Facili�Es for Trea�Ng Linked Lists HAROLD LAWSON,JR

    PL/I List Processing • PL/I Language Lacked FaciliEs for TreaNg Linked Lists HAROLD LAWSON,JR

    The Birth of the Pointer Variable Based upon: Experiences and Reflec;ons of a Computer Pioneer Harold “Bud” Lawson FELLOW FELLOW and LIFE MEMBER IEEE COMPUTER SOCIETY CHARLES BABBAGE COMPUTER PIONEER FELLOW Overlapping Phases • Phase 1 (1959-1974) – Computer Industry • Phase 2 (1974-1996) - Computer-Based Systems • Phase 3 (1996-Present) – Complex Systems • Dedicated to all the talented colleagues that I have worked with during my career. • We have had fun and learned from each other. • InteresMng ReflecMons and Happenings are indicated in Red. Computer Industry (1959 to 1974) • Summer 1958 - US Census Bureau • 1959 Temple University (Introduc;on to IBM 650 (Drum Machine)) • 1959-61 Employed at Remington-Rand Univac • 1961-67 Employed at IBM • 1967-69 Part Time Consultant (Professor) • 1969-70 Employed at Standard Computer Corporaon • 1971-73 Consultant to Datasaab, Linköping • 1973-… Consultant .. Expert Witness.. Rear Admiral Dr. Grace Murray Hopper (December 9, 1906 – January 1, 1992) Minted the word “BUG” – During her Mme as Programmer of the MARK I Computer at Harvard Minted the word “COMPILER” with A-0 in 1951 Developed Math-MaMc and FlowmaMc and inspired the Development of COBOL Grace loved US Navy Service – The oldest acMve officer, reMrement at 80. From Grace I learned that it is important to queson the status-quo, to seek deeper meaning and explore alterna5ve ways of doing things. 1980 – Honarary Doctor The USS Linköpings Universitet Hopper Univac Compiler Technology of the 1950’s Grace Hopper’s Early Programming Languages Math-MaMc
  • 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)

    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.
  • Systems Programming in C++ Practical Course

    Systems Programming in C++ Practical Course

    Systems Programming in C++ Practical Course Summer Term 2019 Course Goals Learn to write good C++ • Basic syntax • Common idioms and best practices Learn to implement large systems with C++ • C++ standard library and Linux ecosystem • Tools and techniques (building, debugging, etc.) Learn to write high-performance code with C++ • Multithreading and synchronization • Performance pitfalls 1 Formal Prerequisites Knowledge equivalent to the lectures • Introduction to Informatics 1 (IN0001) • Fundamentals of Programming (IN0002) • Fundamentals of Algorithms and Data Structures (IN0007) Additional formal prerequisites (B.Sc. Informatics) • Introduction to Computer Architecture (IN0004) • Basic Principles: Operating Systems and System Software (IN0009) Additional formal prerequisites (B.Sc. Games Engineering) • Operating Systems and Hardware oriented Programming for Games (IN0034) 2 Practical Prerequisites Practical prerequisites • No previous experience with C or C++ required • Familiarity with another general-purpose programming language Operating System • Working Linux operating system (e.g. Ubuntu) • Basic experience with Linux (in particular with shell) • You are free to use your favorite OS, we only support Linux 3 Lecture & Tutorial • Lecture: Tuesday, 14:00 – 16:00, MI 02.11.018 • Tutorial: Friday, 10:00 – 12:00, MI 02.11.018 • Discuss assignments and any questions • First two tutorials are additional lectures • Everything will be in English • Attendance is mandatory • Announcements on the website 4 Assignments • Brief non-coding quizzes
  • Simula Mother Tongue for a Generation of Nordic Programmers

    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!
  • Internet Engineering Jan Nikodem, Ph.D. Software Engineering

    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.
  • Language-Parametric Methods for Developing

    Language-Parametric Methods for Developing

    Gabriël Ditmar Primo Konat was born in The Language-Parametric Methods for Developing Interactive Programming Systems Language-Parametric Methods for Developing Interactive Programming Hague, the Netherlands. In 2009, he received his BSc in Computer Science from the Institute of Ap- Invitation plied Sciences in Rijswijk. In 2012, he received his MSc in Computer Science from Delft University of Technology (TUDelft). From 2012 to 2018, he was Language-Parametric a Ph.D. student with the Programming Languages Methods for Developing group at TUDelft, under supervision of Eelco Viss- Interactive Programming er and Sebastian Erdweg. His work focuses on lan- Systems guage workbenches and incremental build systems. Gabriël Konat [email protected] You are cordially invited to the public defense of my dissertation on Monday, November 18th, 2019 at 3pm. At 2:30pm, I will give a brief presentation summarizing my dissertation. The defense will take place in the Senaatszaal of the Delft University of Technology Auditorium, Mekelweg 5, 2628 CC Delft, the Netherlands Afterwards, there will be a Gabriël Konat Language-Parametric Methods for reception. Developing Interactive Programming Systems Gabriël Konat Propositions accompanying the dissertation Language-Parametric Methods for Developing Interactive Programming Systems by Gabriël Ditmar Primo Konat 1. Language-parametric methods for developing interactive programming sys- tems are feasible and useful. (This dissertation) 2. Compilers of general-purpose languages must be bootstrapped with fixpoint bootstrapping. (This dissertation) 3. Manually implementing an incremental system must be avoided. (This dissertation) 4. Like chemists need lab assistants, computer scientists need software engineers to support them in research, teaching, and application in industry. 5.
  • Oral History Interview with John Brackett and Doug Ross

    Oral History Interview with John Brackett and Doug Ross

    An Interview with JOHN BRACKETT AND DOUG ROSS OH 392 Conducted by Mike Mahoney on 7 May 2004 Needham, Massachusetts Charles Babbage Institute Center for the History of Information Processing University of Minnesota, Minneapolis Copyright, Charles Babbage Institute John Brackett and Doug Ross Interview 7 May 2004 Oral History 392 Abstract Doug Ross and John Brackett focus on the background of SofTech and then its entry into the microcomputer software marketplace. They describe their original contact with the University of California at San Diego (UCSD) and licensing the p-System which had been developed there. They discuss the effort required to bring the program to production status and the difficulties in marketing it to the sets of customers. They talk about the transition from 8 bit to 16 bit machines and how that affected their market opportunities. They conclude with a review of the negotiations with IBM and their failure to get p-System to become a primary operating environment. That, and the high performance of Lotus 1-2-3, brought about the demise of the p- System. [John Brackett requested that the following information from Wikipedia, the free encyclopedia, be provided as an introduction to this oral history interview: “UCSD p-System or UCSD Pascal System was a portable, highly machine independent operating system based upon UCSD Pascal. The University of California, San Diego Institute for Information Systems developed it in 1978 to provide students with a common operating system that could run on any of the then available microcomputers as well as campus DEC PDP-11 minicomputers. UCSD p- System was one of three operating systems (along with PC-DOS and CP/M-86) that IBM offered for its original IBM PC.
  • Type Extensions, Wirth 1988

    Type Extensions, Wirth 1988

    Type Extensions N. WIRTH lnstitut fijr Informatik, ETH, Zurich Software systems represent a hierarchy of modules. Client modules contain sets of procedures that extend the capabilities of imported modules. This concept of extension is here applied to data types. Extended types are related to their ancestor in terms of a hierarchy. Variables of an extended type are compatible with variables of the ancestor type. This scheme is expressed by three language constructs only: the declaration of extended record types, the type test, and the type guard. The facility of extended types, which closely resembles the class concept, is defined in rigorous and concise terms, and an efficient implementation is presented. Categories and Subject Descriptors: D.3.3 [Programming Languages]: Language Constructs-data types and structures; modules, packuges; D.3.4 [Programming Languages]: Processors-code generation General Terms: Languages Additional Key Words and Phrases: Extensible data type, Modula-2 1. INTRODUCTION Modern software development tools are designed for the construction of exten- sible systems. Extensibility is the cornerstone for system development, for it allows us to build new systems on the basis of existing ones and to avoid starting each new endeavor from scratch. In fact, programming is extending a given system. The traditional facility that mirrors this concept is the module-also called package-which is a collection of data definitions and procedures that can be linked to other modules by an appropriate linker or loader. Modern large systems consist, without exception, of entire hierarchies of such modules. This notion has been adopted successfully by modern programming languages, such as Mesa [4], Modula-2 [8], and Ada [5], with the crucial property that consistency of interfaces be verified upon compilation of the source text instead of by the linking process.
  • Kednos PL/I for Openvms Systems User Manual

    Kednos PL/I for Openvms Systems User Manual

    ) Kednos PL/I for OpenVMS Systems User Manual Order Number: AA-H951E-TM November 2003 This manual provides an overview of the PL/I programming language. It explains programming with Kednos PL/I on OpenVMS VAX Systems and OpenVMS Alpha Systems. It also describes the operation of the Kednos PL/I compilers and the features of the operating systems that are important to the PL/I programmer. Revision/Update Information: This revised manual supersedes the PL/I User’s Manual for VAX VMS, Order Number AA-H951D-TL. Operating System and Version: For Kednos PL/I for OpenVMS VAX: OpenVMS VAX Version 5.5 or higher For Kednos PL/I for OpenVMS Alpha: OpenVMS Alpha Version 6.2 or higher Software Version: Kednos PL/I Version 3.8 for OpenVMS VAX Kednos PL/I Version 4.4 for OpenVMS Alpha Published by: Kednos Corporation, Pebble Beach, CA, www.Kednos.com First Printing, August 1980 Revised, November 1983 Updated, April 1985 Revised, April 1987 Revised, January 1992 Revised, May 1992 Revised, November 1993 Revised, April 1995 Revised, October 1995 Revised, November 2003 Kednos Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Kednos Corporation or an anthorized sublicensor.
  • Reception of Pascal in the History of Sciences

    Reception of Pascal in the History of Sciences

    Reception of Pascal in the history of sciences... Camille Akmut April 27, 2020 Abstract In particular computer science and technologies. With references to the history of philosophy and the social sciences. 1 I - Crown jewel computers, and sciences The computer scientist Niklaus Wirth, creator of the Pascal programming language, has said of the origins of his creation : I named it after the French philosopher and mathematician, who in 1642 designed one of the first gadgets that might truly be called a digital calculator.1 This is how Wirth remembered Pascal, and explained his choice of the philosopher for his namesake language in 1993 as part of a large conference organized by the ACM on the history of programming languages (the second HOPL); as a pioneer in a line from which { it is either implied, or we interpret too strongly { he ultimately descended. Another notable computer scientist, Friedrich Bauer, known for the stack ADT and his participation in the making of ALGOL 602 among others, in his 'Historical notes on computer science' (one of his last books, if not the last) expressed the following judgment on Pascal and Schickard : \We would not do Schickard any justice by exaggerating : his cal- culating machine was no 4-type ["Vier-Species"] machine, like that of Leibniz, but only a 2-type like Pascal's, but with the difference of having come twenty years earlier. Kepler was said to have been most happy with it. And, perhaps its mechanism was superior. But, that would be a detail."3 [trans.] Ergo : the real machine was Leibniz's { as it could (really) do all four operations of arithmetic { and as for the earlier, partial or lesser, ones Schickard's 1Found in History of programming languages, vol.