Search

Shared-memory multiprocessors to support concurrent languages for general-purpose multitasked systems are analyzed. To solve the traditional performance problems caused by memory access latency and conflicts, extensive caching of instructions and data is performed in each processor mode. Caches are private to each processor, and coherence is maintained in hardware between the caches. To maintain a good efficiency, several contexts are resident in each processor. On a miss in the cache, a microswitch to another resident context is operated by changing the program counter and a pointer in the register memory. The instruction set of each processor is RISC-like, so that a microswitch should waste few machine cycles. The proposed system has high efficiency, even when the number of processors increases and when the coherence overhead and conflicts are high. Models are developed to evaluate throughput and efficiency.

This note describes RED, a remotely executed debugger capable of generating a real-time source level trace history of a high level language program executing on a microprocessor. The trace history consists of a display of the source statements of each basic block executed, annotated by the time at which execution of that block began. Basic blocks are traced rather than statements to reduce sampling bandwidth requirements while still retaining the ability to record the essential logical flow of programs. RED is intended to assist in debugging stand-alone high level language process control programs with real-time constraints. We outline two possible implementation schemes for generating the real-time trace history. In both, a "debugging co-processor" collects in a history buffer the values of the program counter (PC) and the corresponding value of a clock as each basic block begins execution. The debugger, which runs on the processor hosting the compiler and has access to the co-processor over a fast link, reconstructs a source level trace from the PC-time pairs in the history buffer. In one scheme, the language compiler emits an extra instruction at the beginning of each basic block in the program to output the value of the program counter to a parallel port connected to the debug processor. The second method makes use of an extended target memory space to provide tag bits denoting basic blocks. When an instruction is fetched, the debug processor detects the presence of the tag bits and buffers up the value of the corresponding program counter and time. The first method is simpler to implement, requiring only conventional, usually straightforward hardware additions to the target, but requires the execution overhead of the extra instructions. In both cases the debugger itself runs on the host processor and has access to tables generated during compile time of the source program.

An instruction issue system is described, developed for application in microcomputer design in order to minimize the data transmission expense between storage and cpu , and thus reducing hardware costs. It consists of a program storage module endowed with some processing capabilities, and an intermediate sequential storage system for the instructions integrated into the cpu . The instruction address transfers are totally eliminated by the provision of distributed logic for instruction preinterpretation, program address counting, and subprogram return address administration within the program memory. After the recognition of conditional branches, two alternative instruction sequences are prefetched, and sent to the cpu , where they, as well as short program loops, are entered into specially designed intermediate local memories. From there the instructions are then issued for execution. The savings of internal transfers yielded by the architecture are finally established.

Microcomputers, like large-scale computer systems, can benefit from executive routines which can interrupt a running program, save the program and its environment on a disk, and later reload the program and resume execution at the point of interruption. The process is discussed conceptually, and the specific routines for accomplishing the tasks in a North Star DOS environment are presented and documented.

Computers employing some degree of data flow organisation are now well established as providing a possible vehicle for concurrent computation. Although data-driven computation frees the architecture from the constraints of the single program counter, processor and global memory, inherent in the classic von Neumann computer, there can still be problems with the unconstrained generation of fresh result tokens if a pure data flow approach is adopted. The advantages of allowing serial processing for those parts of a program which are inherently serial, and of permitting a demand-driven, as well as data-driven, mode of operation are identified and described. The MUSE machine described here is a structured architecture supporting both serial and parallel processing which allows the abstract structure of a program to be mapped onto the machine in a logical way.

This paper describes a system that accepts compact specifications of an intermediate code and target machine and produces program code for an integrated code generator and peephole optimizer. A compiler for most of C uses this packa.ge. It emits code comparable to PCCI’S, but it runs over five times faster on preliminary benchmarks. This compiler also runs over twice as fast as a version of pcc2 with a hand-coded, VAX-specific code generator. The code generators are produced as follows. A programmer describes a naive code generator by means of a non-procedural specification. The programmer also prepares a machine description for a retargetable peephole optimizer [2]. These two systems are used together to compile a testbed, and the compiler records each peephole optimization as it is made. This record and the specification of the naive code generator are compiled into a fast, integrated code generator and optimizer. This production code generator then takes the place of the slower “training” version. The production code generator and optimizer are integrated to the point that the code to be generated is communicated from one to the other by encoding it in the program counter, which obviates most inter-phase communication costs. Interpretive peephole optimizers have been driven by traces from retargetable peephole optimizers [3] and integrated with interpretive code generators [4], but the current work is distinguished by the production of a hard-coded, optimizing code generator. Historically, retargetable code generators (i.e., those not largely rewritten for each new machine)

