Showing papers in "IEEE Computer in 1982"

Why systolic architectures

Abstract: f High-performance, special-purpose computer systems are typically used to meet specific application requirements or to off-load computations that are especially taxing to general-purpose computers. As hardware cost and size continue to drop and processing requirements become well-understood in areas such as signal and image processing, more special-purpose systems are being constructed. However, since most of these systems are built on an ad hoc basis for specific tasks, methodological work in this area is rare. Because the knowledge gaited from individual experiences is neither accumulated nor properly organized, the same errors are repeated. I/O and computation imbalance is a notable example-often, the fact that I/O interfaces cannot keep up with device speed is discovered only after constructing a high-speed, special-purpose device. We intend to help correct this ad hoc approach by providing a general guideline-specifically, the concept of systolic architecture, a general methodology for mapping high-level computations into hardware structures. In a systolic system, data flows from the computer memcory in a rhythmic fashion, passing through many processing elements before it returns to memory, much as blood circulates to and from the heart. The system works like an autombbile assembly line where different people work on the same car at different times and many cars are assembled simultaneously. An assembly line is always linear, however, and systolic systems are sometimes two-dimensional. They can be rectangular, triangular, or hexagonal to make use of higher degrees of parallelism. Moreover, to implement a variety of computations, data flow in a systolic system may be at multiple speeds in multiple directions-both inputs and (partial) results flow, whereas only results flow in classical pipelined systems. Generally speaking, a systolic system is easy to implement because of its regularity and easy to reconfigure (to meet various outside constraints) because of its modularity. The systolic architectural concept was developed at Carnegie-Mellon University,'17 and versions of systolic processors are being designed and built by several industrial and governmental organizations.840 This article reviews the basic principle of systolic architectures and explains why they should result in cost-effective, highperformance special-purpose systems for a wide range of problems.

Introduction to the configurable, highly parallel computer

Abstract: When von Neumann computers were still new and exciting, scientists noted in popular accounts that unlike mechanical devices, computers are polymorphic-their function can be radically changed simply by changing programs. Polymorphism is fundamental, but this familiar and obvious fact receives little mention any more, even though it underlies important advances such as time-sharing and programmable microcode. Now, however, as we are confronted with the potential for highly parallel computers made possible by very-largescale integrated circuit technology, we may ask: What is the role of polymorphism in parallel computation? To answer this question, we must review the characteristics of parallel processing and the benefits and limitations of VLSI technology.

A vlsi risc

Abstract: A general trend in computers today is to increase the complexity of architectures commensurate with the increasing potential of implementation technologies, as exemplified by the complex successors of simpler machines. Compare, for example, the DEC VAX-11 to the PDP-1 1, the IBM System/382 to the System/3, and the Intel iAPX-4323'4 to the 8086. The complexity of this class of computers, which we call CISCs for complex instruction set computers, has some negative consequences: increased design time, increased design errors, and inconsistent implementations.5 Investigations of VLSI architectures indicate that the delay-power penalty of data transfers across chip boundaries and the still-limited resources (devices) available on a single chip are major design limitations. Even a million-transistor chip is insufficient if a whole computer has to be built from it.6 This raises the question of whether the extra hardware needed to implement a CISC is the best use of \"scarce\" resources. The above findings led to the Reduced Instruction Set Computer Project. The purpose of the RISC Project is to explore alternatives to the general trend toward architectural complexity. The hypothesis is that by reducing the instruction set one can design a suitable VLSI architecture that uses scarce resources more effectively than a CISC. We also expect this approach to reduce design time, design errors, and the execution time of individual instructions. Our initial version of such a computer is called RISC I. To meet our goals of simplicity and effective single-chip implementation, we somewhat artificially placed the following design constraints on the architecture: (1) Execute one instruction per cycle. RISC I instructions should be about as fast and no more complicated than microinstructions in current machines such as the PDP-ll or VAX. (2) Make all instructions the same size. This again simplifies implementation. We intentionally postponed attempts to reduce program size. (3) Access memory only with load and store instructions ; the rest operate between registers. This restriction simplifies the design. The lack of complex addressing modes also makes it easier to restart instructions. (4) Support high-level languages. The degree of support is explained below. Our intent is to optimize the performance of RISC I for use with high-level languages. RISC I supports 32-bit addresses, 8-, 16-, and 32-bit data, and several 32-bit registers. We intend to examine support for operating systems and floating-point calculations in the future. It would appear that these constraints, based on our desire for simplicity and regularity, …

