Richard T. Witek

Alpha architecture and first implementation

Summary form only given. Alpha is a new 64-b RISC (reduced instruction set computer) architecture designed to facilitate superpipelined and superscalar implementations. EV4, the first implementation of the Alpha architecture, is a 200-MHz custom VLSI CPU with a peak issue rate of 400 MIPs. EV4 is implemented in Digitals 0.75- mu m 3.3-V CMOS technology, contains 1.68 M transistors on a 16.8-mm*13.9-mm chip, and is packaged in a 431-pin PGA. The Alpha architecture, besides supporting a variety of integer and floating point data types, emphasizes pipelining, memory synchronization, and memory access. To facilitate application of the chip on a broad spectrum of applications, EV4 connects directly to an external writeback backup cache built from industry-standard static RAMs.<<ETX>>

Chapter 1 – Introduction (I)

Publisher Summary This chapter provides an overview of the Alpha AXP architecture. Alpha AXP is a 64-bit load/store RISC architecture that is designed with particular emphasis on the three elements that affect its performance the most: (1) clock speed, (2) multiple instruction issue, and (3) multiple processors. The Alpha AXP architecture is designed to avoid bias toward any particular operating system or programming language. Alpha AXP supports the OpenVMS AXP, DEC OSF/1, and Windows NT AXP operating systems and supports simple software migration for applications that run on those operating systems. All registers in Alpha AXP architecture are 64-bits in length and all operations are performed among 64-bit registers. The instructions are very simple. All instructions are 32-bits in length. Memory operations are either loads or stores. All data manipulation is done between registers. The Alpha AXP architecture facilitates pipelining multiple instances of the same operations because there are no special registers and no condition codes. Alpha AXP makes it easy to maintain binary compatibility across multiple implementations and easy to maintain full speed on multiple-issue implementations.

High performance issue oriented architecture

An issue-oriented architecture designed for high performance is described. It uses features, such as simple instruction formats, large number of registers, and load/store architecture, found in some reduced-instruction-set-computer architectures. It also includes features, such as out-of-order completion, imprecise exceptions, and vector processing, found in supercomputers such as the CRAY-1. Furthermore, it provides a full set of system support features, such as multiprocessor synchronization, vectored exceptions, stacks, asynchronous system traps, and extensive memory management, found in complex architectures such as the VAX. The reduced instruction parallel/pipelined (RIP) architecture is described. The RIP architecture was designed as a robust architecture to meet a wide range of system requirements across a family of implementations. The processor model that guided the architecture definition consists of multiple pipelined function units, each of which executes a class of instructions.<<ETX>>

Introduction to OpenVMS AXP (II–A)

This chapter provides an overview of open virtual memory system (OpenVMS) AXP. The goals of this design are to provide a hardware-implementation independent interface between the OpenVMS AXP operating system and the hardware. The design provides the needed abstractions to minimize the impact between OpenVMS AXP and different hardware implementations. It must contain only the overhead necessary to satisfy those requirements, while still supporting high-performance systems. The processor status (PS) register, defined by OpenVMS AXP is a special register that contains the current status of the processor. The stack pointer (SP) regiter contains the address of the top of the stack in the current mode. The internal processor registers (IPRs) provide an architected mapping to internal hardware or provide other specialized uses. They are available to only privileged software through PALcode routines and allow OpenVMS AXP to interrogate or modify system state. The processor cycle counter (PCC) register consists of two 32-bit fields. The low-order 32 bits (PCC ) are an unsigned, wrapping counter, PCC_CNT.

Chapter 8 - Input/Output Overview (I)

This chapter provides an overview of input/output system of Alpha AXP system. Conceptually, the Alpha AXP systems can consist of processors, memory, a processor-memory interconnect (PMI), I/O buses, bridges, and I/O devices. A bridge connects an I/O bus to the system, either directly to the PMI or through another I/O bus. The I/O bus address space is available to the processor either directly or indirectly. Indirect access is provided through either an I/O mailbox or an I/O mapping mechanism. The I/O mapping mechanism includes provisions for mapping between PMI and I/O bus addresses and access to I/O bus operations. Alpha AXP I/O operations can include: (1) accesses between the processor and an I/O device across the PMI; (2) accesses between the processor and an I/O device across an I/O bus; (3) direct memory access (DMA) accesses — I/O devices initiating reads and writes to memory; (4) processor interrupts requested by devices; and (5) bus-specific I/O accesses.

