DOCSLIB.ORG

Oberon System Implemented on a Low-Cost FPGA Board

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Oberon System Implemented on a Low-Cost FPGA Board XPERIMENT Oberon System Implemented on a Low-Cost FPGA Board by Niklaus Wirth Professor (retired) Swiss Federal Institute of Technology (ETH) Zurich, Switzerland [email protected] 30 Xcell Journal Second Quarter 2015 XPERIMENT n 1988, Jürg Gutknecht and I completed and published the programming language A Xilinx Spartan-3 board Oberon [1,2] as the successor to two oth- er languages, Pascal and Modula-2, which becomes the basis for I had developed earlier in my career. We Ioriginally designed the Oberon language to be revamping the author’s more streamlined and efficient than Modula-2 so that it could better help academics teach system Oberon programming programming to computer science students. To advance this endeavor, in 1990 we developed the language and compiler for Oberon operating system (OS) as a modern im- plementation for workstations that use windows use in software education. and have word-processing abilities. We then published a book that details both the Oberon compiler and and the operating system of the same name. The book, entitled Project Oberon, includes thorough instructions and source code. A few years ago, my friend Paul Reed suggest- ed that I revise and reprint the book because of its value for teaching system design, and be- cause it serves as a good starting point to help would-be innovators build dependable systems from scratch. There was a big obstacle, however. The com- piler I originally developed targeted a processor that has essentially disappeared. Thus, my solu- tion was to rewrite a compiler for a modern pro- cessor. But after doing quite a bit of research, I couldn’t find a processor that satisfied my cri- teria for clarity, regularity and simplicity. So I designed my own. I was able to bring this idea to fruition because of the modern FPGA, as it Xcell Journal is honored to pub- lish this article by industry leg- end Niklaus Wirth, who invent- ed Pascal and several derivative programming languages and has pioneered some classic ap- proaches to computer and soft- ware engineering. A recipient of the ACM Turing Award and of the IEEE Computer Pioneer Award, Professor Wirth has retired from teaching but continues to help ed- ucators develop and inspire the innovators of tomorrow. Second Quarter 2015 Xcell Journal 31 XPERIMENT Choosing a Xilinx FPGA allowed me to update the system while keeping the design as close as possible to the original version from 1990. allowed me to design the hardware as The book and the source code for 32 bits; and a control unit with instruc- well as the system software. What’s the entire system are available on pro- tion register, IR and program counter more, choosing a Xilinx® FPGA al- jectoberon.com [3,4,5]. Also available at PC. The processor is represented by the lowed me to update the system while the same site is a single file called S3RI- Verilog module RISC5. keeping the design as close as possible SCinstall.zip. This file contains instruc- The processor features 20 instruc- to the original version from 1990. tions, an SD-card filesystem image and tions: four for moving, shifting and ro- The new processor is called RISC, FPGA configuration bit files (in the form tating; four for logic operations; four and it was implemented on the low- of PROM files for the Spartan-3 board’s for integer arithmetic; four for float- cost Digilent Spartan®-3 development Platform Flash), together with construc- ing-point arithmetic; two for memory board, hosting a 1-Mbyte static RAM tion details for the SD-card/mouse inter- access; and two for branching. (SRAM) memory. The only system face hardware. RISC5 is imported by RISC5Top, the hardware additions I made were to environment, which contains the interfac- add an interface for a mouse and an THE RISC PROCESSOR es to various (memory-mapped) devices SD card to replace the hard-disk drive The processor consists of an arithme- and the SRAM (256M x 32 bit). The entire in the older system. tic-logic unit; an array of 16 registers of system (Figure 1) consists of the follow- RISC5TOP RISC5 Multiplier Divider FPAdder FPMultiplier FPDivider VID SPI PS2 Mouse RS232 Figure 1 – Diagram of the system and the Verilog modules it contains 32 Xcell Journal First Quarter 2015 XPERIMENT where the left button serves to set a car- RISC5Top environment 194 et, marking a text position, and the right RISC5 processor 201 button serves to select a text stretch. Multiplier integer arithmetic 47 The module “Kernel” contains the Divider 24 disk-store management and the garbage FPAdder floating-point arithmetic 98 collector. I ensured that the viewers FPMultiplier 33 were tiled and do not overlap. The stan- FPDivider 35 dard layout shows two vertical tracks SPI SD card and transmitter/receiver 25 with any number of viewers. You can VID 1024 x 768 video controller 73 enlarge them, make them smaller or PS2 keyboard 25 move them by simply dragging their title Mouse mouse 95 bars. Figure 2 shows the user interface RS232T RS232 transmitter 23 running on the monitor, along with the RS232R RS232 receiver 25 Spartan-3 board, keyboard and mouse. The system when loaded occupies 112,640 bytes in module space (21 per- ing Verilog modules (line counts shown): THE OBERON OPERATING SYSTEM cent) and 16,128 bytes of the heap (3 I memory-mapped the black-and- The operating system software consists percent). It consists of the following white VGA display so that it occupies of a core that includes a memory allo- modules (line counts shown), as depict- 1024 x 768 x 1 bit per pixel = 98,304 cator with a garbage collector and a file ed in Figure 3: bytes, which is essentially 10 percent of system, along with the loader, a text sys- the available main memory of 1 Mbyte. tem, a viewer system and a text editor. Kernel 271 (inner core) The SD card replaces the 80 Mbytes in The module called “Oberon” is the FileDir 352 the original system. It is accessed over central task dispatcher while “System” Files 505 a standard SPI interface, which accepts is the basic command module. An ac- Modules (loader) 226 and serializes bytes or 32-bit words. The tion is evoked by clicking the middle Viewers 216 (outer core) keyboard and the mouse are connected button on the text “M.P” in any viewer Texts 532 by standard, serial PS-2 interfaces. Fur- on the display, where P is the name of a Oberon 411 thermore, there is a serial, asynchro- procedure declared in module M. If M is MenuViewers 208 nous RS-232 line and a general-purpose, not present, it is automatically loaded. TextFrames 874 8-bit parallel I/O interface. Module Most text-editing commands, howev- System 420 RISC5Top also provides a counter, in- er, are evoked by simple mouse clicks, Edit 233 cremented every millisecond. It is remarkable that system initial- ization at power-on or reset takes only about 2 seconds. This includes a gar- bage-collecting scan of the file directory. THE OBERON COMPILER The compiler, hosted on the system itself, uses the simple top-down re- cursive-descent parsing method. You can activate the compiler on a module’s selected source text by us- ing the command ORP.Compile @. The parser inputs symbols from the scanner delivering identifiers, num- bers and special symbols (like BE- GIN, END, + and so on). This scheme has proven to be useful and elegant in many applications. It is described in detail in my book Compiler Con- Figure 2 – Monitor showing user interface, with Spartan-3 board at right struction [6,7]. First Quarter 2015 Xcell Journal 33 XPERIMENT The parser calls procedures in the ported variables. The base addresses are ORP parser 968 code generator module. They direct- loaded on demand from a system-glob- ORG code generator 1120 ly append instructions in a code array. al module table, whose address is held ORB base def 435 Forward-branch instructions are pro- in register R12. R15 is used for return ORS scanner 311 vided with jump addresses at the end of addresses (link), as determined by the a module’s compilation (fixups), when RISC architecture. Thus, R0 - R11 are The compiler occupies 115,912 all branch destinations are known. available for expression evaluation and bytes (22 percent) of the module All variable addresses are relative to a for passing procedure parameters. space and 17,508 bytes (4 percent) of base register. This is R14 (stack pointer) The entire compiler consists of four the heap (before any compilation). Its for local variables (set at procedure en- relatively small and efficient modules source code is about 65 kbytes long. try at run-time), or R13 for global and im- (line counts shown): Compilation of the compiler itself The Lola HDL and its Translation to Verilog The hardware-description language To drive the development of Lola-2, ethz.ch/personal/wirth/Lola/Lola2.pdf). (HDL) called Lola was defined in 1990 we had the ambition to reformulate in For the sake of brevity, we show as a means for teaching the basics of Lola all modules of the RISC5 proces- here only a single example of a Lola hardware design. This was the period sor. This has now been achieved. text (Figure 1). The unit of source when textual definitions started to re- text is called a module. Its heading place circuit diagrams, and when the THE LOLA LANGUAGE specifies the name and its input and first FPGAs became available, although Lola is a small, terse language in the output parameters with their names had not yet reached mainstream design.
Load more