Heuristic Models of Task Assignment Scheduling in Distributed Systems

Abstract: When confronted with the need to utilize a remote computer facility or a data base that does not exist in a local computer system, a user looks to distributed processing. Distributed processing not only solves the above problems, it can also increase processing speed by providing facilities for parallel execution. Furthermore, its interconnected set of mini-or microprocessors is flexible, efficient, reliable, modular, and (comparatively) inexpensive. Distributed processing applications can be found in large networks covering a number of computing centers and also in small signal-processing systems. When referring to any of these systems in this article, I call the processing elements simply \"processors\" and use the term \"task\" for programs or other kinds of code units submitted to a system. Although there are related areas of research in distributed processing environments, including file allocation and processor scheduling, this article concentrates on the problem of task allocation management. The purpose of task allocation scheduling in a set of interconnected processors is to reduce job turnaround time. This is done by maximizing the utilization of resources while mimimizing any communication between processors. No access conflicts arise from a shared memory (as in a multiple processing system) because every processor is assumed to have its own working area. The benefits of task allocation scheduling make distributed processing desirable, but several problems must be solved before they can be realized. For example, when the number of processors in a system increases beyond a certain level, throughput decreases.1 This \"saturation ef-fect\" can be simply explained: If there are n processors in the system and if each has a processing speed of k, then one would expect the speed of the system to be n x k. In reality, however, a lower processing speed results, caused by such factors as control overheads, communication between processors, unbalanced loading, queueing delays, and the precedence order of the parts of a task assigned to separate processors. In order to eliminate or minimize saturation, these inhibiting factors must also be eliminated or minimized. First, a fast, dynamic assignment algorithm can be used to attack the control overhead problem. Additionally, load distribution must be provided for a system as a means of balancing and minimizing both interprocessor communications (IPC) and queueing delays. Since, in reality, any system's resources are limited, the effect of limited memory size in each processor on saturation must also be considered, as must response time. Response time …

Data Flow Languages

Abstract: The author states that in a data flow language, locality of effect is easily achieved. But obtaining freedom from side effects requires a fundamental alteration in the execution model of the language. 34 references.

Data Flow Program Graphs

Abstract: The advantages of each are discussed here. fi Data Flow Program Graphs Data flow languages form a subclass of the languages which are based primarily upon function application (i.e., applicative languages). By data flow language we mean any applicative language based entirely upon the notion of data flowing from one function entity to another or any language that directly supports such flowing. This flow concept gives data flow languages the advantage of allowing program definitions to be represented exclusively by graphs. Graphical representations and their applications are the subject of this article. Applicative languages provide the benefits of extreme modularity, in that the function of each of several sub-programs that execute concurrently can be understood in vacuo. Therefore, the programmer need not assimilate a great deal of information about the environment of the subprogram in order to understand it. In these languages, there is no way to express constructs that produce global side-effects. This decoupling of the meaning of individual subprograms also makes possible a similar decoupling of their execution. Thus, when represented graphically, sub-programs that look independent can be executed independently and, therefore, concurrently. By contrast, concurrent programs written in more conventional assignment-based languages cannot always be understood in vacuo, since it is often necessary to understand complex sequences of interactions between a sub-program and its environment in order to understand the meaning of the subprogram itself. This is not to say that data flow subprograms cannot interact with their environments in specialized ways, but that it is possible to define a subprogram's meaning without appealing to those interactions. There are many reasons for describing data flow languages in graphical representations, including the following: (1) Data flow languages sequence program actions by a simple data availability firing rule: When a node's arguments are available, it is said to be firable. The function associated with a firable node can be fired, i.e., applied to is arguments, which are thereby absorbed. After firing, the node's results are sent to other functions, which need these results as their arguments. A mental image of this behavior is suggested by representing the program as a directed graph in which each node represents a function and each (directed) arc a conceptual medium over which data items flow. Phantom nodes, drawn with dashed lines, indicate points at which the program communicates with its environment by either receiving data from it or sending data to it. (2) …