Important features and capabilities of the 80960 are briefly examined, and an overview of its architecture is given. A detached discussion is presented of the register model, core instruction set, register operations, memory operations, control operations instruction cache, user-supervisor protection, interrupts, faults, and debug support. >

Design, internal structure, implementation experience and a number of unique features of the SAMPLER/3000 performance evaluation tool are presented. This package can be used to produce program CPU and wait time profiles in several levels of detail in terms of code segments, procedure names and procedure relative addresses. It also provides an accurate profile of the operating systems code which is exercised to service requests from the selective parts of the user code. Programs can be observed under natural load conditions in a single user or shared environment. A program's CPU usage is determined in terms of direct and indirect cost components. The approaches to determine direct and indirect CPU times are described. A program counter sampling technique in virtual memory domain is discussed. Certain interesting aspects of data analysis and on-line data presentation techniques are described. The features of the computer architecture, the services of the loader and compilers which relate to the operation of the tool are discussed. A case study is finally presented.

The sequential concept of computer operation is that a program counter selects the instruction to execute. Locality, memory hierarchies, and program restructuring are wellknown in sequential environments. The dataflow concept of computer operation is that an instruction should execute as soon as its operands are available. Locality, memory hierarchies, and program restructuring can be applied to dataflow environments: both temporal locality and spatial locality may exist, a memory hierarchy is possible and can be effective, and dataflow programs may benefit from program restructuring. This paper presents a synopsis of the implications of locality, a memory hierarchy, and program restructuring as related to dataflow environments.

A 64-subject computer-controlled laboratory for use in research and as a teaching aid is described. The laboratory hardware includes an 8K minicomputer, a 64-channel input multiplexor, and a video display generator. The software includes a complete operating system and an easy-to-use programming language. The entire laboratory, including the computer, was built for under $12,000.

New instruction sets have been based on traditather than on the application of scientific method. Here, the latter has yielded a simple, optimal, en-member instruction set.

This work is a complementary part for what we proposed in [1]. In this paper, an undergraduate design experience for special purpose 4-bit microprocessor using the skills learned from digital logic design and Microprocessors courses is presented. The experience started in [1] by designing the ALU using the hardware printed circuit board and we are following it by completing the design by the instruction set architecture and the microprogram code. Our microprocessor contains – in addition to the ALU- six registers: A 4-bit accumulator register, Flag register that holds only zero (Z) and carry (C) flags, Program counter register (PC), Memory address register (MAR), Instruction register (IR), and Buffer Register. All programs and data are stored in the 1k RAM.

As part of a multi-access system, a facility was developed to assist in the preparation of real-time programs for a specialist application. The multi-access system (GPO, 1970) is located within the Electronic Switching Group GPO Research Station, Dollis Hill. This group is presently engaged on the development of a computer-controlled telephone exchange. As can be imagined, a considerable software effort is involved even in the initial stage, which consists initially of a four-line exchange controlled by a small computer via a data switch. Plans are in hand to test the system simulating much larger traffic. This software comprises the exhange system executive, a large number of operating routines, of the order of 100, and a complex test program used in the development of the data switch and the other pieces of hardware which make up the exchange. Powerful debug facilities were available and it was desired to extend their use to real-time programs. Because of the programming effort required to implement the system for the exchange and also because the system was to be implemented on a small computer, it was necessary to produce initially an operating system that would provide both multiaccess capabilities and comprehensive debug facilities. A further advantage was that it would permit hardware and software development to proceed simultaneously. The first provision is an obvious one since all computing is done in a 'hands-on' situation, i.e. each programmer is allotted time, during which he may assemble, edit or debug his program. Particularly during the last stage, the computer will be idle for appreciable periods during which the programmer cogitates. Multi-access, therefore, is an obvious method of increasing the efficiency of use of the machine, The comprehensive debug facility ensures that the programmer uses his time as efficiently as possible. The small machine concerned was a Honeywell DDP 516 with 32K words of storage. A high speed punch and reader are connected together with two Teletype ASR 33 and one KSR 35. Optional features which are incorporated in the system are memory lock-out and standard and priority interrupt lines. The high speed reader and punch are connected to the standard interrupt line, while the teletype, real-time clocks, data switch and other hardware links are connected to the priority lines. In the Honeywell interrupt system, when an interrupt occurs, it causes the contents of the program counter, which contains the address of the current instruction to be executed, to be automatically changed, thereby changing the sequence of instruction execution. Interrupts have unique memory locations dedicated to them, whose contents are interpreted as an indirect address. The action of an interrupt causes the program to branch to the location whose address is stored in the dedicated location. These dedicated locations are held in the base sector.

