Fundamentals of Computer Architecture and Organization -- Article Index + Introduction

Contents:

Introduction (below)

I. From software to hardware

1. Computation

2. Software engineering

3. Machine language

II. From switches to processors

4. Data representation and notation

5. Element level

6. Component level

7. Control units

III. From components to systems

8. Processor organization

9. System organization

10. Survey of modern processor architecture

Introduction

Motivation / philosophy

One does not undertake the task of composing a new guide lightly. This one has taken more than a year to produce. Furthermore, it does not make the author rich. (It pays better working in a bar!) So why bother? Having moved to a computer science department from an applied physics environment, I was somewhat shocked at just how little students had been expected to learn, or even care, about the physical nature and engineering of the machines themselves. When I arrived at the University of Oxford, courses in computer architecture were new to the computer science curriculum in most US and UK universities. On searching for a text suitable for students, who perceived their machines from a purely software perspective, I found two serious problems.

First, almost all were written primarily for students of electrical engineering and so devoted too much space to engineering topics and presumed too great a knowledge of electrical theory. Second, all too often they were devoted to one or other "favorite" machine and lacked breadth. It also proved impossible to locate one which comprehensively covered new innovative ideas, such as…

• Reduced instruction set

• Register windowing

• Modular software support

• Concurrent software support

In particular I felt that the architecture of the Transputer could not be ignored because of the degree of its innovation and the fact that it renders parallel computing accessible and affordable, even to the individual.

As a result of the absence of a suitable text I felt myself duty bound to attempt the production of one. At the highest level my intention was to produce, not a "bible" on the subject, but a course text, containing sufficient material to provide a solid introduction but not so much as to overwhelm. It is intended as support for self-contained introductory courses in computer architecture, computer organization and digital systems. A detailed table of contents and substantial index should facilitate random "dipping in". Occasionally material is duplicated between sections to reduce the amount of cross-referencing necessary. An italic font is used for emphasis. A slanted one is used to indicate an important term upon its first use (within the current section or sub-section) and also to highlight itemized lists.

It seems worthwhile to mention some points of philosophy underlying the guide. The current computer science curriculum is a mix of science, technology and engineering, although this seems to be changing as the field matures. (New degree programs in computer systems engineering, as distinct from computer science, are becoming commonplace.) I have attempted to emphasize the ideas fundamental to technology and engineering. These include top-down design and an analyze/design/implement/verify sequential structure to the design process. It seemed to me important to divorce digital systems from the implementation technology to be employed. I believe that a digital computer should be understood independent of whether it is constructed with electrical, optical, mechanical or even pneumatic switches. As a result space has been devoted to explaining the switch level of organization. In summary, the following levels are considered…

• Switch

• Element (Gate, flip-flop)

• Component (Register, ALU, counter, shift-register etc.)

• Processor

The distinction between mainframe, mini and micro computers has been considered irrelevant to an introductory course or text. VLSI technology is in any case blurring the boundaries. I have intentionally omitted any treatment of highly complex designs in order to concentrate on fundamental ideas and their exploitation. More can be learned from simpler examples. The Transputer and Berkeley RISC have shown how simplification can defeat increased complexity.

Scientists simplify, engineers complicate! The programming model assumed as a default is that of the procedure since procedural languages are currently most commonly taught first to students of computer science. Buckingham has opted for Modula-2. In addition the process +message passing model is used when discussing concurrency support.

"Architecture" is taken to mean those features of the machine which a programmer needs to know, such as programmer's architecture, instruction set and addressing modes. "Organization" is taken to mean all features which give rise to the characteristic behavior and performance of the machine and/or the way in which its components are connected together. The distinction between the two definitions is not adhered to with absolute rigidity.

The new ANSI/IEEE standard logic symbols are not employed since it is felt that the traditional ones are easier to learn, make simple systems more clear and are still in widespread use. The new symbols are clearly intended to simplify the representation of integrated devices, particularly for use in computer-aided design. To introduce both would only serve to confuse.

Lastly, only the final section depends on any particular design. This is not a guide devoted to any favorite machine. The three which are discussed have been chosen purely for reasons of illustration.

