DOCSLIB.ORG

The Design of a Real-Time Operating System for Experimental Psychology KENNETH J

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Design of a Real-Time Operating System for Experimental Psychology KENNETH J Behavior Research Methods & Instrumentation 1979. Vol. 11 (5).507-511 COMPUTER TECHNOLOGY The design of a real-time operating system for experimental psychology KENNETH J. BURKHARDT DepartmentofElectrical Engineering, RutgersUniversity. Piscataway, New Jersey 08854 This paper describes the structure of the operating system that was utilized in the imple­ mentation of the experimental programming language. PL/E. Although the system was originally designed to support programming of psychological experiments on a specific machine (Data General Nova), the operating system can be ported with a minimum of effort to other machines. This paper describes the internal algorithms and control structures used in the system and suggests how it can be moved to other computers. Given the ever decreasing cost of computer hardware, SOFTWARE REQUIREMENTS FOR it is becoming quite clear that the cost of implementing REAL-TIME SYSTEMS any application on a computer is greatly affected by the degree of effort required to develop system software. Software requirements for real-time applications In many small computer environments, system hardware such as experimental psychology must be examined at costs are often negligible when compared with software two levels: the level of the applications software and the costs. Thus, in order to minimize total system cost, level of the operating system software. At the applica­ it is necessary to utilize appropriate design aids for tions level, the problems of real-time programming are efficient software development. Although many such quite complex. The wide disparity between potential tools exist in conventional data processing and scientific applications makes even specification of a typical environments (for example, higher level languages such environment extremely difficult, if not impossible. as FORTRAN and COBOL), there are a limited number Conceptually, real-time programs require little more of tools available for real-time system design. complexity than conventional programs. The only This paper describes the structure of an operating constructs that have to be added to non-real-time system utilized in the implementation of an experi­ languages are capabilities for synchronization and mental language known as PL/E. PL/E is a loosely capabilities for controlling tasks as a function of time. defined higher level language that has been designed . From a practical standpoint, however, there is one to function as an aid in the implementation of real­ potentially large difference between conventional and time systems software. Its primary use has been in real-time programs. In real-time systems the applications applications associated with on-line experimental psy­ programmer must be concerned with operating systems chology. PL/E, however, has also been utilized in several concepts and timing considerations that are transparent commercial data base management systems. in non-real-time applications. This not only makes the This paper has four major sections. The first task of program validation more complex due to timing describes software requirements for real-time systems considerations, but it also makes the basic task of in general and justifies the development of a special­ programming more complex, in that the applications purpose operating system for psychology. The second programmer must be aware of system operations at a section briefly describes the features of PL/E and the lower level. run-time interpreter that supports the language. The At the operating systems level, the problems of third section describes the control structures and real-time software have been extensively investigated. algorithms utilized in the operating system. The final Brinch Hansen (1977), Wirth (1977), and others section describes requirements for moving the operating (Dijkstra, 1968; Hoare, 1974) have proposed and system to other computers. implemented a variety of higher level languages and other facilities for the design and construction of reliable Development of the PL/E system was supported by the and efficient real-time executives for both small and National Institute of Mental Health, Grant MH-21795, Earl large computers. Generally, these software tools include Hunt, principal investigator, and the National Institute of Education, Grant NIE-6-74-0104, Clifford Lunneborg, principal capabilities for controlling concurrent processes, investigator, to the University of Washington. John Palmer, interprocess communication, and general process Zelda Zabinsky, and Barry Yanoff were all instrumental in the synchronization. Unfortunately, many of these facilities implementation of the original system. are inadequately supported by the vendors of mini- and Copyright 1979 Psychonomic Society, Inc. 507 0005·7878/79/050507-05$00.75/0 508 BURKHARDT microcomputer systems. The greatest difficulty either pseudoinstructions (commands) or new data encountered in commercial operating systems is the types to the PL/E language without having to modify uncertainty of execution speed for many operations. existing software. New commands can be added to the This can seriously hinder the capability to control PL/E simply by adding the command name and informa­ psychological experiments, in which there is often a tion about its parameters to a system data me read by desire to control display intervals or measure subject the compiler at run-time. New data types or structures response times to within several milliseconds. Other can also be added to the system with relative ease. For problems often encountered in commercial systems example, structured data records (similar to COBAL or are difficulty in interfacing nonstandard hardware, PL/ 1) have been added to PL/E simply by modifying a limited scheduling capabilities, and lack of support for single systems routine and adding a new data-type appropriate higher level languages. definition command to the compiler. This paper describes a system that was designed to alleviate these problems. The primary emphasis is to The Operating System describe the structure and algorithms utilized in the To a large extent the system can be described as an operating system that supports the experimental operating system without an operating system. The programming language, PL/E. The operating system has only required element of the resident system is a 100 removed the majority of the problems associated with instruction kernel, the scheduler. The scheduler consists real-time programming from the applications program­ of two modules: the interrupt service routine and the mer and supports facilities to accurately estimate timing background scheduler, or interpreter. The interrupt requirements associated with various operations. service routine assigns priorities to the various devices and, on detection of interrupts, passes control to the The Applications Language appropriate device handlers. If after processing PL/E is an algebraic language designed originally for interrupts, the interrupt service routine determines human experimental psychology. The main features of that the system was previously idle, control is passed the language are the abilities to process a variety of dif­ to the background scheduler. ferent variable types, to control external apparatus (e.g., Before describing the actual operation of the experimental stations, CRTs, response keys, etc.), and to operating system in detail, it is useful to deflne the control a large number of subjects simultaneously. control structures utilized in its realization. Rather than being a systems programming language such Control structures. The control structures of a as MODULA (Wirth, 1977) or CONCURRENT PASCAL system are the basic data structures manipulated by (Brinch Hansen, 1977), PL/E is strictly an applications­ the operating system during execution of a program. level language, with virtually all timing control and The control structures define the status of individual other synchronization tasks performed by the under­ subject programs and the status of individual input­ lying operating system (for a more detailed description output (I/O) devices. The four basic structures utilized of the system, see Burkhardt, 1976, 1977; Palmer, in the PL/E system are semaphores, program status McCloud, & Loftus, 1978). vectors (PSV), doubly linked lists, and dope vectors. PL/E is not directly executed. It is an intermediately The flrst three structures are utilized internally by the interpreted language that is compiled before execution operating system and are totally transparent to user takes place interpretively under control of the run-time programs. Dope vectors are generated by the compiler system. The code generated by the compiler is in a and are utilized to pass user program variables to lower three-address prefix format. For example, I =X + Y is level routines. compiled as Semaphores. Semaphores are special integer variables proposed by Dijkstra (1968) as synchronizing flags to ADD be utilized in the allocation of resources. A semaphore @ X is associated with any device that can be simultaneously @ Y accessed by more than a single task (e.g., disk, console @ I TTY). A device is referenced internally by means of two basic operations: allocate (P) and release (V). The where ADD corresponds to an integer constant pointing implementation of the P and V operations is quite to an interpreter branch table, and X, Y, and I are similar to that proposed by Dijkstra (1968). Whenever pointers to descriptors of the appropriate variables. a task requires a device,
Load more