Highly concurrent computing structures for matrix arithmetic and signal processing

Abstract: Computational complexity has traditionally been an important measure of the utility of digital signal processing and matrix arithmetic algorithms; however, the digital implementation of such algorithms has often been difficult (or impossible) since they tend to be computebound. Consequently, the quest for real-time processing has resulted in a concerted push for the development of faster computing structures as well as algorithms oflower computational complexity. With the advent of VLSI, many processing elements can now be realized on a single chip, and large collections of processors have therefore become economically feasible. In this article, we present the reader with several highly concurrent, pipelined computing structuresstructures that are realizable in VLSI and that exhibit large throughputs. Although the architectures we describe are introduced through the use of specific examples, they are also applicable to the solution of a variety of other problems. There are three primary reasons why general-purpose uniprocessor computers, especially microcomputers, have met with only limited success in the high-speed signal processing arena. First, they cannot, in general, efficiently compute a variety of elementary operations such as multiplication, vector rotation, and trigonometric functions; these operations are quite common im matrix arithmetic and signal processing algorithms. Second, generalpurpose computer architectures provide only cumbersome address arithmetic for data structures, such as circular buffers, that occur frequently in high-speed signal processing applications (communications, for example). And lastly, with one notable exception, signal processing algorithms exhibit a substantial amount of parallelism that is not effectively exploited in a uniprocessor system. (The exception is the AMD2900 family, which allows some parallelism through the extensive use of two-port RAMs.) Our article will primarily be concerned with architectures that exploit parallelism and that are based on powerful primitive operations. Most signal processing structures, whether parallel or not, tend to emphasize the need for fast multiplication.' However, algorithms for matrix arithmetic and signal processing call for a somewhat larger set of elementary operations: real and complex number multiplications, additions, square roots, divisions, trigonometric functions and their inverses, and, somewhat less often, hyperbolic transformations. For example, the discrete Fourier transform and the matrix decomposition via Givens' rotations demand 2 x 2 plane rotations, while matrix triangular factorization can be performed with 2 x 2 hyperbolic rotations, divisions, and square roots. Multiplications and additions are awkward to use for the generation of these general operations. However, J. E. Volder2 has introduced powerful algorithms named Cordic, for coordinate rotation digital computer, that evaluate a variety of plane coordinate transformations with iterative procedures involving only additions and shift operations at each step, In other words, Cordic processing elements are extremely simple and quite compact to realize, while being no slower than the bit serial multipliers widely proposed for VLSI array structures.3,4 Many of the more complex signal processing tasks and applications, such as statistical analysis and linear and nonlinear programming, rely on standard matrix computations. The basic problem in matrix arithmetic, for which a large number of direct and iterative schemes have been devised, is the solution of linear systems ofequations (and the closely related problem of matrix inversion). A rapid survey of direct methods of solution indicates that Givens' procedure is the method-of-choice from the VLSI implementation standpoint because it can be efficiently

Measuring Curved Surfaces for Robot Vision

Abstract: A new industrial revolution is in the making, produced by a marriage of two versatile technologies, the computer and the robot. This combination of control and manipulation produces a machine with enormous potential for performing useful tasks-yet such potential has not been fully realized. One way to improve the capabilities of current industrial robots is to add visual sensors. Robots that are deaf or dumb or that have no sense of force or touch perform only manually trainable tasks that can be dangerous in some working environments. Many applications call for an \"intelligent\" robot, a stand-alone machine-usually with its own visual, contact, or auditory sensory perception system-that can detect changes in its work environment and adapt to them. Such a detection process requires a large number of computations on the sensory data to distinguish features, recognize patterns, or compare input data with logical expectations. With the low cost of microprocessors and the increasing use of dedicated computers, intelligent systems for robots are becoming more and more sophisticated,\"2 and we have no shortage of potential applications: sensorybased robots can be used in space exploration, deep-sea mining, and industrial automation, for example.3'4 Computer vision, the collection of techniques, software, and hardware for measurements and inferences from images,3,6 appears to offer the richest source of sensory information for intelligent robotic manipulation in the greatest number of environments. A simple computer vision system usually consists of an image-processing unit interfaced with a minicomputer or mainframe,' but many kinds of systems are available, some for as little as $5000.8 However, most of these are low-level processing systems,9\"10 consisting of image acquisition, edge detection, feature extraction, template matching, and object recognition.* High-level processing is time consuming, since it requires a lot of computation. Nevertheless, image-processing algorithms can be implemented on minicomputers or mainframes.'3 In fact, imaging devices have been widely used in many automated visual inspection systems to perform pattern recognition and image processing for a specific task.'4\"l5 This article describes a technique that uses a recorded image of a projected pattern to measure 3-D surface points on simple, curved objects. The measured points are then fit to a quadric surface equation from which location, orientation, and surface recognition are extracted. For many man-made objects, this extracted information is sufficient to permit a robot hand to pick up the object, and results indicate that curved, featureless objects can be located.