Console Subsystem Overview (III)

This chapter provides an overview of console subsystem of the Alpha AXP system. On an Alpha AXP system, underlying control of the system platform hardware is provided by a console. The console initializes, tests, and prepares the system platform hardware for Alpha AXP system software; bootstraps system software; controls and monitors the state and state transitions of each processor in a multiprocessor system in the absence of operating system control; provides services to system software that simplify system software control of and access to platform hardware; and provides a means for a console operator to monitor and control the system. The console interacts with system platform hardware to accomplish the first three tasks. The mechanisms of these interactions are specific to the platform hardware, however, the net effects are common to all systems. The console interacts with the console operator through a virtual display device or console terminal. The console terminal forms the interface between the console and a console presentation layer. The implementation of Alpha AXP console varies from system to system. The goal of Alpha AXP console architecture is to promote a consistent interface across all Alpha AXP systems. Some console functionality is inherently implementation-specific and cannot be required of all Alpha AXP systems; some may be applicable to more than one Alpha AXP system.

Introduction to DEC OSF/1 (II–B)

This chapter provides an overview of DEC OSF/1. The goals of this design are to provide a hardware interface between the hardware and DEC OSF/1 that is implementation independent. The interface needs to provide the required abstractions to minimize the impact of different hardware implementations on the operating system. The interface also needs to be low in overhead to support high-performance systems. It needs to only support the features used by DEC OSF/1. The register usage in this interface is based on the current calling standard used by DEC OSF/1. If the calling standard changes, this interface will be changed accordingly.

Instruction Formats (I)

This chapter presents the instruction set formats of Alpha AXP processor circuit. Each Alpha AXP processor has a set of registers that hold the current processor state. If an Alpha AXP system contains multiple Alpha AXP processors, there are multiple per-processor sets of these registers. The Alpha AXP processor has 32-integer value registers, 32-floating point registers, one program counter (PC). There are five basic Alpha AXP instruction formats: (1) memory, (2) branch, (3) operate, (4) floating-point operate, and (5) PALcode. All instruction formats are 32-bits long with a 6-bit major opcode field in bits of the instruction. The Memory format is used to transfer data between registers and memory, to load an effective address, and for subroutine jumps. Memory format instructions with a function code replace the memory displacement field in the memory instruction format with a function code that designates a set of miscellaneous instructions. The operate format is used for instructions that perform integer register to integer register operations. The operate format allows the specification of one destination operand and two source operands. The floating-point operate format is used for instructions that perform floating-point register to floating-point register operations. PALcode format is used to specify extended processor functions. The source and destination operands for PALcode instructions are supplied in fixed registers that are specified in the individual instruction descriptions.

OpenVMS AXP Internal Processor Registers (II–A)

This chapter illustrates internal process registers (IPRs) of the OpenVMS AXP operating system. These registers are read and written with Move from processor register (MFPR) and move to processor register (MTPR) instructions. Those instructions accept an input operand in R16 and return a result, if any, in R0. Some IPRs, for example, ASTSR, ASTEN, IPL, may be both read and written in a combined operation by performing an MTPR instruction. IPR registers may or may not be implemented as actual hardware registers. An implementation may choose any combination of PALcode and hardware to produce the architecturally specified function. These registers are only accessible from kernel mode.

Common PALcode Architecture (I)

This chapter focuses on the common Privileged Architecture Library (PALcode) architecture. PALcode is used to implement the following functions: (1) instructions that require complex sequencing as an atomic operation; (2) instructions that require VAX style interlocked memory access; (3) privileged instructions; (4) memory management control, including translation buffer (TB) management; (5) context swapping; (6) interrupt and exception dispatching; (7) power-up initialization and booting; (8) console functions; and (9) emulation of instructions with no hardware support. PALcode provides a mechanism to implement these functions without microcode. PALcode uses the Alpha AXP instruction set for most of its operations. A small number of additional functions are needed to implement the PALcode. Five opcodes are reserved to implement PALcode functions: (1) PAL19, (2) PAL1B, (3) PAL1D, (4) PAL1E, and (5) PAL1F. These instructions produce a trap if executed outside the PALcode environment. An Alpha AXP implementation may also choose to provide additional functions to simplify or improve performance of some PALcode functions. The PALcode instructions must be recognized by mnemonic and opcode in all operating system implementations, but the effect of each instruction is dependent on the implementation.