In Chapter 1 we described 16-bit microprocessors in a very simplified way, so as to illustrate their basic behavior. The processors that are available on the market show a more complex structure and a higher performance when compared to our model. This is also true for 8-bit microprocessors. Some of the features that allow distinction between 16-bit and 8-bit microprocessors are listed below: longer word length of 16 bits and therefore 16-bit data paths, larger number of data formats (bit, half byte, byte, word, double word, byte string and word string), general purpose register set, longer address with up to 24 bits, larger number of addressing modes, two-address instructions, more powerful instruction set (multiplication and division instructions, instructions for memory management, string and block processing instructions) universal trap and interrupt system, different modes (system mode, user mode), easy change of status, privileged instructions, support for multiprocessor configurations.

Digital methods and techniques for the processing of one/two dimensional signals are considered. Spectral estimation, digital filtering and data compression operations are in particular described. It is shown how digital signal processing operations can be practically performed by means of standard computers (software definition) or by using special type digital processors (hardware definition). The use of recently developed microprocessors and charge-coupled devices is also considered. Some digital processors performing digital filtering and spectral estimation are described in detail, as typical examples. Applications to processing of signals (audio, ECG…) and images (in biomedicine, from earth resource satellites…) are presented.

This chapter provides an introduction to on-line computing, and is intended as a summary of basic concepts to support the rest of the book. The aim is therefore to outline principles, and to describe a few typical examples or applications rather than to provide an extensive review of the literature. Computers now fill a very varied role in most branches of radiochemistry, and applications range from the direct use of computers as instruments (i.e. on-line computing) to complex data manipulation (off-line applications). To provide some coherence in the treatment, the major part of this chapter focusses on gamma-spectrometry and activation methods. An outline is given of the basic principles of multichannel analysers, and a simple account of the operation and programming of a small computer. This is followed by a fairly detailed description of the organisation, operation and use of a small computer as a single gamma-spectrometer, to illustrate techniques, advantages and limitations. Further sections summarise alternative methods of using dedicated computer units, for example for fully automated activation systems, and the use of medium-sized computers for simultaneous operation as several independent gamma-spectrometers. A final section summarises computer applications in some other branches of radiochemistry.

The susceptibility of programmable electronic systems (PES) to electromagnetic interferences (EMI) is known as an actual problem from the point of view of PES safety. At first, some specific aspects are focused on, f.i. those relevant to the programmable electronics of PESs

With the availability of VLSI technology to build supercomputers with a large number of interacting processors, the brain-computer analogy has found a revived interest. The RAM machine by von Neumann, [1] with a global memory for data and programs and with control by a single program counter (which holds the address of the next instruction and is updated in a regular cycle), cannot serve as a useful model for the brain. Much more interesting are parallel computers, where the architecture depends strongly on the algorithms to be performed. The ultracomputer model [2] uses a large number N of identical processors which are locally connected to a few nearest neighbor processors, e.g. in a higher dimensional cubic lattice. Such an architecture has a programming style, in which periods of independent parallel computations alternate with periods of interprocessor communication and data shuffling. For certain problems algorithms can be developed where an N-processor ultracomputer is N times faster than a RAM machine. Such ultracomputers are also structurally very different from the brain. Closest to the brain’s mode of operation is the data flow concept [3].

Having selected or derived the desired digital filter pulse transfer function, G(Z), (see chapter 2 and chapter 3) and, furthermore, having determined the appropriate processor word length (see chapter 4), then the next step is to undertake the implementation of the filter’s linear difference equation corresponding to G(Z). This linear difference equation is used to compute the filter’s output y(n)T values, which will be a filtered version of the filter’s input x(n)T values (see figure 1.1).

In this chapter we shall discuss the target machine properties relevant for code generation, and the mapping of the language-oriented objects and operations onto objects and operations of the target machine. Systematic code generation must, of course, take account of the peculiarities and weaknesses of the target computer’s instruction set. It cannot, however, become bogged down in exploitation of these special idiosyncrasies; the payoff in code efficiency will not cover the implementation cost. Thus the compiler writer endeavors to derive a model of the target machine that is not distorted by exceptions, but is as uniform as possible, to serve as a base for code generator construction. To this end some properties of the hardware may be ignored, or gaps in the instruction set may be filled by subroutine invocations or inline sequences treated as elementary operations. In particular, the instruction set is extended by the operations of a run-time system that interfaces input/output and similar actions to the operating system, and attends to storage management.