The U-Interpreter

Abstract: The usual method of interpreting data flow graphs assumes a finite token capacity (usually one) on each arc. This unnecessarily limits the amount of parallelism that can be easily exploited in a program. The U-interpreter is a method for assigning labels to each computational activity as it is dynamically generated during program execution. The U-interpreter assigns and manipulates labels in a totally distributed manner, thus avoiding a sequential controller, which can be a bottleneck in the design of large multiple-processor machines.

A Second Opinion on Data Flow Machines and Languages

Abstract: The authors argue that due to their simplicity and strong appeal to intuition, data flow techniques attract a great deal of attention. Other alternatives, however, offer more hope for the future. 25 references.

Evolution of the Ethernet Local Computer Network

Abstract: The Ethernet system is a local computer network that supports high-speed packet switching in a locally distributed computing environment. This paper highlights some important elements of the basic system, and traces the evolution of the design from a research prototype to the specification of a multi-company standard. Starting from the Experimental Ethernet, we discuss tradeoffs among alternative implementations and design strategies which led to the Ethernet Specification. A concise summary of the Ethernet Specification is also included. CR Categories: 3.81.

A Practical Data Flow Computer

Abstract: Based on a tagged dynamic data flow model, this prototype machine has eight unusual matching functions for handling incoming data tokens at its computational nodes. 10 references.

Testing and Fault Tolerance of Multistage Interconnection Networks

Abstract: Test length is independent of network size in this simple, straightforward methodology for testing MINs (multistage interconnection networks). It requires only four test sequences for single-fault diagnosis. 26 references.

A survey of highly parallel computing

Abstract: It is no accident that the set of mental and physical processes used by a designer working in a particular medium is called a design discipline. Something about the human mind tends to define a design medium in terms of its constraints, its limits. From the writing of haiku* to the design of new computers, designers tend to think in terms of a limiting structural framework to which their design must adhere. Consequently, when evolving style or advancing technology removes some of these constraints, designers often react with as much consternation as joy. The discipline ofcomputer architecture is now in such a transitional period. The advent of VLSI and very recently developed automated design tools have removed a fundamental constraint from computer architecture. Computer designers are no longer rigidly bound by the cost of processing logic. An obvious result is that the von Neumann paradigm for computer design, in which a single CPU operates serially on data items that it serially fetches from and restores to memory, is obsolete for computationally demanding tasks. The designer can now attack problems that once were computationally intractable by implementing systems in which thousands or even tens of thousands of processors cooperate to solve a single problem. A highly parallel structure has three main characteristics:

A Comparative Study of Robot Languages

Abstract: Efficient communication with industrial robots is a key factor in the success of contemporary programmable automation, but robot languages-the means of communication-have commonly been developed in an ad hoc manner to meet the needs of a particular robot and application. Thus, we currently have almost as many robot languages as robots. To formulate recommendations for an efficient robot language of the future, this article reviews and evaluates many of the RLs now in use or under development in industrial or academic environments. Table I compares the industrial robots for which the languages were developed, and Table 2 contains background information on the 14 selected languages, * which are identified below.

A Unix-Based Local Computer Network with Load Balancing

