Introduction a Brief History of Computing
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
COM 113 INTRO to COMPUTER PROGRAMMING Theory Book
1 [Type the document title] UNESCO -NIGERIA TECHNICAL & VOCATIONAL EDUCATION REVITALISATION PROJECT -PHASE II NATIONAL DIPLOMA IN COMPUTER TECHNOLOGY Computer Programming COURSE CODE: COM113 YEAR I - SE MESTER I THEORY Version 1: December 2008 2 [Type the document title] Table of Contents WEEK 1 Concept of programming ................................................................................................................ 6 Features of a good computer program ............................................................................................ 7 System Development Cycle ............................................................................................................ 9 WEEK 2 Concept of Algorithm ................................................................................................................... 11 Features of an Algorithm .............................................................................................................. 11 Methods of Representing Algorithm ............................................................................................ 11 Pseudo code .................................................................................................................................. 12 WEEK 3 English-like form .......................................................................................................................... 15 Flowchart ..................................................................................................................................... -
"Bob" Schreiner
Oral History of Robert “Bob” Schreiner Interviewed by: Stephen Diamond Recorded: June 10, 2013 Mountain View, California CHM Reference number: X6873.2014 © 2013 Computer History Museum Oral History of Robert “Bob” Schreiner Stephen Diamond: We're here at the Computer History Museum with Bob Schreiner. It's June 10th, 2013, and we're going to talk about the oral history of Synertek and the 6502. Welcome, Bob. Thanks for being here. Can you introduce yourself to us? Robert “Bob” Schreiner: Okay. My name is Bob Schreiner. I'm an ex-Fairchilder, one of the Fairchildren in the valley, and then involved in running a couple of other small semiconductor companies, and I started a semiconductor company. Diamond: So that would be Synertek. Schreiner: Synertek. Diamond: Tell us about that. Schreiner: Okay. As you know from an earlier session I left Fairchild Semiconductor around 1971. And at the time I left I was running the LSI program at Fairchild, and I was a big believer that the future marketplace for MOS technology would be in the custom area. And since Fairchild let that whole thing fall apart, I decided there's got to be room for a company to start up to do that very thing, work with big producers of hardware and develop custom chips for them so they would have a propriety product that would be difficult to copy. So I wrote a business plan, and I went around to a number of manufacturers. I had a computer guy [General Automation], and I had Bulova Watch Company, and I had a company that made electronic telephones [American Telephones], and who was the fourth guy? Escapes my memory right now, but the pitch basically was, "Your business, which now you manufacture things with discrete components, it's going to change. -
Microprocessors History of Computing Nouf Assaid
MICROPROCESSORS HISTORY OF COMPUTING NOUF ASSAID 1 Table of Contents Introduction 2 Brief History 2 Microprocessors 7 Instruction Set Architectures 8 Von Neumann Machine 9 Microprocessor Design 12 Superscalar 13 RISC 16 CISC 20 VLIW 23 Multiprocessor 24 Future Trends in Microprocessor Design 25 2 Introduction If we take a look around us, we would be sure to find a device that uses a microprocessor in some form or the other. Microprocessors have become a part of our daily lives and it would be difficult to imagine life without them today. From digital wrist watches, to pocket calculators, from microwaves, to cars, toys, security systems, navigation, to credit cards, microprocessors are ubiquitous. All this has been made possible by remarkable developments in semiconductor technology enabling in the last 30 years, enabling the implementation of ideas that were previously beyond the average computer architect’s grasp. In this paper, we discuss the various microprocessor technologies, starting with a brief history of computing. This is followed by an in-depth look at processor architecture, design philosophies, current design trends, RISC processors and CISC processors. Finally we discuss trends and directions in microprocessor design. Brief Historical Overview Mechanical Computers A French engineer by the name of Blaise Pascal built the first working mechanical computer. This device was made completely from gears and was operated using hand cranks. This machine was capable of simple addition and subtraction, but a few years later, a German mathematician by the name of Leibniz made a similar machine that could multiply and divide as well. After about 150 years, a mathematician at Cambridge, Charles Babbage made his Difference Engine. -
Analytical Engine, 1838 ALLAN G
Charles Babbage’s Analytical Engine, 1838 ALLAN G. BROMLEY Charles Babbage commenced work on the design of the Analytical Engine in 1834 following the collapse of the project to build the Difference Engine. His ideas evolved rapidly, and by 1838 most of the important concepts used in his later designs were established. This paper introduces the design of the Analytical Engine as it stood in early 1838, concentrating on the overall functional organization of the mill (or central processing portion) and the methods generally used for the basic arithmetic operations of multiplication, division, and signed addition. The paper describes the working of the mechanisms that Babbage devised for storing, transferring, and adding numbers and how they were organized together by the “microprogrammed” control system; the paper also introduces the facilities provided for user- level programming. The intention of the paper is to show that an automatic computing machine could be built using mechanical devices, and that Babbage’s designs provide both an effective set of basic mechanisms and a workable organization of a complete machine. Categories and Subject Descriptors: K.2 [History of Computing]- C. Babbage, hardware, software General Terms: Design Additional Key Words and Phrases: Analytical Engine 1. Introduction 1838. During this period Babbage appears to have made no attempt to construct the Analytical Engine, Charles Babbage commenced work on the design of but preferred the unfettered intellectual exploration of the Analytical Engine shortly after the collapse in 1833 the concepts he was evolving. of the lo-year project to build the Difference Engine. After 1849 Babbage ceased designing calculating He was at the time 42 years o1d.l devices. -
2.2 Adaptive Routing Algorithms and Router Design 20
https://theses.gla.ac.uk/ Theses Digitisation: https://www.gla.ac.uk/myglasgow/research/enlighten/theses/digitisation/ This is a digitised version of the original print thesis. Copyright and moral rights for this work are retained by the author A copy can be downloaded for personal non-commercial research or study, without prior permission or charge This work cannot be reproduced or quoted extensively from without first obtaining permission in writing from the author The content must not be changed in any way or sold commercially in any format or medium without the formal permission of the author When referring to this work, full bibliographic details including the author, title, awarding institution and date of the thesis must be given Enlighten: Theses https://theses.gla.ac.uk/ [email protected] Performance Evaluation of Distributed Crossbar Switch Hypermesh Sarnia Loucif Dissertation Submitted for the Degree of Doctor of Philosophy to the Faculty of Science, Glasgow University. ©Sarnia Loucif, May 1999. ProQuest Number: 10391444 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a com plete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. uest ProQuest 10391444 Published by ProQuest LLO (2017). Copyright of the Dissertation is held by the Author. All rights reserved. This work is protected against unauthorized copying under Title 17, United States C ode Microform Edition © ProQuest LLO. ProQuest LLO. -
Defining Computer Program Parts Under Learned Hand's Abstractions Test in Software Copyright Infringement Cases
Michigan Law Review Volume 91 Issue 3 1992 Defining Computer Program Parts Under Learned Hand's Abstractions Test in Software Copyright Infringement Cases John W.L. Ogilive University of Michigan Law School Follow this and additional works at: https://repository.law.umich.edu/mlr Part of the Computer Law Commons, Intellectual Property Law Commons, and the Judges Commons Recommended Citation John W. Ogilive, Defining Computer Program Parts Under Learned Hand's Abstractions Test in Software Copyright Infringement Cases, 91 MICH. L. REV. 526 (1992). Available at: https://repository.law.umich.edu/mlr/vol91/iss3/5 This Note is brought to you for free and open access by the Michigan Law Review at University of Michigan Law School Scholarship Repository. It has been accepted for inclusion in Michigan Law Review by an authorized editor of University of Michigan Law School Scholarship Repository. For more information, please contact [email protected]. NOTE Defining Computer Program Parts Under Learned Hand's Abstractions Test in Software Copyright Infringement Cases John W.L. Ogilvie INTRODUCTION Although computer programs enjoy copyright protection as pro tectable "literary works" under the federal copyright statute, 1 the case law governing software infringement is confused, inconsistent, and even unintelligible to those who must interpret it.2 A computer pro gram is often viewed as a collection of different parts, just as a book or play is seen as an amalgamation of plot, characters, and other familiar parts. However, different courts recognize vastly different computer program parts for copyright infringement purposes. 3 Much of the dis array in software copyright law stems from mutually incompatible and conclusory program part definitions that bear no relation to how a computer program is actually designed and created. -
Adaptive Parallelism for Coupled, Multithreaded Message-Passing Programs Samuel K
University of New Mexico UNM Digital Repository Computer Science ETDs Engineering ETDs Fall 12-1-2018 Adaptive Parallelism for Coupled, Multithreaded Message-Passing Programs Samuel K. Gutiérrez Follow this and additional works at: https://digitalrepository.unm.edu/cs_etds Part of the Numerical Analysis and Scientific omputC ing Commons, OS and Networks Commons, Software Engineering Commons, and the Systems Architecture Commons Recommended Citation Gutiérrez, Samuel K.. "Adaptive Parallelism for Coupled, Multithreaded Message-Passing Programs." (2018). https://digitalrepository.unm.edu/cs_etds/95 This Dissertation is brought to you for free and open access by the Engineering ETDs at UNM Digital Repository. It has been accepted for inclusion in Computer Science ETDs by an authorized administrator of UNM Digital Repository. For more information, please contact [email protected]. Samuel Keith Guti´errez Candidate Computer Science Department This dissertation is approved, and it is acceptable in quality and form for publication: Approved by the Dissertation Committee: Professor Dorian C. Arnold, Chair Professor Patrick G. Bridges Professor Darko Stefanovic Professor Alexander S. Aiken Patrick S. McCormick Adaptive Parallelism for Coupled, Multithreaded Message-Passing Programs by Samuel Keith Guti´errez B.S., Computer Science, New Mexico Highlands University, 2006 M.S., Computer Science, University of New Mexico, 2009 DISSERTATION Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy Computer Science The University of New Mexico Albuquerque, New Mexico December 2018 ii ©2018, Samuel Keith Guti´errez iii Dedication To my beloved family iv \A Dios rogando y con el martillo dando." Unknown v Acknowledgments Words cannot adequately express my feelings of gratitude for the people that made this possible. -
Detecting False Sharing Efficiently and Effectively
W&M ScholarWorks Arts & Sciences Articles Arts and Sciences 2016 Cheetah: Detecting False Sharing Efficiently andff E ectively Tongping Liu Univ Texas San Antonio, Dept Comp Sci, San Antonio, TX 78249 USA; Xu Liu Coll William & Mary, Dept Comp Sci, Williamsburg, VA 23185 USA Follow this and additional works at: https://scholarworks.wm.edu/aspubs Recommended Citation Liu, T., & Liu, X. (2016, March). Cheetah: Detecting false sharing efficiently and effectively. In 2016 IEEE/ ACM International Symposium on Code Generation and Optimization (CGO) (pp. 1-11). IEEE. This Article is brought to you for free and open access by the Arts and Sciences at W&M ScholarWorks. It has been accepted for inclusion in Arts & Sciences Articles by an authorized administrator of W&M ScholarWorks. For more information, please contact [email protected]. Cheetah: Detecting False Sharing Efficiently and Effectively Tongping Liu ∗ Xu Liu ∗ Department of Computer Science Department of Computer Science University of Texas at San Antonio College of William and Mary San Antonio, TX 78249 USA Williamsburg, VA 23185 USA [email protected] [email protected] Abstract 1. Introduction False sharing is a notorious performance problem that may Multicore processors are ubiquitous in the computing spec- occur in multithreaded programs when they are running on trum: from smart phones, personal desktops, to high-end ubiquitous multicore hardware. It can dramatically degrade servers. Multithreading is the de-facto programming model the performance by up to an order of magnitude, significantly to exploit the massive parallelism of modern multicore archi- hurting the scalability. Identifying false sharing in complex tectures. -
Language Translators
Student Notes Theory LANGUAGE TRANSLATORS A. HIGH AND LOW LEVEL LANGUAGES Programming languages Low – Level Languages High-Level Languages Example: Assembly Language Example: Pascal, Basic, Java Characteristics of LOW Level Languages: They are machine oriented : an assembly language program written for one machine will not work on any other type of machine unless they happen to use the same processor chip. Each assembly language statement generally translates into one machine code instruction, therefore the program becomes long and time-consuming to create. Example: 10100101 01110001 LDA &71 01101001 00000001 ADD #&01 10000101 01110001 STA &71 Characteristics of HIGH Level Languages: They are not machine oriented: in theory they are portable , meaning that a program written for one machine will run on any other machine for which the appropriate compiler or interpreter is available. They are problem oriented: most high level languages have structures and facilities appropriate to a particular use or type of problem. For example, FORTRAN was developed for use in solving mathematical problems. Some languages, such as PASCAL were developed as general-purpose languages. Statements in high-level languages usually resemble English sentences or mathematical expressions and these languages tend to be easier to learn and understand than assembly language. Each statement in a high level language will be translated into several machine code instructions. Example: number:= number + 1; 10100101 01110001 01101001 00000001 10000101 01110001 B. GENERATIONS OF PROGRAMMING LANGUAGES 4th generation 4GLs 3rd generation High Level Languages 2nd generation Low-level Languages 1st generation Machine Code Page 1 of 5 K Aquilina Student Notes Theory 1. MACHINE LANGUAGE – 1ST GENERATION In the early days of computer programming all programs had to be written in machine code. -
Leaper: a Learned Prefetcher for Cache Invalidation in LSM-Tree Based Storage Engines
Leaper: A Learned Prefetcher for Cache Invalidation in LSM-tree based Storage Engines ∗ Lei Yang1 , Hong Wu2, Tieying Zhang2, Xuntao Cheng2, Feifei Li2, Lei Zou1, Yujie Wang2, Rongyao Chen2, Jianying Wang2, and Gui Huang2 fyang lei, [email protected] fhong.wu, tieying.zhang, xuntao.cxt, lifeifei, zhencheng.wyj, rongyao.cry, beilou.wjy, [email protected] Peking University1 Alibaba Group2 ABSTRACT 101 Hit ratio Frequency-based cache replacement policies that work well QPS on page-based database storage engines are no longer suffi- Latency cient for the emerging LSM-tree (Log-Structure Merge-tree) based storage engines. Due to the append-only and copy- 100 on-write techniques applied to accelerate writes, the state- of-the-art LSM-tree adopts mutable record blocks and issues Normalized value frequent background operations (i.e., compaction, flush) to reorganize records in possibly every block. As a side-effect, 0 50 100 150 200 such operations invalidate the corresponding entries in the Time (s) Figure 1: Cache hit ratio and system performance churn (QPS cache for each involved record, causing sudden drops on the and latency of 95th percentile) caused by cache invalidations. cache hit rates and spikes on access latency. Given the ob- with notable examples including LevelDB [10], HBase [2], servation that existing methods cannot address this cache RocksDB [7] and X-Engine [14] for its superior write perfor- invalidation problem, we propose Leaper, a machine learn- mance. These storage engines usually come with row-level ing method to predict hot records in an LSM-tree storage and block-level caches to buffer hot records in main mem- engine and prefetch them into the cache without being dis- ory. -
CSC 256/456: Operating Systems
CSC 256/456: Operating Systems Multiprocessor John Criswell Support University of Rochester 1 Outline ❖ Multiprocessor hardware ❖ Types of multi-processor workloads ❖ Operating system issues ❖ Where to run the kernel ❖ Synchronization ❖ Where to run processes 2 Multiprocessor Hardware 3 Multiprocessor Hardware ❖ System in which two or more CPUs share full access to the main memory ❖ Each CPU might have its own cache and the coherence among multiple caches is maintained CPU CPU … … … CPU Cache Cache Cache Memory bus Memory 4 Multi-core Processor ❖ Multiple processors on “chip” ❖ Some caches shared CPU CPU ❖ Some not shared Cache Cache Shared Cache Memory Bus 5 Hyper-Threading ❖ Replicate parts of processor; share other parts ❖ Create illusion that one core is two cores CPU Core Fetch Unit Decode ALU MemUnit Fetch Unit Decode 6 Cache Coherency ❖ Ensure processors not operating with stale memory data ❖ Writes send out cache invalidation messages CPU CPU … … … CPU Cache Cache Cache Memory bus Memory 7 Non Uniform Memory Access (NUMA) ❖ Memory clustered around CPUs ❖ For a given CPU ❖ Some memory is nearby (and fast) ❖ Other memory is far away (and slow) 8 Multiprocessor Workloads 9 Multiprogramming ❖ Non-cooperating processes with no communication ❖ Examples ❖ Time-sharing systems ❖ Multi-tasking single-user operating systems ❖ make -j<very large number here> 10 Concurrent Servers ❖ Minimal communication between processes and threads ❖ Throughput usually the goal ❖ Examples ❖ Web servers ❖ Database servers 11 Parallel Programs ❖ Use parallelism -
13. Stored-Program Computers
13. Stored-Program Computers 13.1 Introduction This chapter concentrates on the low-level usage and structure of stored program computers. We focus on a particular hypothetical machine known as the ISC, describing its programming in assembly language. We show how recursion and switch statements are compiled into machine language, and how memory-mapped overlapped I/O is achieved. We also show the logic implement of the ISC, in terms of registers, buses, and finite-state machine controllers. 13.2 Programmer's Abstraction for a Stored-Program Computer By stored-program computer, we mean a machine in which the program, as well as the data, are stored in memory, each word of which can be accessed in uniform time. Most of the high-level language programming the reader has done will likely have used this kind of computer implicitly. However, the program that is stored is not high-level language text. If it were, then it would be necessary to constantly parse this text, which would slow down execution immensely. Instead one of two other forms of storage is used: An abstract syntax representation of the program could be stored. The identifiers in this representation are pre-translated, and the structure is traversed dynamically as needed during execution. This is the approach used by an interpreter for the language. A second approach is to use a compiler for the language. The compiler translates the program into the very low-level language native to the machine, appropriately called machine language. The native machine language acts as a least-common-denominator language for the computer.