The Helios Operating System

Total Page:16

File Type:pdf, Size:1020Kb

The Helios Operating System The Helios Operating System PERIHELION SOFTWARE LTD May 1991 COPYRIGHT This document Copyright c 1991, Perihelion Software Limited. All rights reserved. This document may not, in whole or in part be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form without prior consent in writing from Perihelion Software Limited, The Maltings, Charlton Road, Shepton Mallet, Somerset BA4 5QE. UK. Printed in the UK. Acknowledgements The Helios Parallel Operating System was written by members of the He- lios group at Perihelion Software Limited (Paul Beskeen, Nick Clifton, Alan Cosslett, Craig Faasen, Nick Garnett, Tim King, Jon Powell, Alex Schuilen- burg, Martyn Tovey and Bart Veer), and was edited by Ian Davies. The Unix compatibility library described in chapter 5, Compatibility,im- plements functions which are largely compatible with the Posix standard in- terfaces. The library does not include the entire range of functions provided by the Posix standard, because some standard functions require memory man- agement or, for various reasons, cannot be implemented on a multi-processor system. The reader is therefore referred to IEEE Std 1003.1-1988, IEEE Stan- dard Portable Operating System Interface for Computer Environments, which is available from the IEEE Service Center, 445 Hoes Lane, P.O. Box 1331, Pis- cataway, NJ 08855-1331, USA. It can also be obtained by telephoning USA (201) 9811393. The Helios software is available for multi-processor systems hosted by a wide range of computer types. Information on how to obtain copies of the Helios software is available from Distributed Software Limited, The Maltings, Charlton Road, Shepton Mallet, Somerset BA4 5QE, UK (Telephone: 0749 344345). Contents 1 Introduction 1 1.1 Hardware limitations .......................... 1 1.2 Actual requirements ........................... 3 1.3 Architectural improvements ...................... 4 1.4 Parallelism ............................... 6 1.5 The Transputer . ........................... 7 1.6 Helios . ................................. 8 1.7 Target hardware . ........................... 9 1.8 About this book . ........................... 11 2 Networks 13 2.1 Introduction ............................... 13 2.2 The components of Helios . ...................... 14 2.2.1 A simple network . ...................... 14 2.2.2 The Helios naming scheme . ................ 15 2.2.3 The I/O server . ...................... 17 2.2.4 The Nucleus .......................... 18 2.2.5 The Init program . ...................... 20 2.2.6 The network server . ...................... 21 2.2.7 The Session Manager ...................... 24 2.2.8 The Task Force Manager .................... 25 2.2.9 Summary of the bootstrap process ............... 26 2.3 Some example networks . ...................... 27 2.3.1 Single-processor embedded systems . ........... 27 2.3.2 Single-processor workstation . ................ 28 2.3.3 Workstation with I/O processor ................ 29 2.3.4 Workstation for developing parallel software ......... 29 2.3.5 A small network . ...................... 30 2.3.6 A fairly small single-user network ............... 30 2.3.7 A network with configuration hardware . ........... 31 2.3.8 A single-user supercomputer . ................ 32 2.3.9 Several single-user systems . ................ 32 2.3.10 A single-user process control system . ........... 33 2.3.11 A small multi-user network . ................ 34 2.3.12 Two connected single-user networks . ........... 35 2.3.13 A large multi-user network . ................ 36 i ii CONTENTS 2.3.14 A mainframe computer ..................... 37 2.3.15 Networked mainframe computers ............... 37 2.4 The real world . ........................... 38 2.4.1 Different hardware . ...................... 38 2.4.2 Inmos . ........................... 38 2.4.3 Parsytec . ........................... 40 2.4.4 Telmat . ........................... 42 2.4.5 Meiko . ........................... 44 2.4.6 Handling different hardware . ................ 45 2.4.7 Mapping task forces onto a network . ........... 46 2.4.8 Possible topologies . ...................... 48 2.4.9 Task force connectivity ..................... 49 2.4.10 Other considerations ...................... 50 2.4.11 Summary . ........................... 50 2.5 Network commands ........................... 50 2.6 Configuration files ........................... 52 2.6.1 host.con ............................ 52 2.6.2 initrc .............................. 54 2.6.3 .login, .cshrc, and .logout ................... 57 2.6.4 nsrc ............................... 58 2.6.5 Network resource maps ..................... 60 2.7 Configuring networks .......................... 72 2.7.1 Single-processor workstation . ................ 72 2.7.2 Workstation with I/O processor ................ 75 2.7.3 Workstation for developing parallel software ......... 77 2.7.4 A small network . ...................... 78 2.7.5 A fairly small single-user network ............... 80 2.7.6 A network with configuration hardware . ........... 82 2.7.7 A single-user supercomputer . ................ 83 2.7.8 Several single-user systems . ................ 84 2.7.9 A process control system .................... 85 2.7.10 A small multi-user network . ................ 87 2.7.11 Two connected single-user networks . ........... 89 2.7.12 A large multi-user network . ................ 90 2.7.13 A mainframe computer ..................... 94 2.7.14 Networked mainframe computers ............... 95 3 Programming under Helios 97 3.1 Simple programming .......................... 97 3.1.1 A simple program . ...................... 98 3.1.2 Driver options . ...................... 98 3.1.3 Multiple modules . ...................... 100 3.1.4 Make .............................. 101 3.1.5 Common suffixes . ...................... 110 3.2 More advanced programming ...................... 111 3.2.1 Libraries . ........................... 112 3.2.2 Other tools ........................... 118 CONTENTS iii 3.2.3 Manual compilation ...................... 122 3.3 Servers ................................. 128 3.3.1 Posix facilities . ...................... 128 3.3.2 System library facilities .................... 131 3.3.3 File systems ........................... 134 3.3.4 The /window server ...................... 135 3.3.5 The /rs232 server . ...................... 143 3.3.6 The centronics server ...................... 149 3.3.7 Mouse and keyboard servers . ................ 150 3.3.8 Networking servers . ...................... 152 3.3.9 /tasks and /loader ....................... 153 3.3.10 The null server . ...................... 154 3.3.11 The error logger . ...................... 154 3.3.12 Real-time clock . ...................... 155 3.3.13 The lock server . ...................... 156 3.3.14 Raw disc servers . ...................... 157 3.3.15 The X window system ..................... 157 3.3.16 Pipe and socket I/O . ...................... 157 3.4 Protection: a tutorial .......................... 159 4 CDL 167 4.1 The CSP model for parallel programming ............... 167 4.2 The CDL language ........................... 169 4.2.1 How to execute task forces................... 169 4.2.2 The task force definition .................... 171 4.2.3 Allocation of streams ...................... 174 4.2.4 Component declarations .................... 177 4.2.5 Replicators ........................... 179 4.2.6 Replicated component declarations . ........... 182 4.2.7 The environment . ...................... 184 4.2.8 Arguments and replicators . ................ 186 4.2.9 Signals and termination .................... 187 4.3 An example as easy as PI . ...................... 187 4.3.1 A simple problem . ...................... 187 4.3.2 How to parallelise the problem . ................ 188 4.3.3 The ring . ........................... 188 4.3.4 A farm topology . ...................... 193 4.3.5 Different levels of communication ............... 197 4.3.6 More about pipe I/O ...................... 199 4.3.7 Running the task force ..................... 199 4.3.8 FORTRAN task forces ..................... 201 4.3.9 Pascal task forces . ...................... 203 4.4 CDL farms and load balancing ..................... 205 4.4.1 A simple farm . ...................... 205 4.4.2 A simple load balancer ..................... 212 4.4.3 More about packets . ...................... 216 4.4.4 Advanced farms . ...................... 216 iv CONTENTS 4.5 Odds and ends . ........................... 218 4.5.1 Communication versus computation . ........... 219 4.5.2 Problems with worker components ............... 221 4.5.3 Parallel servers . ...................... 222 5 Compatibility 225 5.1 Introduction ............................... 225 5.2 Unix compatibility ........................... 225 5.3 File handle sharing ........................... 226 5.4 fork() .................................. 226 5.5 Signals . ................................. 228 5.6 Process identifiers . ........................... 230 5.7 User and group identifiers . ...................... 230 5.8 BSD compatibility ........................... 231 5.9 Porting techniques ........................... 233 5.10 Multi-threaded library access ...................... 234 6 Communication and performance 237 6.1 Communication . ........................... 237 6.1.1 Helios overview . ...................... 238 6.1.2 Pipes . ........................... 239 6.1.3 Sockets . ........................... 242 6.1.4 Message passing . ...................... 247 6.2 Performance ..............................
Recommended publications
  • Inmos T800 Transputer)
    PARALLEL ALGORITHM DEVELOPMENT FOR A SPECIFIC MACHINE (INMOS T800 TRANSPUTER) BY WILLIAM STAUB 1 This paper will desribe from start to finish the parallel algorithm program development for a specific transputer (Inmos T800) network. It is essential to understand how the hardware manages parallel tasks and how information is exchanged between the transputers before writing a parallel program. A transputer (figure1, page3) is a circuit containing a processor, some memory to store programs and data, and several ports for exchanging, or transferring information with other transputers or with the outside world. By designing these circuits so that they could be connected together with the same simplicity with which transistors can be in a computer, the transputer was born. One of the most important factor was the introduction of a high-level language, occam [MAY83], whose features were directly supported by this transputer’s hardware and that made the transputer a building block for parallel computers. However a Locical System C compiler was developed for wider know usage. A prominent factor to utilizing this circuitry was the ease with which transputers could be connected to each other with as little as a few electrical wires. The four bi- directional input/output (I/O) ports of the transputer are designed to interface directly with the ports of other transputers, his feature allows for several transputers to fit on a small footprint, with very little extra logic circuits, making it possible to easily fit four transputers with some memory on a PC daughter board (ISA bus). 2 Figure 1: Transputer block-diagram and examples of interconnection networks.
    [Show full text]
  • A Low Cost, Transputer Based Visual Display Processor G.J. Porter, B
    Transactions on Information and Communications Technologies vol 3, © 1993 WIT Press, www.witpress.com, ISSN 1743-3517 A low cost, transputer based visual display processor G.J. Porter, B. Singh, S.K. Barton Department of Electronic and Electrical Engineering, University of Bradford, Richmond Road, Bradford, West Yorkshire, UK ABSTRACT As major computer systems and in particular parallel computing resources become more accessible to the engineer, it is becoming necessary to increase the performance of the attached video display devices at least pro-rata with those of the computational elements. To this end a number of device manufacturers have developed or are in the process of developing new display controllers, dedicated to the task of improving the display environments of the super computers in use today by engineers. There is however a price to be paid for this development, in terms of monetary cost and in the design effort involved in integrating the new technology into existing systems. This paper will present a solution to this problems. Firstly, by showing how to utilise available transputer technology to upgrade the display capability of existing systems by transferring some of the available processing power from the computational elements of the system to the display controller. Secondly, by utilising a low cost off-the-shelf Transputer Module based video display unit. The new video display processor utilises a three transputer pipeline formed from as Scan Converter Unit, a Span Encoder Unit and a Span Filler Unit, and can be further expanded by increasing the functionality and/or parallelism of each stage if required. 1.
    [Show full text]
  • A Distributed Transputer-Based Architecture Using a Reconfigurable Synchronous Communication Protocol
    A DISTRIBUTED TRANSPUTER-BASED ARCHITECTURE USING A RECONFIGURABLE SYNCHRONOUS COMMUNICATION PROTOCOL Marie Josette Brigitte Vachon B.A.Sc. Royal Military College, Kingston, 1984 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES DEPARTMENT OF ELECTRICAL ENGINEERING We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA August 1989 © Marie Josette Brigitte Vachon s 1989 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 or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of E^(Lm\OAL. k)ZF.P\*iU The University of British Columbia Vancouver, Canada Date IC AVC I J8 7 DE-6 (2/88) Abstract A reliable, reconfigurable, and expandable distributed architecture supporting both bus and point- to-point communication for robotic applications is proposed. The new architecture is based on Inmos T800 microprocessors interconnected through crossbar switches, where communication between nodes takes place via point-to-point bidirectional links. Software development is done on a host computer, Sun 3/280, and the executable code is downloaded to the distributed architecture via the bus. Based on this architecture, an operating system has been designed to provide communication and input/output support.
    [Show full text]
  • Design of a Neural Network Simulator on a Transputer Array
    DESIGN OF A NEURAL NETWORK SIMULATOR ON A TRANSPUTER ARRAY Gary Mclntire James Villarreal, Paul Baffes, and Advanced Systems Engineering Dept. Ford Monica Rua Artificial Intelligence Section, Aerospace, Houston, TX. NASNJohnson Space Center, Houston, TX. Abstract they will be commercially available. Even if they were available today, they would be A high-performance simulator is being built generally unsuitable for our work because to support research with neural networks. All they are very difficult (usually impossible) to of our previous simulators have been special reconfigure programmably. A non-hardwired purpose and would only work with one or two VLSl neural network chip does not exist today types of neural networks. The primary design but probably will exist within a year or two. If goal of this simulator is versatility; it should done correctly, this would be ideal for our be able to simulate all known types of neural simulations. But the state of the art in networks. Secondary goals, in order of reconfigurable simulators are supercomputers importance, are high speed, large capacity, and and parallel processors. We have a very fast ease of use. A brief summary of neural simulator running on the SX-2 supercomputer networks is presented herein which (200 times faster than our VAX 11/780 concentrates on the design constraints simulator), but supercomputer CPU time is imposed. Major design issues are discussed yfzy costly. together with analysis methods and the chosen For the purposes of our research, solutions. several parallel processors were investigated Although the system will be capable of including the Connection Machine, the BBN running on most transputer architectures, it Butterfly, and the Ncube and Intel Hypercubes.
    [Show full text]
  • Finding Aid to the Atari Coin-Op Division Corporate Records, 1969-2002
    Brian Sutton-Smith Library and Archives of Play Atari Coin-Op Division Corporate Records Finding Aid to the Atari Coin-Op Division Corporate Records, 1969-2002 Summary Information Title: Atari Coin-Op Division corporate records Creator: Atari, Inc. coin-operated games division (primary) ID: 114.6238 Date: 1969-2002 (inclusive); 1974-1998 (bulk) Extent: 600 linear feet (physical); 18.8 GB (digital) Language: The materials in this collection are primarily in English, although there a few instances of Japanese. Abstract: The Atari Coin-Op records comprise 600 linear feet of game design documents, memos, focus group reports, market research reports, marketing materials, arcade cabinet drawings, schematics, artwork, photographs, videos, and publication material. Much of the material is oversized. Repository: Brian Sutton-Smith Library and Archives of Play at The Strong One Manhattan Square Rochester, New York 14607 585.263.2700 [email protected] Administrative Information Conditions Governing Use: This collection is open for research use by staff of The Strong and by users of its library and archives. Though intellectual property rights (including, but not limited to any copyright, trademark, and associated rights therein) have not been transferred, The Strong has permission to make copies in all media for museum, educational, and research purposes. Conditions Governing Access: At this time, audiovisual and digital files in this collection are limited to on-site researchers only. It is possible that certain formats may be inaccessible or restricted. Custodial History: The Atari Coin-Op Division corporate records were acquired by The Strong in June 2014 from Scott Evans. The records were accessioned by The Strong under Object ID 114.6238.
    [Show full text]
  • Occam User Group
    for all users of occam and the transputer N912 January 1990 Contents EDITORIAL 2 Contributions to the newsletter 3 Occam user group publications 3 North American transputer users group publications 4 FORTHCOMING 4 Twelfth occam user group technical meeting 4 North American transputer users group spring meeting 5 Third Japanese transputer/ occam international conference 5 Thirteenth occam user group technical meeting 6 North American transputer users group fall meeting 6 Transputing 1991 7 REPORTS 9 Inaugural meeting of the occam user group: Latin America 9 Eleventh occam user group technical meeting 10 Why did the transputer cross The Pond? 14 Second seminar of the Swedish transputer user group 15 continued on back cover Meiko In-Sun Computing Surface Hardware (see page 98) occam is a trade mark of the INMOS Group of Companies 2 occam user group newsletteT EDITORIAL ~ ~ New groups seem to be springing up all around the world; this issue of nan the newsletter carries contact addresses for the first time for groups in U:E ~ Sweden and Latin America. We have contributions from as far afield as Brazil, the Basque country, and Bristol. It is all here: from exotic hardware (see for example pages 19, 82, 98 and many of the product announcements) to expressions of concern that software should be as unexciting as possible (see pages 22, 27). I would particularly like to draw your attention to the initiative to promote the occam language (see page 84); and to the CODE system from C-DAC (see pages 86 and18), an impromptu presentation of which stole the show in the exhibition at the OUG technical meeting in Edinburgh.
    [Show full text]
  • Activisionad2.Pdf
    TEMPTAT10N. HACKER'" THE ACTIVISION LITTLE COMPUTER PEOPLE lbstumble Into get 1D art wllh. "The most fabulous game I've ever run across."-Dave Plotkin, Antic DISCOVERY KIT'" -.ebodyelle'l ~ lt.FI'am compuwsyDrn. lhere.ll\upiDyou. Magazine After years of speculation and months of intensive work, the Activi­ lfyau'ledewr sion Little Computer People Research Group has successfully discov­ 1b be........ "Hacker is every gamer's fantasy come true."-Arnie Katz, Consumer placeyau'rw ered and actually lured out small, living creatures who have been reolly nat sup· Software News pc.d ID be. you aJUid living in the confines of standard, everyday computers. lvtd ID get lhe ........... wartd The only thing we can add is that it was designed by legendary de­ And now you too can join in on the discovery by actually meeting the signer Steve Cartwright. HACKER. Little Computer People (LCP) in your computer. We'll give you every­ Available for: Commodore 64'"/128'" and Amiga;• Apple ~ 11 series, thing you'll need for the task: A special2V> story house-on-a-disk Macintosh,'" Atari~ ST; • 800/XE/XL and compatible systems. (your Little Computer Person's new residence), an informative guide to the care of and communication with LCP, an authorized "Deed" enabling you to register your house-on-a-disk and your own copy of Modern Computer People-a fabulous, full-color magazine which chron­ icles the discovery of the LCPs! Research in progress on: Commodore 64/128 and Apple II series computers. Commodore 64/128 version shown. I AmigaT'" version shown. I / ALTER EGO'" " ..
    [Show full text]
  • 1 Architecture Reference Manual 2 T414 Transputer Product Data
    Contents 1 Architecture reference manual 2 T414 transputer product data 3 T212 transputer product data 4 C011 link adaptor product data 5 C012 link adaptor product data omrnos® Reference manual • transputer architecture 8, inmos, IMS and occam are trade marks of the INMOS Group of Companies. INMOS reserves the right to make changes in specifications at any time and without notice. The information furnished by INMOS in this publication is believed to be accurate; however no responsibility is assumed for its use, nor for any infringements of patents or other rights of third parties resulting from its use. No licence is granted under any patents, trademarks or other rights of the INMOS Group of Companies. Copyright INMOS Limited, 1986 72 TRN 048 02 2 Contents 1 Introduction 5 1.1 Overview 6 1.2 Rationale 7 1.2.1 System design 7 1.2.2 Systems architecture 8 1.2.3 Communication 9 2 Occam model 11 2.1 Overview 11 Occam overview 12 2.2.1 Processes 12 2.2.2 Constructs 13 2.2.3 Repetition 15 2.2.4 Replication 15 2.2.5 Types 16 2.2.6 Declarations, arrays and subscripts 16 2.2.7 Procedures 17 2.2.8 Expressions 17 2.2.9 Timer 17 2.2.10 Peripheral access 18 2.3 Configuration 18 3 Error handling 19 ~------------------------------------------------------~-- _4___ P_rogram_ develo-'-p_m_e_n_t__________ _ 20 4.1- Performance measurement 20 ------------------ ~~--~------~~--~-------------------~-- 4.2 Separate compilation of occam and other languages 20 4.3 Memory map and placement 21 5 Physical architecture 22 5.1 INMOS serial links 22 5.1.1 Overview 22 5.1.2 Electrical specification of links 22 ------5~.~2---=S-ys-t-e--m-se-r-v~ic-e-s-~-------------------------------~23 ---------- 5.2.1 Powering up and down, running and stopping 23 5.2.2 Clock distribution 23 5.3 Bootstrapping from ROM or from a link 23 ------5-.-4--P-e-r-ip-h-eral interfacing 24 6 Notation conventions 26 6.1 Signal naming conventions 26 7 Transputer product numbers 27 3 Preface This manual describes the architecture of the transputer family of products.
    [Show full text]
  • ISRA VISION at a Glance
    ISRA VISION Initiating Coverage 18 February 2019 Better than the human eye – Growth story is expected continue In a highly fragmented market environment ISRA VISION ranks Target price (EUR) 36 Share price (EUR) 28 among the leading players for machine vision technologies with a strong focus on software solutions. Driven by market trends as well as R&D efforts, we expect ISRA’s growth story to continue and Forecast changes forecast a revenue growth CAGR of 10.4% until FY 2022/23e. EBIT % 2019e 2020e 2021e is expected to increase by 10.6% during this period. In addition to organic growth, M&A driven growth is very likely. We initiate the Revenues NM NM NM EBITDA NM NM NM coverage of ISRA VISION with Buy and a TP of EUR 36.00. EBIT adj NM NM NM EPS reported NM NM NM EPS adj NM NM NM ISRA VISION among the technology leaders Source: Pareto ISRA is one of the leading providers for machine vision solutions with specialisation in 3D machine vision. The company’s Ticker ISRG.DE, ISR GR competences are mainly concentrated around the internally Sector Industrials developed software application. Future demand is driven by more Shares fully diluted (m) 21.9 Market cap (EURm) 605 complexity and miniaturization, quality requirements and entering Net debt (EURm) -18 into new markets. Customer benefits are cost savings, process Minority interests (EURm) 2 optimization, higher flexibility and a ROI of clearly <1 year. Enterprise value 19e (EURm) 590 Free float (%) 65 Growth story should continue - 5yrs growth CAGR of 10.4% The well diversified customer base in various end-markets helps ISRA to reduce cyclicality.
    [Show full text]
  • Uva-DARE (Digital Academic Repository)
    UvA-DARE (Digital Academic Repository) Scalable distributed data structures for database management Karlsson, S.J. Publication date 2000 Document Version Final published version Link to publication Citation for published version (APA): Karlsson, S. J. (2000). Scalable distributed data structures for database management. General rights It is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s) and/or copyright holder(s), other than for strictly personal, individual use, unless the work is under an open content license (like Creative Commons). Disclaimer/Complaints regulations If you believe that digital publication of certain material infringes any of your rights or (privacy) interests, please let the Library know, stating your reasons. In case of a legitimate complaint, the Library will make the material inaccessible and/or remove it from the website. Please Ask the Library: https://uba.uva.nl/en/contact, or a letter to: Library of the University of Amsterdam, Secretariat, Singel 425, 1012 WP Amsterdam, The Netherlands. You will be contacted as soon as possible. UvA-DARE is a service provided by the library of the University of Amsterdam (https://dare.uva.nl) Download date:11 Oct 2021 atabasee Management Scalablee Distributed Data Structures s for r Databasee Management Academischh Proefschrift terr verkrijging van de graad van doctor aann de Universiteit van Amsterdam opp gezag van de Rector Magnificus prof.. dr. J. J. M. Franse tenn overstaan van een door het collegee voor promoties ingestelde commissie, inn het openbaar te verdedigen inn de Aula der Universiteit opp donderdag 14 december 2000, te 11.00 uur doorr Jonas S Karlsson geborenn te Enköping, Sweden Promotor:: Prof.
    [Show full text]
  • Innovation in the Video Game Industry: the Role of Nintendo
    Department of Business and Management Course of Managerial Decision Making Innovation in the video game industry: the role of Nintendo Prof. Luigi Marengo Prof. Luca De Benedictis SUPERVISOR CO-SUPERVISOR Fulvio Nicolamaria ID No.705511 CANDIDATE Academic Year 2019/2020 To those who belong to my past, that have made me what I am and to those who belong to my present, who give me the strength to advance 2 Foreword Writing a paper with the gaming industry as one of the main themes may seem, in the eyes of the reader that is not properly involved in the subject, as something atypical and far from the academic conception of what should be debated in a thesis. However, in a work that concerns Economics, even an industry dedicated solely to entertainment like that one of video game can be an interesting challenge. Moreover, each thesis should aim to develop researches on new topics and to process the results. What better way to do this if not by exploring overlooked fields of research? The idea of a work involving Nintendo company as the main topic was among the possible research options, and choosing it as the theme to conclude the Master Degree was the goal I had proposed to myself for a long time. The involvement of the subject of innovation comes from the belief of its importance; since these two themes, innovation and Nintendo, could be easily combined, it was natural to create this work in some way dual. Making available to any reader topics so far from usual ones, without sacrificing the academic character of the paper, was both a challenge and a target.
    [Show full text]
  • STATUS REPORT Sc? (1@’Rq» Lu? Ul __ V? 211 — Q CERN Participation in the GP MIMD ESPRIT Project
    CERN LIBRARIES, GENEVA CERN/DRDU 9 1-12 Danc/M5 llltlllllllllulll II\)Illll|lI)I|l)H)|lllllI|ll)) afch , ;, — P A $(100000690 <_ fri · \ xg ·-J ’ STATUS REPORT Sc? (1@’rQ» lu? Ul __ V? 211 — Q CERN participation in the GP MIMD ESPRIT project P.C. Burkimsher, R.W. Dobinson ' , A. King, B. Martin, and I.M. Willers, CERN. J—L. Pages, University of Lausanne A. Schneider, University of Geneva. In collaboration with INMOS (UK), lead partner. Meiko (UK), Parsys (UK), Parsytec (D) and Telmat (F), main partners. and Grupo APD (E), INESC (P), Siemens (D), SICS (S), Southampton University (UK), IRISA (F) OCR Output spokesman z JMU Introduction A proposal was submitted to ESPRIT in January 1990 by INMOS and four European manufacturers of Transputer based computers. The aim of the proposal is to develop high performance parallel processing computers using a new generation of Transputers. ESPRIT is the EEC supported European Strategic Programme for Research and Development in Information Technology. The technical, manpower and budget details of the project are contained in the technical annex [l] of the official contract that has been signed by the lead and main project partners with the EEC. CERN has taken part in the preparatory work for the GP MIMD ESPRIT proposal and must now decide on the continuation of this work within the framework of the approved project. Transputer Technology Today's microprocessors make available on a single chip a significant fraction of the computing performance of a traditional mainframe. A recent trend has been to construct very powerful computing systems of interconnected microprocessors: up to hundreds or even thousands of processor nodes, each with local memory, joined by a fast switching network.
    [Show full text]