Recommended publications
  • A Screen Oriented Simulator for a DEC PDP-8 Computer
    University of Wollongong Research Online Department of Computing Science Working Faculty of Engineering and Information Paper Series Sciences 1983 A screen oriented simulator for a DEC PDP-8 computer Neil Gray University of Wollongong, [email protected] Follow this and additional works at: https://ro.uow.edu.au/compsciwp Recommended Citation Gray, Neil, A screen oriented simulator for a DEC PDP-8 computer, Department of Computing Science, University of Wollongong, Working Paper 83-2, 1983, 65p. https://ro.uow.edu.au/compsciwp/69 Research Online is the open access institutional repository for the University of Wollongong. For further information contact the UOW Library: [email protected] THE UNIVERSITY OF WOlLONGONG DEPARTMENT OF COMPUTING SCIENCE A SCREEN ORIENTED SIMULATOR FOR A DEC PDP-8 COMPUTER .". N.A.B. Gray Department of Computing Science University of Wollongong Preprlnt No 83-2 January 25. 1983 P.O. Box 1144. WOLLONGONG. N.S.W. AUSTRALIA telephone (042)-282-981 telex AA29022 A Screen Oriented Simulator for a DEC PDP-8 computer. N.A.B. Gray. Department of Computing Science. University of Wollongong. PO Box 1144. WOllongong NSW 2500. Austr"1lia. ABSTRACT This note describes a simulator for the DEC PDP-8 computer. The simulator is intended as an aid tor students starting to learn assemDly language programming. It utilises the simple graphIcs capaDilities of the terminals in the department's laboratories to present. on the termI­ nal screen. a view of the operations of the simulated computer. The complete system comprises two versions at me program tor simulating a PDP-8 computer and a simplified "assembler" tor prepar­ Ing students' programs for execution.
    [Show full text]
  • Also Includes Slides and Contents From
    The Compilation Toolchain Cross-Compilation for Embedded Systems Prof. Andrea Marongiu ([email protected]) Toolchain The toolchain is a set of development tools used in association with source code or binaries generated from the source code • Enables development in a programming language (e.g., C/C++) • It is used for a lot of operations such as a) Compilation b) Preparing Libraries Most common toolchain is the c) Reading a binary file (or part of it) GNU toolchain which is part of d) Debugging the GNU project • Normally it contains a) Compiler : Generate object files from source code files b) Linker: Link object files together to build a binary file c) Library Archiver: To group a set of object files into a library file d) Debugger: To debug the binary file while running e) And other tools The GNU Toolchain GNU (GNU’s Not Unix) The GNU toolchain has played a vital role in the development of the Linux kernel, BSD, and software for embedded systems. The GNU project produced a set of programming tools. Parts of the toolchain we will use are: -gcc: (GNU Compiler Collection): suite of compilers for many programming languages -binutils: Suite of tools including linker (ld), assembler (gas) -gdb: Code debugging tool -libc: Subset of standard C library (assuming a C compiler). -bash: free Unix shell (Bourne-again shell). Default shell on GNU/Linux systems and Mac OSX. Also ported to Microsoft Windows. -make: automation tool for compilation and build Program development tools The process of converting source code to an executable binary image requires several steps, each with its own tool.
    [Show full text]
  • Go Forth with TTL !
    Go Forth with TTL ! The Gigatron TTL Color Computer Forth for a Very Unusual Processor Ken Boak SV Fig. Forth Day 2019 . In September of 1975, MOS Technology launched the 6502 at the Wescon75 Computer Conference in San Francisco. Chuck Peddle and his team had created a very lean, stripped down, small die cpu. Costing just $25, the 6502 was a fraction of the cost of its nearest competitor. At that time the Intel 8080 was $360 and the Motorola 6800 was $175 . The 6502 was clearly a disruptive usurper. 25 year old, HP Engineer, Steve Wozniak, realised that this new microprocessor would be a game-changer and went on to incorporate it into the small computer he was developing. That machine went on to become the Apple I. In 1975 7400 TTL was the “Bread and Butter” of logic design: 7400 series TTL integrated circuits were developed in the early 1960’s. Initially quite expensive so mainly used in Military and Aerospace applications. By the early 1970’s TTL had become a versatile family of standardised, low cost,. easy to use logic. Typically about $1 per device. 7400 series logic was widely used in the design of minicomputers, including the PDP-11, the Data General Nova 1200 and later models of PDP-8. TTL was a viable, faster and cheaper processing solution than the emerging 8-bit microprocessors such as MOS 6502, Intel 8080 and the Motorola 6800. Essential Reading 16-bit TTL CPU board from Data General Nova 1200 The Gigatron TTL Computer – What is it? Started as a Hackaday.io project in Spring 2017 by Marcel van Kervinck of The Hague, Netherlands.
    [Show full text]
  • Computer Architecture and Assembly Language
    Computer Architecture and Assembly Language Gabriel Laskar EPITA 2015 License I Copyright c 2004-2005, ACU, Benoit Perrot I Copyright c 2004-2008, Alexandre Becoulet I Copyright c 2009-2013, Nicolas Pouillon I Copyright c 2014, Joël Porquet I Copyright c 2015, Gabriel Laskar Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being just ‘‘Copying this document’’, no Front-Cover Texts, and no Back-Cover Texts. Introduction Part I Introduction Gabriel Laskar (EPITA) CAAL 2015 3 / 378 Introduction Problem definition 1: Introduction Problem definition Outline Gabriel Laskar (EPITA) CAAL 2015 4 / 378 Introduction Problem definition What are we trying to learn? Computer Architecture What is in the hardware? I A bit of history of computers, current machines I Concepts and conventions: processing, memory, communication, optimization How does a machine run code? I Program execution model I Memory mapping, OS support Gabriel Laskar (EPITA) CAAL 2015 5 / 378 Introduction Problem definition What are we trying to learn? Assembly Language How to “talk” with the machine directly? I Mechanisms involved I Assembly language structure and usage I Low-level assembly language features I C inline assembly Gabriel Laskar (EPITA) CAAL 2015 6 / 378 I Programmers I Wise managers Introduction Problem definition Who do I talk to? I System gurus I Low-level enthusiasts Gabriel Laskar (EPITA) CAAL
    [Show full text]
  • Compiler Construction
    Compiler Construction Chapter 11 Compiler Construction Compiler Construction 1 A New Compiler • Perhaps a new source language • Perhaps a new target for an existing compiler • Perhaps both Compiler Construction Compiler Construction 2 Source Language • Larger, more complex languages generally require larger, more complex compilers • Is the source language expected to evolve? – E.g., Java 1.0 ! Java 1.1 ! . – A brand new language may undergo considerable change early on – A small working prototype may be in order – Compiler writers must anticipate some amount of change and their design must therefore be flexible – Lexer and parser generators (like Lex and Yacc) are therefore better than hand- coding the lexer and parser when change is inevitable Compiler Construction Compiler Construction 3 Target Language • The nature of the target language and run-time environment influence compiler construction considerably • A new processor and/or its assembler may be buggy Buggy targets make it difficult to debug compilers for that target! • A successful source language will persist over several target generations – E.g., 386 ! 486 ! Pentium ! . – Thus the design of the IR is important – Modularization of machine-specific details is also important Compiler Construction Compiler Construction 4 Compiler Performance Issues • Compiler speed • Generated code quality • Error diagnostics • Portability • Maintainability Compiler Construction Compiler Construction 5 Compiler Speed • Reduce the number of modules • Reduce the number of passes Perhaps generate machine
    [Show full text]
  • Computer Architecture Anc Instruction Set Design*
    Computer architecture anc instruction set design* by P. C. ANAGNOSTOPOULOS, M. J. MICHEL, G. SOCKUT, G. M. STABLER, and A. van DAM Brown University Providence, Rhode Island INTRODUCTION The Brown University Graphics System (BUGS)1* was designed as the vehicle for performing this research. Prin­ A group of computer scientists and mathematicians at cipally, the configuration consists of an IBM S/360-67 Brown University has been engaged in the study of running the CP-67/CMS time-sharing system,10 used by computer graphics for the past eight years. During the the entire Brown University community, and a satellite course of these studies a variety of topics has been inves­ display station, as illustrated in Figure 1. This reasonably tigated, in particular, during the last few years, the use of powerful satellite configuration provides such facilities as microprogramming for implementing graphics sys­ program editing and compilation, debugging tools, and tems.2021' In early 1971, Professor Andries van Dam and most importantly, application processing power and data his associates submitted a threefold research proposal to storage. However, because of the two rather distinct the National Science Foundation. The problems to be demands placed upon the local processor, that of display investigated were: generation and general computing, and because these two capabilities could run in parallel, it was further deter­ (1). Inter-Connected Processing (ICP-ing) between a mined that the inclusion of two separate processors in the central computer and an associated satellite proces­ graphics station would be in order. In particular, the first sor, with the goal of a dynamically alterable solu­ of these processors would be of a general-purpose nature, tion to the "division of labor" problem; program while the second would be designed specifically for main­ modules would be dynamically linked in either tenance and regeneration of the display.
    [Show full text]
  • Cern Libraries, Geneva Cm-P00087609 Cern/Fc/1374
    CERN/FC/1374 CERN LIBRARIES, GENEVA Original: English 15 September, 1971 CM-P00087609 ORGANISATION EUROPÉENNE POUR LA RECHERCHE NUCLÉAIRE CERN EUROPEAN ORGANIZATION FOR NUCLEAR RESEARCH FINANCE COMMITTEE Hundred-and-fourteenth Meeting Geneva - 29 September, 1971 ADJUDICATION FOR REMOTE INPUT OUTPUT STATIONS FOR THE CERN CENTRAL COMPUTER SYSTEM The document CERN/FC/1340, Programme for Acquisition of Peripheral Equipment for the CERN Central Computer System, outlines the programme of development needed to build up a decentralized service based on the CDC 7600 computer. The first step in this programme consists of the acquisition of five or six Remote Input Output Stations. Each station will be based on a small computer which initially drives a card reader, line printer and a communications controller. Additional stations may be purchased later and some will be expanded by the addition of extra peripherals and high speed communications equipment as the demands on the decentralized service grow. The offers received from firms show the Modular One computer manufactured by Computer Technology Limited to be the one which most exactly meets the technical specification. The offer from Computer Technology Limited is a few percent more expensive than the two other possible machines for the initial configuration, but this is more than compensated for by the proven software and greater capability for ex• pansion of the Modular One Computer. The Finance Committee is requested to approve the award of the contract for an initial order of five or six basic Remote Input Output Stations from Computer Technology Limited at a price of approx• imately 182,000 Swiss Francs per station (excluding the card reader), with the possibility of later 71/286/5/e CERN/FC/1374 I.
    [Show full text]
  • Embedded Firmware Development Languages/Options
    Module -4 Embedded System Design Concepts Characteristics & Quality Attributes of Embedded Systems Characteristics of Embedded System Each Embedded System possess a set of characteristics which are unique to it. Some important characteristics of embedded systems are: Application & Domain Specific Reactive & Real Time Operates in ‘harsh’ environment Distributed Small size and Weight Power Concerns Quality Attributes of Embedded Systems: Represent the non-functional requirements that needs to be addressed in the design of an embedded system. The various quality attributes that needs to be addressed in any embedded system development are broadly classified into Operational Quality Attributes Refers to the relevant quality attributes related to tan embedded system when it is in the operational mode or ‘online ’ mode Non-Operational Quality Attributes The Quality attributes that needs to be addressed for the product ‘not’ on the basis of operational aspects are grouped under this category Operational Quality Attributes Response Throughput Reliability Maintainability Security Safety Non-Operational Quality Attributes Testability & Debug-ability Evolvability Portability Time to Prototype and Market Per Unit and Total Cost Washing Machine – Application Specific Embedded System V Extensively used in Home Automation for washing and drying clothes V Contains User Interface units (I/O) like Keypads, Display unit, LEDs for accepting user inputs and providing visual indications V Contains sensors like, water level sensor, temperature
    [Show full text]
  • Assembly Language Programming by James and Jarrod Parkes Abstract
    Technical Course Curriculum and Annotated Bibliography CS308: Assembly Language Programming By James and Jarrod Parkes Abstract At the University of Alabama in Huntsville, the Computer Science (CS) Department is facing a decreased student interest in their CS 308 assembly language course. As a result, this new course curriculum and annotated bibliography have been created to restore excitement into the program. Since today's students are seeking innovative applications for programming, this curriculum teaches the 6502 assembly language with a focus on the Nintendo Entertainment System (NES)--a vintage video game console. While linearly covering the required assembly language material, this curriculum incorporates interactive examples from classic NES titles such as Super Mario and The Legend of Zelda. With this curriculum, CS professors are also given the tools to guiding students through the development of their very own NES video games. By the end of the curriculum, professors will be fully equipped to teach the 6502 assembly language while providing students the rewarding experience of game development. Additionally, the annotated bibliography includes supplementary texts and online articles to help reinforce topics for professors and students. Source: Google Images ii Table of Contents Introduction to the Assembly Language Course....................................................... 1! What is an Assembly Language? .................................................................................. 1! How is this Course Structured?...................................................................................
    [Show full text]
  • Chapter 1 Basic Principles of Programming Languages
    Chapter 1 Basic Principles of Programming Languages Although there exist many programming languages, the differences among them are insignificant compared to the differences among natural languages. In this chapter, we discuss the common aspects shared among different programming languages. These aspects include: programming paradigms that define how computation is expressed; the main features of programming languages and their impact on the performance of programs written in the languages; a brief review of the history and development of programming languages; the lexical, syntactic, and semantic structures of programming languages, data and data types, program processing and preprocessing, and the life cycles of program development. At the end of the chapter, you should have learned: what programming paradigms are; an overview of different programming languages and the background knowledge of these languages; the structures of programming languages and how programming languages are defined at the syntactic level; data types, strong versus weak checking; the relationship between language features and their performances; the processing and preprocessing of programming languages, compilation versus interpretation, and different execution models of macros, procedures, and inline procedures; the steps used for program development: requirement, specification, design, implementation, testing, and the correctness proof of programs. The chapter is organized as follows. Section 1.1 introduces the programming paradigms, performance, features, and the development of programming languages. Section 1.2 outlines the structures and design issues of programming languages. Section 1.3 discusses the typing systems, including types of variables, type equivalence, type conversion, and type checking during the compilation. Section 1.4 presents the preprocessing and processing of programming languages, including macro processing, interpretation, and compilation.
    [Show full text]
  • Fifty Years in Home Computing, the Digital Computer and Its Private Use(Er)S
    International Journal of Parallel, Emergent and Distributed Systems ISSN: 1744-5760 (Print) 1744-5779 (Online) Journal homepage: https://www.tandfonline.com/loi/gpaa20 Fifty years in home computing, the digital computer and its private use(er)s Stefan Höltgen To cite this article: Stefan Höltgen (2020) Fifty years in home computing, the digital computer and its private use(er)s, International Journal of Parallel, Emergent and Distributed Systems, 35:2, 170-184, DOI: 10.1080/17445760.2019.1597085 To link to this article: https://doi.org/10.1080/17445760.2019.1597085 © 2019 The Author(s). Published by Informa UK Limited, trading as Taylor & Francis Group Published online: 26 Mar 2019. Submit your article to this journal Article views: 354 View related articles View Crossmark data Full Terms & Conditions of access and use can be found at https://www.tandfonline.com/action/journalInformation?journalCode=gpaa20 INTERNATIONAL JOURNAL OF PARALLEL, EMERGENT AND DISTRIBUTED SYSTEMS 2020, VOL. 35, NO. 2, 170–184 https://doi.org/10.1080/17445760.2019.1597085 Fifty years in home computing, the digital computer and its private use(er)s Stefan Höltgen Department for Musicology and Media Science, Humboldt University, Berlin, Germany ABSTRACT ARTICLE HISTORY The following chapter will discuss the relation between home computer his- Received 13 March 2019 tory and computer programming – with a focus on game programming. Accepted 16 March 2019 The nurseries of the early 1980s are the origins of the later computer game KEYWORDS industry and the private use of microcomputers becomes an essential part Homecomputer; computer of the ‘playful’ exploration and emancipation of technology.
    [Show full text]
  • Ada: the Maginot Line of Languages -Or
    BACKTALK Ada: The Maginot Line of Languages -or- One language to rule them all, One language to find them, One language to (withbring apologiesthem all toan J.R.R.Tolkien)d in the darkness bind them. uring World War I, more than one million French citizens The Ada programming language shall become the single were killed, and another estimated four to five million common programming language for Defense mission-criti- were wounded. Many French politicians and generals thought that cal applications. Effective 1 January 1984 for programs the Treaty of Versailles (which ended the war, and was supposed to entering Advanced Development and 1 July 1984 for pro- punish the defeated countries and prevent further conflict) was grams entering Full-Scale Engineering Development, Ada Dinsufficient protection. France was justifiably concerned that the shall be the programming language. treaty was really just an armistice and that war would ultimately resume (as it did – World War II). To protect France, many influ- The problem was that back in 1983 there weren’t many compil- ential politicians and generals were in favor of an aggressive set of ers, tools, or experienced programmers. Compilers were slow and fortifications. There were many studies and meetings, and based on tended to consume all the resources of even high-end computers. the consensus of opinion, the Maginot Line was built. The general feeling among us Ada zealots was that the DeLauer The Maginot Line, named after French minister of defense memo was premature and actually worked against the cause of Ada. André Maginot, was a line of concrete fortifications, tank obstacles, Because of the lack of tools, compilers, and trained programmers, machine gun posts, and other defenses which were built along the many developers either received a waiver from the Ada mandate or Italian and German border.
    [Show full text]