Recommended publications
  • PL/I List Processing • PL/I Language Lacked FaciliEs for TreaNg Linked Lists HAROLD LAWSON,JR
    The Birth of the Pointer Variable Based upon: Experiences and Reflec;ons of a Computer Pioneer Harold “Bud” Lawson FELLOW FELLOW and LIFE MEMBER IEEE COMPUTER SOCIETY CHARLES BABBAGE COMPUTER PIONEER FELLOW Overlapping Phases • Phase 1 (1959-1974) – Computer Industry • Phase 2 (1974-1996) - Computer-Based Systems • Phase 3 (1996-Present) – Complex Systems • Dedicated to all the talented colleagues that I have worked with during my career. • We have had fun and learned from each other. • InteresMng ReflecMons and Happenings are indicated in Red. Computer Industry (1959 to 1974) • Summer 1958 - US Census Bureau • 1959 Temple University (Introduc;on to IBM 650 (Drum Machine)) • 1959-61 Employed at Remington-Rand Univac • 1961-67 Employed at IBM • 1967-69 Part Time Consultant (Professor) • 1969-70 Employed at Standard Computer Corporaon • 1971-73 Consultant to Datasaab, Linköping • 1973-… Consultant .. Expert Witness.. Rear Admiral Dr. Grace Murray Hopper (December 9, 1906 – January 1, 1992) Minted the word “BUG” – During her Mme as Programmer of the MARK I Computer at Harvard Minted the word “COMPILER” with A-0 in 1951 Developed Math-MaMc and FlowmaMc and inspired the Development of COBOL Grace loved US Navy Service – The oldest acMve officer, reMrement at 80. From Grace I learned that it is important to queson the status-quo, to seek deeper meaning and explore alterna5ve ways of doing things. 1980 – Honarary Doctor The USS Linköpings Universitet Hopper Univac Compiler Technology of the 1950’s Grace Hopper’s Early Programming Languages Math-MaMc
    [Show full text]
  • From Signal Temporal Logic to FPGA Monitors
    From Signal Temporal Logic to FPGA Monitors Stefan Jaksiˇ c´∗, Ezio Bartocci†, Radu Grosu†, Reinhard Kloibhofer∗, Thang Nguyen‡ and Dejan Nickoviˇ c´∗ ∗AIT Austrian Institute of Technology, Austria †Faculty of Informatics, Vienna University of Technology, Austria ‡Infineon Technologies AG, Austria Abstract— allows very long tests that are not possible with simulation- based methods. Design emulation is used both to explore Due to the heterogeneity and complexity of systems-of- systems (SoS), their simulation is becoming very time consuming, the behavior of digital and analog components. In the latter expensive and hence impractical. As a result, design simulation is case, the (possibly mixed signal) component is approximated increasingly being complemented with more efficient design em- with its discretized behavioral model. By combining these two ulation. Runtime monitoring of emulated designs would provide approaches, we provide a rigorous method for runtime verifi- a precious support in the verification activities of such complex cation of long executions resulting from mixed signal design systems. emulations. In addition to design emulations, our proposed We propose novel algorithms for translating signal temporal solution can be used to monitor real mixed-signal devices in logic (STL) assertions to hardware runtime monitors imple- post-silicon validation in real-time. mented in field programmable gate array (FPGA). In order to We choose Signal Temporal Logic (STL) [13] as our accommodate to this hardware specific setting, we restrict our- selves to past and bounded future temporal operators interpreted specification language. STL allows describing complex timing over discrete time. We evaluate our approach on two examples: relations between digital and analog “events”, where the latter the mixed signal bounded stabilization property; and the serial are specified via numerical predicates.
    [Show full text]
  • Language-Level Support for Exploratory Programming of Distributed Virtual Environments
    In Proc ACM UIST ‘96 (Symp. on User Interface Software and Technology), Seattle, WA, November 6–8, 1996, pp. 83–94. Language-Level Support for Exploratory Programming of Distributed Virtual Environments Blair MacIntyre and Steven Feiner Department of Computer Science, Columbia University, New York, NY, 10027 {bm,feiner}@cs.columbia.edu http://www.cs.columbia.edu/~{bm,feiner} Abstract resulted in an unmanageable welter of client-server relation- ships, with each of a dozen or more processes needing to We describe COTERIE, a toolkit that provides language- create and maintain explicit connections to each other and to level support for building distributed virtual environments. handle inevitable crashes. COTERIE is based on the distributed data-object paradigm for distributed shared memory. Any data object in COTE- We spent a sufficiently large portion of our time reengineer- RIE can be declared to be a Shared Object that is replicated ing client-server code that it became clear to us that our fully in any process that is interested in it. These Shared implementation of the client-server model was unsuitable Objects support asynchronous data propagation with atomic for exploratory programming of distributed research proto- serializable updates, and asynchronous notification of types. The heart of the problem, as we saw it, was a lack of updates. COTERIE is built in Modula-3 and uses existing support for data sharing that was both efficient and easy for Modula-3 packages that support an integrated interpreted programmers to use in the face of frequent and unantici- language, multithreading, and 3D animation. Unlike other pated changes.
    [Show full text]
  • An Implementation of Lola-2 Or Translating from Lola to Verilog
    An Implementation of Lola-2 or Translating from Lola to Verilog N.Wirth, 30.11.2014 1. Introduction The hardware description language Lola (Logic Language) was designed in 1990 as an effort to present a simple and effective textual description of digital circuits. At that time, the conventional style was still graphical (circuit charts), and it was not evident that textual descriptions would replace them entirely within 20 years. Also, there were no means available to automatically transfer them into physical circuits of electronic components. However, field-programmable gate arrays (FPGA) appeared, and although they were far too restrictive (small) for most practical purposes, they seemed to be a promising gateway towards introducing textual specifications with the hope of future automatic generation of real circuits. That this hope was well-founded is now evident. The difficult part of implementation in 1990 was not the compilation of the textual descriptions into net lists of gates and wires. It was rather the placement of components and routing of wires. And this still remains so. But even if this task is achieved, the compiled output is to be down-loaded into the FPGA. For this purpose, the format of the data, the bit-stream format, must be known. Whereas at the time we obtained this information from two FPGA manufacturers, it is now strictly proprietary in the case of the dominating manufacturers, a severe case of interface secrecy. In the course of reviving activities of 25 years ago around Oberon, also the hardware description language (HDL) Lola reappeared. Now textual descriptions of hardware are common place, the preferred languages being Verilog and VHDL.
    [Show full text]
  • A Language for Parametrised and Reconfigurable Hardware Design
    Pebble: A Language For Parametrised and Reconfigurable Hardware Design Wayne Luk and Steve McKeever Department of Computing, Imperial College, 180 Queen’s Gate, London SW7 2BZ, UK Abstract. Pebble is a simple language designed to improve the pro- ductivity and effectiveness of hardware design. It improves productivity by adopting reusable word-level and bit-level descriptions which can be customised by different parameter values, such as design size and the number of pipeline stages. Such descriptions can be compiled without flattening into various VHDL dialects. Pebble improves design effectiven- ess by supporting optional constraint descriptions, such as placement attributes, at various levels of abstraction; it also supports run-time re- configurable design. We introduce Pebble and the associated tools, and illustrate their application to VHDL library development and reconfigu- rable designs for Field Programmable Gate Arrays (FPGAs). 1 Introduction Many hardware designers recognise that their productivity can be enhanced by reusable designs in the form of library elements, macros, modules or intellectual property cores. These components are developed carefully to ensure that they are efficient, validated and easy to use. Several development systems based on Java [1], Lola [2], C [3], ML [5], VHDL and Ruby [7] have been proposed. While the languages in these systems have their own goals and merits, none seems to meet all our requirements of: 1. having a simple syntax and semantics; 2. allowing a wide range of parameters in design descriptions; 3. providing support for both word-level design and bit-level design; 4. supporting optional constraint descriptions, such as placement attributes, at various levels of abstraction; 5.
    [Show full text]
  • The Zonnon Project: a .NET Language and Compiler Experiment
    The Zonnon Project: A .NET Language and Compiler Experiment Jürg Gutknecht Vladimir Romanov Eugene Zueff Swiss Fed Inst of Technology Moscow State University Swiss Fed Inst of Technology (ETH) Computer Science Department (ETH) Zürich, Switzerland Moscow, Russia Zürich, Switzerland [email protected] [email protected] [email protected] ABSTRACT Zonnon is a new programming language that combines the style and the virtues of the Pascal family with a number of novel programming concepts and constructs. It covers a wide range of programming models from algorithms and data structures to interoperating active objects in a distributed system. In contrast to popular object-oriented languages, Zonnon propagates a symmetric compositional inheritance model. In this paper, we first give a brief overview of the language and then focus on the implementation of the compiler and builder on top of .NET, with a particular emphasis on the use of the MS Common Compiler Infrastructure (CCI). The Zonnon compiler is an interesting showcase for the .NET interoperability platform because it implements a non-trivial but still “natural” mapping from the language’s intrinsic object model to the underlying CLR. Keywords Oberon, Zonnon, Compiler, Common Compiler Infrastructure (CCI), Integration. 1. INTRODUCTION: THE BRIEF CCI and b) to experiment with evolutionary language HISTORY OF THE PROJECT concepts. The notion of active object was taken from the Active Oberon language [Gut01]. In addition, two This is a technical paper presenting and describing new concurrency mechanisms have been added: an the current state of the Zonnon project. Zonnon is an accompanying communication mechanism based on evolution of the Pascal, Modula, Oberon language syntax-oriented protocols , borrowed from the Active line [Wir88].
    [Show full text]
  • MODULA a Language for Modular Multiprogramming, Wirth, 1976
    Research Collection Report MODULA a language for modular multiprogramming Author(s): Wirth, Niklaus Publication Date: 1976 Permanent Link: https://doi.org/10.3929/ethz-a-000199440 Rights / License: In Copyright - Non-Commercial Use Permitted This page was generated automatically upon download from the ETH Zurich Research Collection. For more information please consult the Terms of use. ETH Library ~ idgenöss · ische ·Institut T echnisc ~he für. Hochschule Informatik Zürich MODULA: A language formodular multiprogramming ~~8rz 1976 18 ~ ., ' , „· Eidgenössische Institut Technische für Hochschule Informatik Zürich Niklaus Wirth MODULA: A language formodular multiprogramming - 1 - N .Wirth Abstract This paper defines a language called Modula, which is intended primarily for programming dedicated computer systems, including process control systems on smaller machines. The language is largely based on Pascal, but in addition to conventional block ) structure it introduces a so - called module structure . A module is a set of procedures, data types, and variables, where the programmer has precise control over the names that are imported from and exported to the environment. Modula includes general multiprocessing facilities, namely processes , interfacp, modules, and Signals . It also allows the specification of facilities that represent a computer ' s specific peripheral devices . Those given in this paper pertain to the PDP - 11. Author ' s address: Institut für Informatik , ETH , CH-8092 Zürich - 2 - Coaten ts 1. Introduction 3 2. 0 verview 5 3. Notation for syotactic description 10 4. Language vocabulary and representation 10 5. Facilities for sequential programmiog 12 1. Constant declarations 12 2. Type declarations 12 1 • Basic types 13 2. E n um e ratio n s 13 3.
    [Show full text]
  • Mexican Sentimiento and Gender Politics A
    UNIVERSITY OF CALIFORNIA Los Angeles Corporealities of Feeling: Mexican Sentimiento and Gender Politics A dissertation submitted in partial satisfaction of the requirements for the degree Doctor of Philosophy in Culture and Performance by Lorena Alvarado 2012 © Copyright by Lorena Alvarado 2012 ABSTRACT OF THE DISSERTATION Corporealities of Feeling: Mexican Sentimiento and Gender Politics by Lorena Alvarado Doctor of Philosophy in Culture and Performance University of California, Los Angeles, 2011 Professor Alicia Arrizón, co-chair Professor Susan Leigh Foster, co-chair This dissertation examines the cultural and political significance of sentimiento, the emotionally charged delivery of song in ranchera genre musical performance. Briefly stated, sentimiento entails a singer’s fervent portrayal of emotions, including heartache, yearning, and hope, a skillfully achieved depiction that incites extraordinary communication between artist and audience. Adopting a feminist perspective, my work is attentive to the elements of nationalism, gender and sexuality connected to the performance of sentimiento, especially considering the genre’s historic association with patriotism and hypermasculinity. I trace the logic that associates representations of feeling with nation-based pathology and feminine emotional excess and deposits this stigmatized surplus of affect onto the singing body, particularly that of the mexicana female singing body. In this context, sentimiento is represented in film, promotional material, and other mediating devices as a bodily inscription of personal and gendered tragedy, ii as the manifestation of exotic suffering, or as an ancestral and racial condition of melancholy. I examine the work of three ranchera performers that corroborate these claims: Lucha Reyes (1906-1944), Chavela Vargas (1919) and Lila Downs (1964).
    [Show full text]
  • Bjarne Stroustrup
    Bjarne Stroustrup 52 Riverside Dr. #6A +1 979 219 5004 NY, NY 10024 [email protected] USA www.stroustrup.com Education Ph.D. in Computer Science, University of Cambridge, England, 1979 Ph.D. Thesis: Communication and Control in Distributed Computer Systems Thesis advisor: David Wheeler Cand.Scient. in Mathematics with Computer Science, Aarhus University, Denmark, 1975 Thesis advisor: Brian H. Mayoh Research Interests Distributed Systems, Design, Programming techniques, Software development tools, and Programming Languages Professional Experience Technical Fellow, Morgan Stanley, New York, January 2019 – present Managing Director, Division of Technology and Data, Morgan Stanley, New York, January 2014 – present Visiting Professor, Columbia University, New York, January 2014 – present Visiting Professor in the Computer Lab and Fellow of Churchill College, Cambridge University, Spring 2012 Visiting Professor in the Computer Science Department, Princeton University, Fall 2011 The College of Engineering Chair Professor in Computer Science, Department of Computer Science, Texas A&M University, October 2002 – January 2014 Department Head, AT&T Laboratories – Research, Florham Park, New Jersey, July 1995 – October 2002 Distinguished Member of Technical Staff, AT&T Bell Laboratories, Murray Hill, NJ, June 1987 – July 1995 Member of Technical Staff, AT&T Bell Laboratories, Murray Hill, NJ, March 1979 – June 1987 Honors & Awards 2019: Honorary doctor of University Carlos III in Madrid, Spain. 1 2018: The John Scott Legacy Medal and Premium from The Franklin Institute and the City Council of Philadelphia to men and women whose inventions improved the comfort, welfare, and happiness of human kind in a significant way. 2018: The Computer Pioneer Award from The IEEE Computer Society For bringing object- oriented programming and generic programming to the mainstream with his design and implementation of the C++ programming language.
    [Show full text]
  • LOLA: Runtime Monitoring of Synchronous Systems
    LOLA: Runtime Monitoring of Synchronous Systems Ben D’Angelo ∗ Sriram Sankaranarayanan ∗ Cesar´ Sanchez´ ∗ Will Robinson ∗ Bernd Finkbeiner y Henny B. Sipma ∗ Sandeep Mehrotra z Zohar Manna ∗ ∗ Computer Science Department, Stanford University, Stanford, CA 94305 fbdangelo,srirams,cesar,sipma,[email protected] y Department of Computer Science, Saarland University z Synopsys, Inc. [email protected] Abstract— We present a specification language and algo- the specification. Offline monitoring is critical for testing rithms for the online and offline monitoring of synchronous large systems before deployment. An online monitor systems including circuits and embedded systems. Such processes the system trace while it is being generated. monitoring is useful not only for testing, but also under Online monitoring is used to detect violations of the actual deployment. The specification language is simple specification when the system is in operation so that and expressive; it can describe both correctness/failure assertions along with interesting statistical measures that they can be handled before they translate into observable are useful for system profiling and coverage analysis. and cascading failures, and to adaptively optimize system The algorithm for online monitoring of queries in this performance. language follows a partial evaluation strategy: it incre- Runtime monitoring has received growing attention in mentally constructs output streams from input streams, recent years [1], [2], [3]. While static verification intends while maintaining a store of partially evaluated expressions to show that every (infinite) run of a system satisfies for forward references. We identify a class of specifica- the specification, runtime monitoring is concerned only tions, characterized syntactically, for which the algorithm’s with a single (finite) trace.
    [Show full text]
  • Awards Handbook
    AWARDS HANDBOOK Recognizing Technical Achievement and Service Revised October 2011 IEEE COMPUTER SOCIETY AWARDS HANDBOOK Recognizing Technical Achievement and Service October 2011 For further information about the Awards Program contact the Awards Administrator at IEEE Computer Society 2001 L Street N.W., Suite 700 Washington, DC 20036-4928 Phone: (202) 371-0101 Fax: (202) 728-9614 [email protected] Table of Contents 1. INTRODUCTION ............................................................................... 1 2. AWARDS COMMITTEE STRUCTURE AND RESPONSIBILITIES 2.1 Awards Committee Membership ............................................. 2 2.2 Awards Subcommittees ........................................................... 2 2.3 Awards Committee General Responsibilities .......................... 3 2.4 Nomination Solicitations .......................................................... 3 2.5 Confidentiality of Nominees' Identities and Committee Deliberations ............................................................................ 3 2.6 Conflict of Interest .................................................................... 4 2.7 Awards Handbook ................................................................... 4 2.8 Publicity for Granted Awards ................................................... 4 3. ADMINISTRATION OF AWARDS 3.1 Who May Nominate? ............................................................... 5 3.2 How To Nominate .................................................................... 5 3.3 Schedule of Nomination
    [Show full text]
  • The People Who Invented the Internet Source: Wikipedia's History of the Internet
    The People Who Invented the Internet Source: Wikipedia's History of the Internet PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 22 Sep 2012 02:49:54 UTC Contents Articles History of the Internet 1 Barry Appelman 26 Paul Baran 28 Vint Cerf 33 Danny Cohen (engineer) 41 David D. Clark 44 Steve Crocker 45 Donald Davies 47 Douglas Engelbart 49 Charles M. Herzfeld 56 Internet Engineering Task Force 58 Bob Kahn 61 Peter T. Kirstein 65 Leonard Kleinrock 66 John Klensin 70 J. C. R. Licklider 71 Jon Postel 77 Louis Pouzin 80 Lawrence Roberts (scientist) 81 John Romkey 84 Ivan Sutherland 85 Robert Taylor (computer scientist) 89 Ray Tomlinson 92 Oleg Vishnepolsky 94 Phil Zimmermann 96 References Article Sources and Contributors 99 Image Sources, Licenses and Contributors 102 Article Licenses License 103 History of the Internet 1 History of the Internet The history of the Internet began with the development of electronic computers in the 1950s. This began with point-to-point communication between mainframe computers and terminals, expanded to point-to-point connections between computers and then early research into packet switching. Packet switched networks such as ARPANET, Mark I at NPL in the UK, CYCLADES, Merit Network, Tymnet, and Telenet, were developed in the late 1960s and early 1970s using a variety of protocols. The ARPANET in particular led to the development of protocols for internetworking, where multiple separate networks could be joined together into a network of networks. In 1982 the Internet Protocol Suite (TCP/IP) was standardized and the concept of a world-wide network of fully interconnected TCP/IP networks called the Internet was introduced.
    [Show full text]