DOCSLIB.ORG

MTS the Michigan Terminal System Volume 3

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

M T S The Michigan Terminal System Volume 3: System Subroutine Descriptions Reference R1003 April 1981 Updated March 1982 (Update 1) Updated February 1983 (Update 2) Updated January 1984 (Update 3) Updated September 1984 (Update 4) Updated April 1985 (Update 5) Updated September 1985 (Update 6) Updated July 1987 (Update 7) Updated September 1989 (Update 8) The University of Michigan Computing Center Ann Arbor, Michigan 1 DISCLAIMER This volume is intended to represent the current state of the Michigan Terminal System (MTS), but because the system is constantly being developed, extended, and refined, sections of this volume will become obsolete. The user should refer to the U-M___ Computing_________ News,____ Computing Center Memos, and future updates to this volume for the latest information about changes to MTS. Copyright 1981 by the Regents of the University of Michigan. Copying is permitted for nonprofit, educational use provided that (1) each repro- duction is done without alteration and (2) the volume reference and date of publication are included. Permission to republish any portions of this manual should be obtained in writing from the Director of the University of Michigan Computing Center. 2 MTS 3: System Subroutine Descriptions April 1981 Page Revised September 1989 PREFACE_______ The software developed by the Computing Center staff for the operation of the high-speed processor computer can be described as a multiprogramming supervisor that handles a number of resident, reentrant programs. Among them is a large subsystem, called MTS (Michigan Terminal System), for command interpretation, execution control, file management, and accounting maintenance. Most users interact with the computer’s resources through MTS. The MTS Manual is a series of volumes that describe in detail the facilities provided by the Michigan Terminal System. Administrative policies of the Computing Center and the physical facilities provided described in other publications. The MTS volumes now in print are listed below. The date indicates the most recent edition of each volume; however, since volumes are periodically updated, users should check the file *CCPUBLICATIONS, or watch for announcements in the U-M___ Computing_________ News,____ to ensure that their MTS volumes are up to date. Volume 1: The____________________________ Michigan Terminal System, November 1988 Volume 2: Public________________________ File Descriptions, January 1987 Volume 3: System______________________________ Subroutine Descriptions, March 1989 Volume 4: Terminals_____________________________ and Networks in MTS, July 1988 Volume 5: System_______________ Services, May 1983 Volume 6: FORTRAN______________ in MTS, October 1983 Volume 7: PL/I___________ in MTS, September 1982 Volume 8: LISP____________________ and SLIP in MTS, June 1976 Volume 9: SNOBOL4______________ in MTS, September 1975 Volume 10: BASIC____________ in MTS, December 1980 Volume 11: Plot_______________________ Description System, August 1978 Volume 12: PIL/2____________ in MTS, December 1974 Volume 13: The_____________________________ Symbolic Debugging System, September 1985 Volume 14: 360/370_________________________ Assemblers in MTS, May 1983 Volume 15: FORMAT__________________ and TEXT360, April 1977 Volume 16: ALGOL______________ W in MTS, September 1980 Volume 17: Integrated__________________________ Graphics System, December 1980 Volume 18: The___________________ MTS File Editor, February 1988 Volume 19: Tapes______________________ and Floppy Disks, March 1989 Volume 20: Pascal_____________ in MTS, January 1989 Volume 21: MTS_________________________________ Command Extensions and Macros, April 1986 Volume 22: Utilisp______________ in MTS, May 1988 Volume 23: Messaging_________________________________ and Conferencing in MTS, August 1988 The numerical order of the volumes does not necessarily reflect the chronological order of their appearance; however, in general, the higher the number, the more specialized the volume. Volume 1, for example, 3 MTS 3: System Subroutine Descriptions Page Revised September 1989 April 1981 introduces the user to MTS and describes in general the MTS operating system, while Volume 10 deals exclusively with BASIC. The attempt to make each volume complete in itself and reasonably independent of others in the series naturally results in a certain amount of repetition. Public file descriptions, for example, may appear in more than one volume. However, this arrangement permits the user to buy only those volumes that serve his or her immediate needs. Richard A. Salisbury, General Editor 4 MTS 3: System Subroutine Descriptions April 1981 PREFACE___________________________ TO REVISED VOLUME 3 The April 1981 edition reflects the changes that have been made to MTS since October 1976. Some of these changes were described in Updates 1-5 and are incorporated into this revision. The section "PL/I Library Subroutines" has been deleted from this edition as those subroutines are currently described in MTS Volume 7, PL/I___________ in MTS. The section "External Symbol Index" has been deleted. This informa- tion is now available through the program *SYMBOLS. The following subroutine descriptions have been added to this edition since Update 5 (April 1980). CHKPAR COMMAND GPRJNO NPAR PKEY RSSAS TRLCUC, TRUCLC TRTLC, TRTUC, TRTNONAN The following subroutines have been deleted from this edition as they are no longer actively supported by the Computing Center. Descriptions of these subroutines may be found in the October 1976 edition of MTS Volume 3, System______________________________ Subroutine Descriptions, which is available in the Computing Center staff library. CVTOMR E7090, D7090, E7090P, D7090P KEYWRD TRACER The following subroutine has been deleted from this edition as it is callable only from internal system programs. SETFPRIV The CASECONV subroutine description is now a part of the TRLCUC, TRUCLC subroutine description. A special edition of this volume has been published for use by systems programmers. This edition contains descriptions of several internal system subroutines which are callable only from system mode or 5 MTS 3: System Subroutine Descriptions April 1981 which contain parameters which are only of use to systems programs. A copy of this edition is available in the Computing Center Staff Library. 6 MTS 3: System Subroutine Descriptions April 1981 Contents________ Preface . 3 LAND . 61 LCOMPL . 61 Preface to Revised Volume 3 . 5 LOR . 61 LXOR . 61 Using Subroutine Libraries . 11 OR . 61 SHFTL . 61 Subroutines Libraries SHFTR . 61 Available in MTS . 13 XOR . 61 Blocked Input/Output Subject Categories of Routines . 63 Subroutines . 19 QGETUCB . 64 Character and Numeric QOPEN . 65 Conversion . 19 QGET . 67 Date and Time Conversion . 19 QPUT . 69 File and Device Usage . 20 QCLOSE . 71 FORTRAN Usage . 21 QFREEUCB . 72 Input/Output Routines . 22 QCNTRL . 73 Interrupt Processing . 22 BLOKLETR . 75 Status of User and System . 22 CALC . 77 System Utilities . 23 CANREPLY . 81 Virtual Memory Management . 23 CATSCAN . 82.1 CFDUB . 83 Calling Conventions . 25 Character Manipulation Routines . 85 Resident System and *LIBRARY BTD . 87 Subroutines . 35 COMC . 88 ADROF . 37 DTB . 89 ANSI Standard Bit EQUC . 91 Manipulation Subroutines . 38.1 FINDC . 92 ANSI Standard File Control FINDST . 94 Subroutines . 38.3 IGC . 95 Array Management Subroutines 39 LCOMC . 97 ARINIT . 41 MOVEC . 98 ARRAY, ARRAY2 . 42 SETC . 99 EXTEND, XTEND2 . 44 TRNC . .100 ERASE . 46 TRNST . .101 ERASAL . 46 CHARGE . .103 ASCEBC, IASCEBC . 47 CHGFSZ . .107 ATNTRP . 53 CHGMBC . .109 ATTNTRP . 55 CHGXF . .111 BINEBCD . 57 CHKACC . .115 BINEBCD2 . 59 CHKFDUB . .117 BMS (Bit Manipulation CHKFILE . .119 Subroutines) . 60.1 CHKPAR . .121 Bitwise Logical Functions . 61 CLOSEFIL . .125 AND . 61 CMD . .127 COMPL . 61 CMDNOE . .129 7 MTS 3: System Subroutine Descriptions April 1981 CNFGINFO . .131 LINK, LINKF . .319 CNTLNR . .137 LIOUNITS . .325 COMMAND . .139 LOAD, LOADF . .327 CONTROL . .143 LOADINFO . .335 COST . .147 LOCK . .339 CREATE . .149 LODMAP . .343 CRYPT . .151 Logical Operators . .345 CSGET, CSSET . .152.1 ICLC . .345 DESTROY . .153 IED . .345 DISMOUNT . .155 IEDMK . .345 DUMP, PDUMP . .157 IMVC . .345 EBCASC, IEBCASC . .159 INC . .345 EDIT . .167 IOC . .345 EMPTY . .179 ITR . .345 EMPTYF . .181 ITRT . .345 ERROR . .183 IXC . .345 FILEINFO . .184.1 LSFILE . .348.1 FNAMETRT . .185 LSTASK . .348.5 FREAD/FWRITE . .187 MOUNT . .349 FREEFD . .189 MTS . .355 FREESPAC . .191 MTSCMD . .357 FSIZE . .193 NOTE . .359 FSRF, BSRF . .195 NPAR . .361 FTNCMD . .197 OSGRDT . .363 GDINF . .199 PAR . .365 GDINFO . .201 PARSTR . .366.1 GDINFO2 . .207 Pattern-Matching Routines . .366.3 GDINFO3 . .209 PATBUILD . .366.4 GETFD . .211 PATMATCH . .366.7 GETFST, GETLST . .213 PATFREE . .366.9 GETIME . .215 PERMIT . .367 GETSPACE . .217 PGNTTRP . .371 GFINFO . .221 PKEY . .373 GPRJNO . .229 POINT . .375 GPSECT, QPSECT, FPSECT . .231 Printer Plot Routines . .377 GRAND, GRAND1 . .233 PLOT1 . .381 GRGJULDT, GRGJULTM, GRJLSEC .235 PLOT2 . .382 GRJLDT, GRJLTM . .237 PLOT3 . .383 GROSDT . .239 PLOT4 . .384 GTDJMS . .241 PLOT14 . .385 GTDJMSR . .243 PRCHAR . .386 GUINFO, CUINFO . .245 PREND . .387 GUINFUPD . .271 PRPLOT . .388 GUSER . .273 STPLT1 . .390 GUSERID . .275 STPLT2 . .391 IBSCH . .276.1 SETLOG . .392 IOH . .277 OMIT . .393 JLGRDT, JLGRTM . .279 QUIT . .395 JMSGTD, JTUGTD . .283 RCALL . .397 JMSGTDR, JTUGTDR . .285 READ . .399 JULGRGDT, JULGRGTM, JLGRSEC .287 READBFR . .403 KWSCAN . .289 RENAME . .405 LETGO . .317 RENUMB . .407 8
Recommended publications
  • Efficient Computation of LALR(1) Look-Ahead Sets

    Efficient Computation of LALR(1) Look-Ahead Sets

    Efficient Computation of LALR(1) Look-Ahead Sets FRANK DeREMER and THOMAS PENNELLO University of California, Santa Cruz, and MetaWare TM Incorporated Two relations that capture the essential structure of the problem of computing LALR(1) look-ahead sets are defined, and an efficient algorithm is presented to compute the sets in time linear in the size of the relations. In particular, for a PASCAL grammar, the algorithm performs fewer than 15 percent of the set unions performed by the popular compiler-compiler YACC. When a grammar is not LALR(1), the relations, represented explicitly, provide for printing user- oriented error messages that specifically indicate how the look-ahead problem arose. In addition, certain loops in the digraphs induced by these relations indicate that the grammar is not LR(k) for any k. Finally, an oft-discovered and used but incorrect look-ahead set algorithm is similarly based on two other relations defined for the fwst time here. The formal presentation of this algorithm should help prevent its rediscovery. Categories and Subject Descriptors: D.3.1 [Programming Languages]: Formal Definitions and Theory--syntax; D.3.4 [Programming Languages]: Processors--translator writing systems and compiler generators; F.4.2 [Mathematical Logic and Formal Languages]: Grammars and Other Rewriting Systems--parsing General Terms: Algorithms, Languages, Theory Additional Key Words and Phrases: Context-free grammar, Backus-Naur form, strongly connected component, LALR(1), LR(k), grammar debugging, 1. INTRODUCTION Since the invention of LALR(1) grammars by DeRemer [9], LALR grammar analysis and parsing techniques have been popular as a component of translator writing systems and compiler-compilers.
  • SAKI: a Fortran Program for Generalized Linear Inversion of Gravity and Magnetic Profiles

    SAKI: a Fortran Program for Generalized Linear Inversion of Gravity and Magnetic Profiles

    UNITED STATES DEPARTMENT OF THE INTERIOR GEOLOGICAL SURVEY SAKI: A Fortran program for generalized linear Inversion of gravity and magnetic profiles by Michael Webring Open File Report 85-122 1985 This report is preliminary and has not been reviewed for conformity with U.S. Geological Survey editorial standards. Table of Contents Abstract ------------------------------ 1 Introduction ---------------------------- 1 Theory ------------------------------- 2 Users Guide ---------------------------- 7 Model File -------------------------- 7 Observed Data Files ---------------------- 9 Command File ------------------------- 10 Data File Parameters ------------------- 10 Magnetic Parameters ------------------- 10 General Parameters -------------------- H Plotting Parameters ------------------- n Annotation Parameters ------------------ 12 Program Interactive Commands ----------------- 13 Inversion Function ---------------------- 16 Examples ------------------------------ 20 References ----------------------------- 26 Appendix A - plot system description ---------------- 27 Appendix B - program listing -------------------- 30 Abstract A gravity and magnetic inversion program is presented which models a structural cross-section as an ensemble of 2-d prisms formed by linking vertices into a network that may be deformed by a modified Marquardt algorithm. The nonuniqueness of this general model is constrained by the user in an interactive mode. Introduction This program fits in a least-squares sense the theoretical gravity and magnetic response of
  • Michigan Terminal System (MTS) Distribution 3.0 Documentation

    Michigan Terminal System (MTS) Distribution 3.0 Documentation

    D3.NOTES 1 M T S D I S T R I B U T I O N 3.0 August 1973 General Notes Distribution 3.0 consists of 6 tapes for the 1600 bpi copy or 9 tapes for the 800 bpi copy. All tapes are unlabeled to save space. The last tape of each set is a dump/restore tape, designed to be used to get started (for new installations) or for conversion (for old installations). Instructions for these procedures are given in items 1001 and 1002 of the documentation list (later in this writeup). The remaining tapes are "Distribution Utility" tapes containing source, object, command, data, and print files, designed to be read by *FS or by the Distribution program, which is a superset of *FS. A writeup for this distribution version of *FS is enclosed (item 1003). Throughout the documentation for this distribution, reference is made to the components of the distribution. Generally these references are made by the 3-digit component number, sometimes followed by a slash and a 1- or 2-digit sub- component number. For example, the G assembler (*ASMG) has been assigned component number 066. However, the assembler actually has many "pieces" and so the assembler consists of components 066/1 through 066/60. Component numbers 001 through 481 are compatible with the numbers used in distribution 2.0; numbers above 481 are new components, or in some cases, old components which have been grouped under a new number. Two versions of the distribution driver file are provided: 461/11 for the 1600 bpi tapes, and 461/16 for the 800 bpi tapes.
  • Pearl: Diagrams for Composing Compilers

    Pearl: Diagrams for Composing Compilers

    Pearl: Diagrams for Composing Compilers John Wickerson Imperial College London, UK [email protected] Paul Brunet University College London, UK [email protected] Abstract T-diagrams (or ‘tombstone diagrams’) are widely used in teaching for explaining how compilers and interpreters can be composed together to build and execute software. In this Pearl, we revisit these diagrams, and show how they can be redesigned for better readability. We demonstrate how they can be applied to explain compiler concepts including bootstrapping and cross-compilation. We provide a formal semantics for our redesigned diagrams, based on binary trees. Finally, we suggest how our diagrams could be used to analyse the performance of a compilation system. 2012 ACM Subject Classification Software and its engineering → Compilers Keywords and phrases compiler networks, graphical languages, pedagogy Digital Object Identifier 10.4230/LIPIcs.ECOOP.2020.1 1 Introduction In introductory courses on compilers across the globe, students are taught about the inter- actions between compilers using ‘tombstone diagrams’ or ‘T-diagrams’. In this formalism, a compiler is represented as a ‘T-piece’. A T-piece, as shown in Fig. 1, is characterised by three labels: the source language of the compiler, the target language of the compiler, and the language in which the compiler is implemented. Complex networks of compilers can be represented by composing these basic pieces in two ways. Horizontal composition means that the output of the first compiler is fed in as the input to the second. Diagonal composition means that the first compiler is itself compiled using the second compiler.
  • MTS on Wikipedia Snapshot Taken 9 January 2011

    MTS on Wikipedia Snapshot Taken 9 January 2011

    MTS on Wikipedia Snapshot taken 9 January 2011 PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sun, 09 Jan 2011 13:08:01 UTC Contents Articles Michigan Terminal System 1 MTS system architecture 17 IBM System/360 Model 67 40 MAD programming language 46 UBC PLUS 55 Micro DBMS 57 Bruce Arden 58 Bernard Galler 59 TSS/360 60 References Article Sources and Contributors 64 Image Sources, Licenses and Contributors 65 Article Licenses License 66 Michigan Terminal System 1 Michigan Terminal System The MTS welcome screen as seen through a 3270 terminal emulator. Company / developer University of Michigan and 7 other universities in the U.S., Canada, and the UK Programmed in various languages, mostly 360/370 Assembler Working state Historic Initial release 1967 Latest stable release 6.0 / 1988 (final) Available language(s) English Available programming Assembler, FORTRAN, PL/I, PLUS, ALGOL W, Pascal, C, LISP, SNOBOL4, COBOL, PL360, languages(s) MAD/I, GOM (Good Old Mad), APL, and many more Supported platforms IBM S/360-67, IBM S/370 and successors History of IBM mainframe operating systems On early mainframe computers: • GM OS & GM-NAA I/O 1955 • BESYS 1957 • UMES 1958 • SOS 1959 • IBSYS 1960 • CTSS 1961 On S/360 and successors: • BOS/360 1965 • TOS/360 1965 • TSS/360 1967 • MTS 1967 • ORVYL 1967 • MUSIC 1972 • MUSIC/SP 1985 • DOS/360 and successors 1966 • DOS/VS 1972 • DOS/VSE 1980s • VSE/SP late 1980s • VSE/ESA 1991 • z/VSE 2005 Michigan Terminal System 2 • OS/360 and successors
  • Die Gruncllehren Cler Mathematischen Wissenschaften

    Die Gruncllehren Cler Mathematischen Wissenschaften

    Die Gruncllehren cler mathematischen Wissenschaften in Einzeldarstellungen mit besonderer Beriicksichtigung der Anwendungsgebiete Band 135 Herausgegeben von J. L. Doob . E. Heinz· F. Hirzebruch . E. Hopf . H. Hopf W. Maak . S. Mac Lane • W. Magnus. D. Mumford M. M. Postnikov . F. K. Schmidt· D. S. Scott· K. Stein Geschiiftsfiihrende Herausgeber B. Eckmann und B. L. van der Waerden Handbook for Automatic Computation Edited by F. L. Bauer· A. S. Householder· F. W. J. Olver H. Rutishauser . K. Samelson· E. Stiefel Volume I . Part a Heinz Rutishauser Description of ALGOL 60 Springer-Verlag New York Inc. 1967 Prof. Dr. H. Rutishauser Eidgenossische Technische Hochschule Zurich Geschaftsfuhrende Herausgeber: Prof. Dr. B. Eckmann Eidgenossische Tecbnische Hocbscbule Zurich Prof. Dr. B. L. van der Waerden Matbematisches Institut der Universitat ZUrich Aile Rechte, insbesondere das der Obersetzung in fremde Spracben, vorbebalten Ohne ausdriickliche Genehmigung des Verlages ist es auch nicht gestattet, dieses Buch oder Teile daraus auf photomechaniscbem Wege (Photokopie, Mikrokopie) oder auf andere Art zu vervielfaltigen ISBN-13: 978-3-642-86936-5 e-ISBN-13: 978-3-642-86934-1 DOl: 10.1007/978-3-642-86934-1 © by Springer-Verlag Berlin· Heidelberg 1967 Softcover reprint of the hardcover 1st edition 1%7 Library of Congress Catalog Card Number 67-13537 Titel-Nr. 5l1B Preface Automatic computing has undergone drastic changes since the pioneering days of the early Fifties, one of the most obvious being that today the majority of computer programs are no longer written in machine code but in some programming language like FORTRAN or ALGOL. However, as desirable as the time-saving achieved in this way may be, still a high proportion of the preparatory work must be attributed to activities such as error estimates, stability investigations and the like, and for these no programming aid whatsoever can be of help.
  • A Study on Various Programming Languages to Keep Pace with Innovation

    A Study on Various Programming Languages to Keep Pace with Innovation

    S.Sridhar* et al. (IJITR) INTERNATIONAL JOURNAL OF INNOVATIVE TECHNOLOGY AND RESEARCH Volume No.5, Issue No.2, February – March 2017, 5681-5704. A Study On Various Programming Languages To Keep Pace With Innovation S.SRIDHAR Professor & Director RV Centre for Cognitive & Central Computing R.V.College of Engineering, Mysore Road Bangalore-560059 India Abstract: A programming language is a formal computer language designed to communicate instructions to a machine, particularly a computer. Programming languages can be used to create programs to control the behaviour of a machine or to express algorithms. The earliest known programmable machine preceded the invention of the digital computer and is the automatic flute player described in the 9th century by the brothers Musa in Baghdad, "during the Islamic Golden Age". From the early 1800s, "programs" were used to direct the behavior of machines such as Jacquard looms and player pianos. Thousands of different programming languages have been created, mainly in the computer field, and many more still are being created every year. Many programming languages require computation to be specified in an imperative form (i.e., as a sequence of operations to perform) while other languages use other forms of program specification such as the declarative form (i.e. the desired result is specified, not how to achieve it). The description of a programming language is usually split into the two components of syntax (form) and semantics (meaning). Some languages are defined by a specification document (for example, the C programming language is specified by an ISO Standard) while other languages (such as Perl) have a dominant implementation that is treated as a reference.
  • 19710010121.Pdf

    19710010121.Pdf

    General Disclaimer One or more of the Following Statements may affect this Document This document has been reproduced from the best copy furnished by the organizational source. It is being released in the interest of making available as much information as possible. This document may contain data, which exceeds the sheet parameters. It was furnished in this condition by the organizational source and is the best copy available. This document may contain tone-on-tone or color graphs, charts and/or pictures, which have been reproduced in black and white. This document is paginated as submitted by the original source. Portions of this document are not fully legible due to the historical nature of some of the material. However, it is the best reproduction available from the original submission. Produced by the NASA Center for Aerospace Information (CASI) ^i A PROPOSFD TRANSLATOR-WRITING-SYSTEM LANGUAGE FRANKLIN L. DE RLMER CEP REPORT, VOLUME 3, No. 1 September 1970 C4 19 5 G °o ACCESSION NUPBER) (T U) c^`r :E 3 (PAG 5 (CODE) ^y1P`C{ o0 LL (NASA CR OR T X OR AD NUME ►_R) (CATEGORY) 0^0\G^^^ v Z The Computer Evolution Project Applied Sciences The University of California at Santa Cruz, California 95060 A PROPOSED TRANSLATOR-WRITING-SYSTEM LANGUAGE ABSTRACT We propose herein a language for an advanced translator writing system (TWS), a system for use by langwige designers, I d as opposed to compiler writers, which will accept as input a formal specification of a language and which will generate as output a translator for the specified language.
  • MTS Volume 1, for Example, Introduces the User to MTS and Describes in General the MTS Operating System, While MTS Volume 10 Deals Exclusively with BASIC

    MTS Volume 1, for Example, Introduces the User to MTS and Describes in General the MTS Operating System, While MTS Volume 10 Deals Exclusively with BASIC

    M T S The Michigan Terminal System The Michigan Terminal System Volume 1 Reference R1001 November 1991 University of Michigan Information Technology Division Consulting and Support Services DISCLAIMER The MTS manuals are intended to represent the current state of the Michigan Terminal System (MTS), but because the system is constantly being developed, extended, and refined, sections of this volume will become obsolete. The user should refer to the Information Technology Digest and other ITD documentation for the latest information about changes to MTS. Copyright 1991 by the Regents of the University of Michigan. Copying is permitted for nonprofit, educational use provided that (1) each reproduction is done without alteration and (2) the volume reference and date of publication are included. 2 CONTENTS Preface ........................................................................................................................................................ 9 Preface to Volume 1 .................................................................................................................................. 11 A Brief Overview of MTS .......................................................................................................................... 13 History .................................................................................................................................................. 13 Access to the System ...........................................................................................................................
  • Translator Writing System

    Translator Writing System

    A TRANSLATOR WRITING SYSTEM • FOR MINICOMPUTERS by Jake Madderom B.A.Sc, University of British Columbia, 1968 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in the Department of Electrical Engineering We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA June 1973 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the Head of my Department or by his representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of £ C* ' r\ ^ <£. r~ , .i The University of British Columbia Vancouver 8, Canada ABSTRACT Some portions of real-time computer process control software can be programmed with special purpose high-level languages. A trans• lator writing'system for minicomputers is developed to aid in writing translators for those languages. The translator writing system uses an LR(1) grammar analyzer with an LR(1) skeleton parser. XPL is used as the source language for the semantics. An XPL to intermediate language translator has been written to aid in the translation of XPL programs to minicomputer assembly language. A simple macro generator must be written to translate intermediate language programs into various minicomputer assembly languages. i TABLE OF CONTENTS Page ABSTRACT i TABLE OF CONTENTS • ii LIST OF ILLUSTRATIONS iii GLOSSARY iv ACKNOWLEDGEMENT vii 1.
  • The Copyright Law of the United States (Title 17, U.S

    The Copyright Law of the United States (Title 17, U.S

    NOTICE WARNING CONCERNING COPYRIGHT RESTRICTIONS: The copyright law of the United States (title 17, U.S. Code) governs the making of photocopies or other reproductions of copyrighted material. Any copying of this document without permission of its author may be prohibited by law. CMU-CS-84-163 An Efficient All-paths Parsing Algorithm for Natural Languages Masaru Tornita Computer Science Department Carnegie-Mellon University Pittsburgh, PA 15213 25 October 1984 Abstract An extended LR parsing algorithm is introduced and its application to natural language processing is discussed. Unlike the standard LR, our algorithm is capable of handling arbitrary context-free phrase structure grammars including ambiguous grammars, while most of the LR parsing efficiency is preserved. When an input sentence is ambiguous, it produces all possible parses in an efficient manner with the idea of a "graph-structured stack." Comparisons with other parsing methods are made. This research was sponsored by the Defense Advanced Research Projects Agency (DOD), ARPA Order No. 3597, monitored by the Air Force Avionics Laboratory Under Contract F33615-81 -K-1539. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the US Government. i Table of Contents 1. Introduction 1 2. LR parsing 3 2.1. An example 3 2.2. Problem in Applying to Natural Languages 5 3. MLR parsing 7 3.1. With Stack List 7 3.2. With a Tree-structured Stack 9 3.3. With a Graph-structured Stack 10 4.
  • ESP: a Language for Programmable Devices

    ESP: a Language for Programmable Devices

    ESP: A Language for Programmable Devices Sanjeev Kumar, Yitzhak Mandelbaum, Xiang Yu, and Kai Li Princeton University (sku mar,yitz hakm ,xyu, li) @ cs. princeton, edu ABSTRACT cards was implemented using event-driven state machines in This paper presents the design and implementation of Event- C. Our experience was that while good perfbrmance could driven State-machines Programming (ESP)--a language for be achieved with this approach, the source code was hard to programmable devices. In traditional languages, like C, us- maintain and debug. The implementation involved around ing event-driven state-machines forces a tradeoff that re- 15600 lines of C code. Even after several years of debugging, quires giving up ease of development and reliability to achieve race conditions cause the system to crash occasionally. IJlg}l p~,ti~rlnallc~, ESP is designed to provide all of these ESP was designed to meet the following goals, First, the three properties simult.aneously. language should provide constructs to write concise modu- ESP provides a comprehensive set of teatures to support lar programs. Second, the language should permit the use development of compact and modular programs. The ESP of software verification tools like SPIN [14] so that the con- compiler compiles the programs into two targets---a C file current programs can be tested thoroughly. Finally, the lan- that can be used to generate efficient firmware for the device; guage should permit aggressive compile time optimizations and a specification that can be used by a verifier like SPIN to provide low overhead. to extensively test the firmware. ESP has a number of language features that allow devel- As a case study, we reimplemented VMMC firmware that opment of fast and reliable concurrent programs.