To summarize, this guide differs from others on the same subject as follows…

• Better support for students of computer science

• No dependence upon any particular machine

• High digital systems content

• Up-to-date coverage of new issues including…

- Modular software support

- Concurrency support

• Up-to-date coverage of new features including…

- Reduced instruction set

- Register windowing

- Synchronous channels (hard & soft) Content and course correspondence

The guide is divided into three parts…

Part I: From software to hardware is intended to introduce the software oriented student to the fundamental ideas of physical computation. It begins with a section devoted to defining new terminology and describing fundamental concepts such as that of time-discrete system, process and protocol. Section 2 offers a summary of the basic ideas of software engineering and introduces some of the ideas fundamental to the engineering design process. Section 3 outlines the implementation of the building blocks of a structured program at the primitive (or atomic) level and includes a contrast of the RISC versus CISC design philosophies in the context of their efficiency at implementing statements in a high level procedural programming language.

Part II: From switches to processors covers more than the required ground needed in digital systems. It includes treatment of design techniques for both combinational and sequential systems. Also finding a home here are Section 4, which discusses data representation and notation, and Section 7, which discusses the nature and design of both hardwired and microcoded processor control units.

Part III: From components to systems seeks to show how components may be organized to form central and communication processors and memory units.

Section 8 covers processor architecture and organization, discussing accumulator, stack and register file designs. Discussion of the use of register files extends to include register windowing and its effect on the procedure call overhead. It also discusses a "queue+channel" machine, designed to support the scheduling of concurrent processes and the synchronous communication of messages between them. Section 9 deals with both internal and external communication and memory organization. Finally, Section 10 gives an overview of the architecture of three contemporary processors, the Motorola 68000, National Semiconductor 32000 and the Inmos Transputer. A particularly thorough discussion of the Transputer is given because of the extent and importance of its innovation and because a student accessible treatment does not yet appear to be available elsewhere.

More than two hundred diagrams serve to illustrate ideas in the text. Every picture is worth a thousand words…and took as long to produce! Also more than forty exercises are given , together with complete solutions. These are intended as supplementary material for the student, not to save the course tutor effort! (I have never understood the point of including exercises without solutions in a guide.) Most references used are to currently available textbooks. Those made to journal papers are restricted to "landmark" expositions.

The course at Buckingham is supplemented with assembly language programming experience. Apart from two lectures on assembly language translation and programming tools, the course follows the guide except for somewhat reduced coverage of digital systems design and early delivery of material from Section 10 on the machine to be programmed, (currently the NS32000).

Material on assembly language programming and tools is deliberately omitted for two reasons. First, it requires a particular machine which should be chosen partly on the basis of practical experience and available equipment. Neither of these factors should influence the content of a textbook. Secondly, an alternative possibility is that a full course on compilers might include material and practical experience of code generation and its relationship to architecture design.

Teaching assembly language programming is arguably not the best way to introduce students to machine implementation of constructs and procedure invocation, etc.. It totally bypasses the problem of automatic generation of code and its implications for architecture design.

Knowledge of a fully structured procedural programming language is the only pre-requisite. The level of mathematical skill and knowledge required varies throughout the guide. Introductions are included to propositional logic, Boolean algebra and computer arithmetic which are adequate for their use within the guide. Knowledge of data structures, modular software engineering, parallel processing and Occam would be beneficial but not essential.

The IEEE Computer Society Model Program in Computer Science and Engineering, [IEEE CS 83], calls for the following related core curriculum subject areas to be supported by lecture courses. The degree of overlap with the topics chosen for this text is shown below…

----

----

The approach taken in this guide differs from the recommendations. Many more additional topics are treated than are left out. Overlap at the module level may not mean exact correspondence to topics within. Treatment of alternatives, of equivalent merit, within a module is considered sufficient. For example in Subject area eight/module three: "Computer architecture survey" a different collection of machines will be found to that in Section 8.

It was never the intention to match the guide to part of any preconceived curriculum. Course syllabus should be a matter for the course tutor. We hope very much that the text proves useful to others who share the experience of that responsibility.

PREV. | NEXT

Related Articles -- Top of Page -- Home