Abstract: Many of today's computers run with Bell Laboratories' Unix operating system, including the DEC PDP-1 1 and VAX series, Interdata 8/32, and Honeywell 6000.1(2 At least 5000 Unix systems are currently in operation, as compared with approximately 1000 such systems at the end of 1978. The need for linking these systems into networks has focused attention on such technical problem areas as communication protocols and Unix extensions, as well as load-balancing methods. The problems arising from networking can be better understood in the context of the design and operational experiences associated with one particular Unix network-the Purdue Engineering Computer Network. Of particular interest in the ECN are the load-balancing strategies embedded in its system software. Additional light can be shed on these topics by comparing the Purdue ECN with other Unix networks in terms of network configurations, protocols, and capabilities. Two types of Unix networks have been developed in industrial and academic environments: the dial-up Unix network,3 developed at Bell Laboratories using telephone lines linking more than 80 minicomputers, and the hardwired Unix networks. Data communications through the dial-up network's leased telephone lines are slow, with a rate of 300 baud or 1200 baud. Hardwired Unix networks, however, which use dedicated links between the host computers, feature much higher data transmission ratesrates ranging up to severalM baud. The Purdue ECN4,5 is

Computer Vision Techniques for Industrial Applications and Robot Control

Abstract: robots that \"see\" and \"feel\" can perform more complex tasks, industry has employed various computer vision techniques to enhance the abilities of intelligent machines. The recent widespread interest in robotics and automation in the US originates from American industry's most fundamental problem: a staggering drop in productivity. From 1947 to 1965, US productivity increased at an average rate of 3.4 percent a year. The growth rate decreased to 2.3 percent in the following decade, then dropped to below one percent in the late 1970's and down to-0.9 percent in 1980. Japan's productivity growth, the contrasting example most often cited in the literature, has been climbing at an average annual rate of about 7.3 percent. ' Although there are many ways to influence manufacturing productivity and product quality-regulatory, fiscal, and social-the emphasis in the following discussion is technological. In particular, we are interested in the computer vision aspects of industrial inspection and robot control. The principal motivation behind computer vision is increased flexibility and lower cost. The use of sensing technology to endow-a machine with a greater degree of \"intelligence\" in dealing with its environment is receiving increased attention. A robot that can \"see\" and \"feel\" should be easier to train in the performance of complex tasks while at the same time requiring less stringent control mechanisms than preprogrammed machines. A sensory, trainable system is also adaptable to a much larger variety of tasks, thus achieving a degree of universality that ultimately translates into lower production and maintenance costs. The computer vision process can be divided into five principal areas: sensing, segmentation, description, recognition , and interpretation. These categories are suggested to a large extent by the way computer vision systems are generally implemented. It is not implied that human vision and reasoning can be so neatly subdivided nor that these processes are carried out independently of each other. For instance, we can logically assume that recognition and interpretation are highly interrelated functions in a human. These relationships, however, are not yet understood to the point where they can be mod-eled analytically. Thus, the subdivision of functions discussed below can be viewed as a practical (albeit limited) approach for implementing state-of-the-art computer vision systems, given our level of understanding and the analytical tools currently available in this field. Visual sensing Imaging devices. Visual information is converted to electrical signals by visual sensors. The most commonly used visual sensors are vidicon cameras …

Data Flow Systems: Guest Editors' Introduction

Abstract: Some 15 years ago, J. Rodriguez at MITI and D. Adams at Stanford2 began to work on research that eventually led to the development of concepts still in use today in data flow systems. Important advances have been made since that time, and many researchers are now investigating data flow concepts as an alternative to von Neumann machines and languages. Nevertheless, until this special issue of Computer, no attempt had been made to bring together a body of work on data flow systems and closely examine just how far research into this technology has progressed. In the pages that follow, the reader will be presented with an overview of the field, especially as it relates to high-speed computing. Included are articles by leading researchers in the field of data flow languages and graphs, and dynamic architectures. There is also an article that outlines the major problems with data flow systems from the point of view of experts who are not directly active in data flow research. Together, we hope these articles will stimulate further investigation into the practicality of data flow systems. Anyone with some background in computer languages and architecture, and with a rudimentary knowledge of compilers should find the material in this issue most interesting.

Virtual Memory Management in the VAX/VMS Operating System

Abstract: The VAX-i 1/780, introduced in 1978, and the smaller VAX11/750, introduced in 1980, are Digital Equipment Corporation's first implementations of the 32-bit VAX-II minicomputer architecture.' Eventually, there will be a family of VAX-I I minicomputers. The VAX-I I and its VAX/VMS operating system were designed to provide extended address space and enhanced performance for Digital's PDP11 customers. Built on Digital's experience with a multitude of PDP-11 operating systems, VAX/VMS was intended to provide a single environment for all VAX-based applications, whether realtime, timeshared (including program development), or batch. In addition, VAX/VMS had to operateon a family of processors having different performance characteristics and physical memory capacities ranging from 250K bytes to more than 8M bytes. To meet the requirements posed by these applications environments, the memory management system had to be capable of adjusting to the changing demands characteristic of timesharing while allowing the predictable performance required by realtime and batch processes. Memory management policies and decisions made in the design and implementation of the first release of the VAX/VMS operating system in 1978 reflected the concerns of the developers. This article examines those concerns and the mechanisms selected to deal with them.

The Design of a Family of Application-Oriented Requirements Languages

Abstract: The purpose of a requirements specification is to describe a product's behavior at an early stage of its development life cycle. The specifications document should describe what the product should do, not how it does it. This specification is read in detail by the product's prospective users for their approval and by the product's designers so that they can better understand what they are designing and implementing. The customer or his representative is typically an expert in a particular application (e.g., medicine, telephony, nuclear reactor controls), and the designer is typically an expert in systems, software, and hardware engineering. These differences in audience background and interests constitute a major dilemma for the requirements writer. In what language shall the requirements specification document be written? Technical English is ideal for the customer but is inherently ambiguous. Moreover, English documents cannot be subjected to rigorous computer processing to determine inconsistencies. On the other hand, a formal computer language is ideal for designers who are accustomed to reading large, formal, dry documents. As an added advantage , requirements written in formal languages can be processed by computer-based requirements analyzers. Unfortunately, formal documents are not suitable for customers unfamiliar with the format, syntax, and semantics present in these documents. One solution to this dilemma is the definition of application-specific formal requirements languages. Each language is \"formal\" in that it possesses a unique, well-defined, and documented syntax and semantics. Each one, however, is also tailored to a particular application area and thus is rich in the terminology peculiar to that area. This article first discusses the various alternatives to application-oriented requirements languages. It then describes a class of application-oriented requirements languages suitable for the specification of real-time systems and discusses a computer program that can automatically check requirements documents written in these languages for the presence of ambiguity and inconsistency. The alternatives Much research has been performed in the design of specification languages. Each research effort has resulted in one or more languages having varying degrees of formality (i.e., suitability for computer processing) and readability. Figure I shows these two properties on a two-dimensional grid. As each alternative is explored, it will be described in terms of this grid to show how the language relates to other languages. As the richness of the language and its methodology increases , while its formality remains consistently high, increased \"processibility\" can be achieved. For example,

Rochester's intelligent gateway

Abstract: The University of Rochester has had several years experience in the design and implementation of a multiple-machine, multiple-network distributed system called RIG, or Rochester's Intelligent Gateway. RIG was designed as a state-of-the-art research computing environment to support a variety of distributed applications and research in distributed computing. Particular applications include computer image analysis and design automation for VLSI. Distributed systems research includes investigations into internetwork architectures, interpro-cess communication, naming, distributed file systems, distributed control, performance monitoring, exception handling, debugging, and user interfaces. RIG was designed for a collection of heterogeneous machines, interconnected by networks of varying characteristics. It represents one of the earliest and most comprehensive attempts at designing a distributed operating system and supporting network architecture from the ground up. Various aspects of the system have been presented in a number of papers. 1-10 The first half of this article will present a brief overview that is a slight idealiza-tion of the current implementation, described elsewhere, 8 and differs in several significant ways from our original notions of the system goals and design.2 The last half will emphasize qualitative and quantitative experimental results. RIG basics Hardware. The hardware environment consists of a number of local-net-based workstations connected to back-end file servers, databases, and large-scale computing resources. In particular, RIG interconnects three networks via a dual-processor gateway (see Figure 1). The bulk of the user's computational requirements are met by timesharing systems such as DEC-10/TOPS-10 and VAX/Unix, and personal computers such as Xerox Altos-16-bit minicomputers with 606 x 808 frame-buffer raster-scan displays.\"1 The Altos, gateway machines (Data General Eclipses), and VAX are connected via an Ethernet.12 The DEC-10 (campus network) communicates with the gateway over 9600-baud asyn-chronous and 50-kHz synchronous lines. The gateway is connected to the Arpanet as a very distant host via a 50-kHz synchronous line. Together, the gateway machines support a variety of devices: a color graphics display processor, a tape drive, an electrostatic printer-plotter, a drum scanner, various display terminals, and 900M bytes of primary disk storage. While providing access to remote computer systems, the gateway machines also support a number of basic program development services such as printing, plotting, local file storage, and text editing. In addition, they provide boot service facilities for the Altos, allowing them to be downloaded with programs stored on the gateway file system. Moreover, the gateway file system provides a central clearinghouse for RIG source files; thus, programs developed on …

An Architectural Trail to Threaded-Code Systems

Abstract: Interest in software systems based on threaded-code concepts has grown remarkably in recent years. Advocates of such systems regularly make claims for them that many classical programmers regard as bordering on the impossible. Typically, proponents claim that it is possible to construct, in 5K to 10K bytes of code, a software package that * is conversational like APL, Lisp, or Basic; * includes a compile facility with many high-order language, structured-programming constructs; * exhibits performance very close to that of machine-coded program equivalents; * is written largely in itself and consequently is largely portable; * places no barriers among combinations of system, compiler, or application code; * can include an integrated, user-controlled virtual memory system for source text and data files; * permits easy user definition of new data types and structures; and * can be extended to include new commands written either in terms of existing commands or in the underlying machine language (an assembler for the underlying machine can be implemented in as little as a page of text of existing commands). Such systems do exist-Forth is perhaps the best known-and have attracted widespread attention, as evidenced by countless implementations, publications, products, and standards groups. The purpose of this article is to convince the skeptic that these claims are, in fact, achievable without resorting to obscure software magic or arm-waving. The approach is to build a logical (not historical) trail from some rather simple concepts to the outlines of a software system that meets the above claims. A series of generalizations added to a simple view of software leads to the final result, a package approaching the combination of * a simple instruction-set architecture, or ISA; * the concepts and syntax of a high-order language, or HOL; and * a set of commands for a conversational monitor. The ISA (such as it is) is for an abstract machine that is very efficiently implemented by short code segments in almost any current machine architecture. The HOL concepts include hierarchical construction of programs, block structures, GOTOless programming, and user-definable data structures. The commands for the conversational monitor permit direct interaction with objects defined by the programmer in terms he defines, not simply in the terms of the underlying machine (i.e., core dumps). Further, the command set is directly executable in a conversational mode and includes virtually all commands available in the system; when so executed, they function just as they …

Reliability issues for fully replicated distributed databases

Abstract: Reliability is commonly considered to be one of the main advantages of distributed databases, but there are problems that must be overcome before it can be achieved. Exactly what is reliability? There are many types of failures, and we should know which types the system will be protected against. It is also necessary to define how the system will react to those failures. A considerable number of special protocols must be implemented with great care in order to realize the desired level of reliability. The purpose of this article is to discuss the design alternatives and problems that must be solved in order to make a completely replicated distributed database reliable. A distributed database is completely replicated if a copy of the value of any data item is stored at every node (or site) in the system. A completely replicated distributed database is a special case of a general distributed database, and there are several reasons for studying the reliability issues in this limited context: (1) Complete replication simplifies the problems. Making a distributed database reliable is not a simple matter, so as a first step we can try to understand a simplified specific case. (2) Replicated data is the key to making data available after failures, so we will actually be concentrating on the critical component of distributed databases. (3) Transaction processing (with no failures) in a completely replicated distributed database is well understood and a good number of papers have been written on the subject. 1-5 Most of the research for reliable distributed databases has been performed in the context of particular transaction processing algorithms. (There are exceptions, however .6'7) This means that only the alternatives best suited to the transaction processing algorithm are considered. In this article this will be avoided by not advocating a particular transaction processing algorithm. A person designing a reliable distributed database is faced with a set of choices. Here these choices are divided into seven broad categories and each category will be discussed in one of the following sections. For each choice that must be made by the designer, I will attempt to give the major alternatives available and then list the implications of these alternatives. Many of the mechanisms for reliable distributed databases that we will discuss have been presented in the literature. I would like to caution the reader that my division of choices is somewhat arbitrary and that the …

Japan's Fifth Generation Computer Systems

Abstract: Until now, the Japanese computer industry has aimed at catching up with the US, especially IBM, in computer technology. The result is that three Japanese companies (Fujitsu, Hitachi, and NEC) now claim to offer equivalent computers that are faster than IBM's. In fact, the Japanese computer industry is presently setting its sights on surpassing the rest of the world,la and it sees as its opportunity the growing \"technology gulf\" between the traditional sequential, control-flow computer and intended application areas such as distributed computing, office automation, and artificial intelligence. All of this is creating the belief that the next generation of computers will have a different theoretical foundation from traditional computers.

The Cm* Testbed

Abstract: Interest in multiprocessor architecture has grown steadily over the past ten to fifteen years. With VLSI technology we can build multiprocessors that are substantially larger than present computers to solve problems that cannot be solved today. Yet despite the substantial number of multiprocessor designs, only a few multiprocessors have been built with a high degree of parallelism, say thirty or more processors. Although multiprocessors appear to have cost/performance and reliability benefits, the computing community has relatively little experience in their actual use. Consequently, little is known about how well the potential of multiprocessors can be realized, which is exactly the thrust of the Cm* research project. We can view a distributed system as being composed of an architectural component and a behavioral component. The first component consists of hardware, firmware, and software elements, and the relationships between them. The behavioral component is characterized by the way the architecture acts in the presence of a workload. The architectural component should be flexible, and the behavioral component should provide a controllable and measurable behavior. These two characteristics are embodied in the Cm* testbed, which has a programmable interconnection network for hardware-architecture flexibility. The two operating systems StarOS and Medusa provide adaptable mechanisms and policies for running experiments with application programs. The workload, the measurement tools, and the experimentation control are integrated into an experimentation environment, which complements the other support programs such as compilers and loaders with facilities for specifying, monitoring, and analyzing experiments. TheCm * project has successfully constructed a 50-processor multiprocessor and two operating systems, thus demonstrating the feasibility of several aspects of multiprocessing. In this article we describe not only Cm* hardware and software but also experimental results, how well various algorithm structures exploit the potential parallelism of the Cm*, and the results of extended measurements on the hardware itself.

Development Support Systems

Abstract: It may once have been true that engineers were very successful in automating every job except their own, but the situation has changed rapidly in recent years. Development support systems now automate engineering activities which can be performed better and more cheaply by computers than by people. Today, engineering is becoming more attractive and satisfying because \"slave\" tasks, such as establishing documentation, can be done by computer , and the advent of workbench systems to support the development process will further impact engineering work, changing not only the habits of the individual engineer but also the structure and function of companies and educational institutions. But there are still many difficulties associated with the development of computer software and hardware systems. For example: * The \"engineeringware\" to specify, design, implement , test, and maintain such systems is costly, time consuming, and difficult to manage. * Computer software and hardware are often non-responsive to user requirements. * More often than not, the documentation proves to be inconsistent and incomplete. * System reliability and integrity may be jeopardized by modifications and changes made during the development process. These difficulties may be overcome, at least in part, through automation of engineering activities. Terms defined. By development we mean all engineering activities, whether related to hardware and software or their operation and use, that are needed to create a man-machine system and keep it operating. As shown in Figure 1, there are two phases of system development. The predelivery phase is usually divided into five stages: requirements analysis, system specification, design, implementation and coding, and test and integration. The postdelivery phase comprises not only maintenance in the usual sense (error and failure diagnosis and repair) but also, more importantly, the enhancement of the system and its adaptation to new environments. This phase, in which the stages of requirements analysis, specification, design, implementation and coding, and test and integration are iterated several times,1 could be renamed the \"evolution phase.\" The man-machine system to be developed may be, for example, a distributed microcomputer system in which software, processors, peripheral hardware, sensors, ac-tuators, and human operators interact to control an industrial process. There are two ways in which a computer can aid the developer. One is to build software tools that support specific activities. Such tools might include an assembler, a text editor, a program to generate the layout for a printed circuit board, or a check-out program. …