One of the difficult tasks of keeping a high speed processor busy is to make sure that it has a constant supply of instructions and to make sure that they are supplied quickly. This requires a very high bandwidth for both instructions and data. For MIPS-X, when both an instruction and data are required, the peak bandwidth required is 160 Mbytes/s. Building a memory system to support this would not be simple and transferring this amount of data across the pins of a VLSI chip would have been difficult with the packaging technology available at the time. MIPS-X uses an on-chip instruction cache to reduce the memory bandwidth requirements. Putting an instruction cache on-chip also makes it possible to fetch new instructions every cycle if the instructions are in the cache.

Educational research in high school classrooms has suggested that students learn better when exposed to instruction which suits their preference with regard to the level of structure in the material(1). A more elaborate educational diagnosis, proposed by John Ginther, takes into account not only the level of structure in the material but the Symbolic, Ikonic or Enactive mode of it’s presentation(2). Thus, there are six possible categories of learner which might benefit by receiving instruction with the level of structure and in the mode of their preference. To test this possibility, one hundred and two patients were randomized into two groups: IIa received instruction matched to the individual’s educational diagnosis, IIb received instruction counter to the educational diagnosis.

In the six year that the PDP-11 has been on the market, more than 20,000 units in 10 different models have been sold. Although one of the original system design goals was a broad range of models, the actual range of 500 to 1 (in cost and memory size) has exceeded the design goals.

Ask 10 people what a computer is, and you will get 10 different answers. But ask those same 10 people how a computer works, and you will get some blank looks. If you are not quite sure how your computer works, now is the time to learn. The better you understand your computer, the better you will use it.

In this paper we consider the use of Petri nets and extensions to describe features of existing architectures. Because the main attraction of Petri nets is in their ability to express synchronization and concurrency, our modelling is directed towards high-performance architectures. In particular, we show models for look-ahead processing schemes and the cache coherence problem.

Designing computers is an art which tries to integrate three separate aspects of the machinery: (1) Need On what problems are computers to be applied? (2) Function What solutions are computers to provide? and (3) Form What parts are computers to be built out of and how are those parts to be connected?

Aim of the paper is to present some details of the PAPIA system design and to describe its Control System hardware implementation.

Current VLSI fabrication technology makes it possible to design a 32-bit CPU on a single chip. However, to achieve high performance from that processor, the architecture and implementation must be carefully designed and tuned. The MIPS processor incorporates some new architectural ideas into a single-chip, nMOS implementation. Processor performance is obtained by the careful integration of the software (e.g., compilers), the architecture, and the hardware implementation. This integrated view also simplifies the design, making it practical to implement the processor at a university.

The CDC 6600, CDC 7600, and IBM 360/91 performed at peak speed when processing highly regular data. Programmers, intent on maximizing performance, optimized inner loops by counting machine cycles to assure that memory and register conflicts were minimized and that pipelines were full. Both manual and compiler techniques were aimed at creating machine code enabling loops to take advantage of the IBM 360/91 hardware’s loop mode. Similar approaches were employed with the CDC 7600. STACKLIB, a collection of subroutines which processed arrays of data, was developed to permit the CDC 7600 to operate at maximum speed. Utilizing tightly coded loops to process vectors of data suggested the development of a hardware implementation.

The instruction set that the MC68000 uses truly makes this device a programmer’s dream. The MC68000 is a processor for the implementation of high-level languages. The “orthogonality” of the processor provides significant assistance to compiler designers.

The HP9000 Series 500 computer uses a fully-integrated 32-bit processing system based on five custom NMOS VLSI circuits that operate at a frequency of 18 MHz. These chips include a 32-bit CPU, an I/O processor, a memory controller, a 128K-bit RAM, and a clock driver (1). The CPU and I/O processor are both microprogrammed. The I/O processor provides a high-performance input/output data path for the system peripherals. The I/O processor handles eight DMA channels and has an I/O bus bandwidth of 5.1M bytes/s when transfering at maximum rate. The memory controller chip can control 256K bytes of RAM and do single-bit error correction and double-bit error detection. A memory controller can map each of 16 16K-byte blocks of memory to its desired position in the address space and can “heal” up to 32 bad memory locations. The 16K x 8-bit RAM chip has redundant rows and columns for yield improvement and can handle pipelined memory accesses. The clock chip generates two nonoverlapping 18 MHz clock signals from a 36 MHz sine wave. A clock chip is used with each CPU, 1/0 processor, and memory controller/RAM subsystem.

This chapter provides an overview of Zilog Z8000 Family (16-BIT). The Zilog Z8000 series of 16-bit devices includes several central processing units (CPUs), with differing capacities for memory support (including virtual memory), and several support devices. These support devices include powerful input/ output handling chips and coprocessors, for example, floating point hardware chip. There are two principal CPUs, which are almost identical except for memory addressing capacity: (1) Z8001 and (2) Z8002. The processor architecture of Z8001 shows that there are 16 16-bit registers, all of which can be used as accumulators and all except RO can be used as index registers. It is also possible to perform some 64-bit (4 word) working. The program counter consists of a 16-bit offset and a 7-bit segment number. The CPU can be operated in system or normal mode and a bit in the status register marks the current mode.

Even if you do no more than run preprogrammed, canned software packages, an understanding of what happens when a program is run will be of value. And, of course, having this understanding will open up possibilities for the HX-20 that you may not have previously thought of.

In the last chapter we developed the concepts and tools needed to build the paper operating system outlined in chapter 1. As mentioned there, the paper operating system will resemble an onion in which each layer provides a set of functions dependent only on the layers within it. At the centre of the onion are the facilities provided by the hardware of the machine itself. The onion layers can be regarded as implementing successive virtual machines, so that the onion as a whole implements the virtual machine required by the user.

This paper develops a method for formally proving the correctness of a microprocessor using an equational method. The behavioral and structural specifications of the processor are expressed in a functional language. The asynchronous interaction between the memory and CPU is expressed in the specification by using a nondeterministic function random. This makes our specification more direct and natural than previous efforts based on a functional formalism. The previous efforts have had to encode in the specification the anticipated asynchronous interaction between the memory and the CPU.

The goal of this chapter is to investigate two commercial microprocessors and to learn to program them. There are many microprocessors on the market, and studying just two of them may seem limiting, but this is not the case. The microprocessors selected are the Motorola 6800 and the Intel 8080/8085 families, which are widely used in their own right. In addition, the Rockwell 6502 has many similarities to the Motorola 6800 and the Zilog Z-80 is related to the Intel 8080/8085.

Author's comment (added 1982): In retrospect this text is not without historical interest: it records the highlights of a discussion mentioned [as "Verbal communication" (Dijkstra 1975)] in C. A. R. Hoare's "Communicating sequential processes", Comm. ACM 21, 8 (Aug. 1978), 666-677. The text was evidently written in a state of some excitement; in retrospect we may conclude that this excitement was not entirely unjustified. Seeing Hoare keenly interested in the topic, I left that arena.

The MC68000 is a bulky integrated circuit that is 1.2 inches longer and 0.4 inches wider than a 40-pin package. The fact that it is equipped with numerous pins, however, makes it easier to interface.

The hypothetical system described in the previous chapters is somewhat too complex to build on a prototyping board. It is, however, desirable for the reader to build a small system and to use it to gain programming experience.

In this chapter we narrow our scope from the system-level speculations of Chapter 1 to the nuts-and-volts hardware level. This is more than a formality. It is impossible to write effective software for a real-time system without an understanding of the system’s hardware, because the hardware and the software are too strongly related. The hardware scans all the relevant available states of the environment, encodes them, and reports them to the software; the software responds to the reports, part of the response being to output encoded instructions to the hardware. The job of the software is to decode the inputs into meaningful information, determine the appropriate reaction, and encode the reaction into output signals. All of this decoding and encoding is heavily dependent on the nature of the hardware with which the software is communicating.

This paper explores the implementation of special purpose digital hardware devices, using Reed-Solomon decoders as its primary example. A design methodology is presented for implementing “special purpose microprocessors” — microprogrammed devices designed to carry out specific tasks. Several Reed-Solomon decoder designs with differing throughputs and costs are discussed in light of this methodology.

We present a new model of parallel computation called the "array processing machine" or APM. The APM was designed to closely model the architecture of existing vector- and array processors, and to provide a suitable unifying framework for the complexity theory of parallel combinatorial and numerical algorithms.

The Viper microprocessor designed at the Royal Signals and Radar Establishment (RSRE) is one of the first commercially produced computers to have been developed using modern formal methods. Viper is specified in a sequence of decreasingly abstract levels. In this paper a mechanical proof of the equivalence of the first two of these levels is described. The proof was generated using a version of Robin Milner’s LCF system.

The microprocessor market today is basically controlled by three producers, whose 16-bit processors will be briefly described in this chapter. Section 7.1 will deal with Motorola’s MC68000, Section 7.2 will describe Zilog’s Z8000 and Section 7.3 will introduce Intel’s 8086. The short descriptions will include programming models, data formats, addressing types, instruction sets, trap and interrupt mechanisms as well as microprocessor signals. Moreover, a review will be given of the different structures of the new machines based on these processors. — For more details, see the producers’ manuals (Motorola [4, 49–51], Zilog [3, 48, 52, 53], Intel [2, 54–56]). Comparative considerations regarding the three processors mentioned above can be found in [42–47].

The main reason of the software crisis is the use of the von Neumann computer architecture and of programming languages related to it. A way out, therefore, necessitates both, new architectures and new languages. The buffer machine Puma (which stands for the German Puffer-Machine) is the result of such an investigation. It has an abstract storage (or data type) architecture. But, more important than addressing objects by their names, is the organization of the control flow in Puma. There are no GOTOs on machine level. Any machine program has the form of a Nassi Schneiderman diagram, i.e. a sequence of instructions called an action. Instructions may be atoms or conditional or unconditional calls of actions. Reaching the end of an action at run time is automatically interpreted as “return to the calling action”. Actions are compiled separately. Since all objects are context-independently addressed by their names, a binding is unnecessary. Puma has excellent detection capabilities for sofware and hardware faults by the use of object descriptors and tags. Since the processor neither has a program counter nor any other register, exception handling can immediately be inserted. Conventional languages like Pascal, Ada and FORTRAN can be compiled, but the Puma assembler in some sense is more user-oriented, since the assembly program is not a linear sequence of code, but a set of independent actions.

A new instruction fetch method, forward semantic, is offered to enable the deeply pipelined processors to fetch one useful instruction every cycle. Forward semantic is an improved alternative to the delayed branching (with or without squashing), with five major advantages. Fist, no restriction is imposed on the type of instructions filling the branch slots, which allows a large number of slots to be filled. Second, no modification to the offsets and displacements is necessary when an instruction is copied to fill a branch slot, which simplifies the linker implementation. Third, an interrupted program can resume execution with a single program counter, eliminating the need for reloading the instruction pipeline before resuming execution. Fourth, programs compiled with N slots can execute on pipelines requiring K (K ≤ N) slots, which makes family architecture compatibility possible . Lastly, the filling of branch slots is totally transparent to code compaction and software interlocking schemes. These advantages combine to provide an efficient instruction fetch mechanism and to eliminate artificial penalties on branch cost. At the cost of 11% static code expansion, forward semantic achieves an instruction fetch cost of 1.2 cycles for pipelines requiring 10 slots for each taken branch. This level of instruction fetch efficiency has never been achieved before with conventional instruction fetch methods. The branch cost is dictated by the accuracy of the compile-time branch prediction rather than artificial limitations, such as data dependencies, which prevent the slots from being filled. These results are measured from the execution of real UNIX and CAD programs with complex control structures.

The FC-4100 is a parallel binary computer with a thirty-bit word length. It operates at a 1.0 mc clock rate and performs approximately 50,000 operations per second. The internal memory capacity is 4,096, 8,192, or 16,384 words of random-access core storage with an access time of 1.3 microseconds. The entire data processor, with core memory, contains less than 3,000 transistors. A special feature of the computer is a program interrupt system: up to sixteen independent programs can be executed on a pre-assigned priority basis. Each program is provided with its own set of six index registers and its own program counter. Other feastures include: a special repeat mode for controlling small, iterative loops without the usual branch instructions; relative addressing; half-word multiply and divide instructions for faster operation at reduced precision; and a normalize instruction to facilitate floating-point operations.

Classical instruction systems specify all functions, simple and complex, through the same mechanism. This paper describes a new organization in which more elementary operations are programmer specified by a second instruction set in micro-subroutines controlled by a subordinate instruction counter. Contingencies in the execution of primary instructions cause automatic seizure of control by the subordinate level and the execution of the appropriate microinstructions. At the completion of a micro-subroutine control reverts to the primary level for continuation of the suspended primary operation. Coding techniques, priority problems, and validity considerations are explored. The relationship of this system to interruption techniques and parallel instruction counters is discussed.