This is Version 4 of the Alpha
Architecture Handbook.
Compaq Computer Corporation
October 1998
The informatio n in this pu bl icat io n is subj ect to chang e with out noti ce.
COMP AQ COMPUTER CORPORATION SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL
ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL. THIS
INFORMAT ION IS PROVIDED “AS IS” AND COMPAQ COMPUTER CORPORA TION DISCLAIMS ANY
WARRANTIES, EXPRESS, IMPLIED OR STATUTORY AND EXPRESSL Y DISCLAIMS THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR PARTICULAR PURPOSE, GOOD TITLE AND AGAINST
INFRINGEMENT.
This publication contains inf or m ation protected by copyright. No part of thi s publicat ion may be photocopied or
reproduced in any form without prior written consent from Compaq Computer Corporation.
The following are trademarks of Comaq Computer Corporation: Alpha AXP, AXP, DEC, DIGITAL, DIGITAL
UNIX, OpenVMS, PDP–11, VAX, VAX DOCUMENT, and the DIGITAL logo.
Cray is a regis tered trademark of Cray Resear ch, Inc. IBM is a registered trademar k of International Business
Machines Co rporation. UNIX is a r egistered trademark in the United States and other countries licensed exclusively
through X/O pen Company Ltd. Windows NT is a trademark of Microsoft Corporation.
All other trademarks and registered t rademarks are the property of their res pective owners.
E–19Bit Summary of PCTR_CTL Register for Windows NT Alpha.................................... E–24
E–20OpenVMS Alpha and DIGITAL UNIX Performance Monitoring Functions................... E–25
E–2121264 Enable Counters for OpenVMS Alpha and DIGITAL UNIX............. .................. E–27
E–2221264 Disable Counters for OpenVMS Alpha and DIGITAL UNIX ............................. E–27
E–2321264 Select Desired Events for OpenVMS Alpha and DIGITAL UNI X ..................... E–28
E–2421264 Read Counters for OpenVMS Alpha and DIGITAL UNIX ................................. E–28
E–2521264 Write Counters for OpenVMS Alpha and DIGITAL UNIX ................................. E–28
E–2621264 Enable and Write Counters for OpenVMS Alpha and DIGITAL UNIX.............. . E–29
xiii
xiv
Preface
Chapters 1 through 8 and appendixes A through E of this book are directly derived from the Alpha System Reference Manual, Version 7 and passed engineering change orders (ECOs) that have been
applied. It is an accurate repr esentation of the described parts of the Alpha architecture.
References in this handbook to the Alpha Architecture Reference Manual are to the Third Edition of
that manual, EY-W938E-DP.
xv
Chapter 1
Introduction
Alpha is a 64-bit load/store RISC archite ct ure that is designe d with particular emph asis on the
three elements that most affect performance: clock speed, multiple instruction issue, and multiple processors.
The Alpha architects e xa mine d an d analy zed c ur rent and the or etical R ISC arc hitec tur e desig n
elements and developed high-performance alternatives for the Alpha architecture. The architects adopted only those design elements that appeared valuable for a projected 25-year design
horizon. Thus, Alpha becomes the firs t 21st century computer architecture.
The Alpha architecture is designed to avoid bias toward any partic ular operating system or programming language. Alpha supports the OpenVMS Alpha, DIGITAL UNIX, and Windows NT
Alpha op e rating syst e m s a n d s up ports simple software m igra ti on for app li cations tha t ru n o n
those operating systems.
This manual descr ibe s in detai l how A lpha is de signed to be the leadership 64-bit arc hite ctur e
of the computer industry.
1.1 The Alpha Approach to RISC Architecture
Alpha Is a True 64-Bit Architecture
Alpha was designed as a 64-bit architecture. All registers are 64 bits in length and all operations are performed between 64-bit registers. It is not a 32-bit architecture that was later
expanded to 64 bits.
Alpha Is Designed for Very High-Speed Implementations
The instructions are very simple. All instr uc tions are 32 bits in le ngth. M emor y operations are
either loads or stores. All data manipulation is done between registers.
The Alpha architecture facilitates pipelining multiple instances of the same operations because
there are no special registers and no condition codes.
The instructions interact with e ach other only by one ins tru ct ion w ri ting a r eg ister o r me mor y
and another instruction reading from the same place. That makes it particularly easy to build
implementations that issue multiple instructions every CPU cycle.
Introduction 1–1
Alpha makes it easy to maintain binary compatibility across multiple implementations and easy
to maintain full speed on multiple-issue implementations. For example, there are no implementation-speci fic pipeline timing hazards, no load-delay slots, and no branch-delay slots.
The Alpha Approach to Byte Manipulation
The Alpha arc hi te ctur e reads and write s by te s be tw e en reg iste rs a nd m e mor y w ith the LDBU
and STB instructions. (Alpha also supports word read/writes with the LDWU and STW
instructions .)
Byte shifting a nd mas king is perfo rme d w ith n ormal 64 -b it r egiste r-to-r eg ister i nstru ction s,
crafted to keep instruction sequences short.
The Alpha Approach to Multiprocessor Shared Memor y
As viewed from a second processor (including an I/O device), a sequence of reads and writes
issued by one processor may be arbitrarily reordered by an implementation. This allows implementations to use multibank caches, bypassed write buffers, write merging, pipelined wri tes
with retry on error, and so forth. If strict ordering between two accesses must be maintained,
explicit memory barrie r ins tructions can be inserted in the program.
The basic multiprocessor interlocking primitiv e is a RISC-style load_locked, modify,
store_conditional sequence. If the sequence runs without interrupt, exception, or an interfering
write from another processor, then the conditional store succeeds. Otherwise, the store fails and
the program eventually must branch back and retry the sequence. This style of interlocking
scales well with very fast caches and makes Alpha an especially attractive architecture for
building multiple-processor systems.
Alpha Instruction s Incl ude Hints for Achie vi ng Highe r Speed
A number of Alpha instruc tions include hints for imple mentatio ns, all aimed at achie ving
higher speed.
•Calculated jump instructions have a target hint that can allow much faster subroutine
calls and returns.
•There are prefetching hints for the memory syste m that can allow much higher cache hit
rates.
•There are granularity hints for the virtual-address mapping that can allow much more
effective use of translation lookaside buffers for large contiguous stru ctu res.
PALcode – Alpha’s Very Flexible Privileged Software Library
A Privileged Ar chite c ture Libr ary (PA Lc ode ) is a se t of subroutines that are spe c ific to a par ticular Alpha operating system implementation. These subroutines provide operating-system
primitives for context switching, interrupts, exceptions, and memory management. PALcode is
similar to the BIOS libraries that are provided in personal computers.
PALcode subroutines are invoked by implementation hardware or by software CALL_PAL
instructions.
1–2 Alpha Architecture Handbook
PALcode is written in standard machine code with some implementation-specific extensions to
provide access to low-le vel hardware.
PALcode lets Alpha impleme ntations run the f ull Ope nVMS Alpha , DI GITA L UN IX, and
Windows NT Alpha operating systems. PALcode can provide this functionality with little
overhea d. F or exa mple, the Op e nV M S Al ph a PA L co de instructions let Al ph a ru n O pe n VM S
with little more hardwar e than tha t found on a con ventiona l R ISC m achin e: the PAL m ode bit
itself, plus four extra protection bits in eac h translation buffer entry.
Other versions of PALcode can be developed for real-time, teaching, and other applications.
PALcode makes Alpha an especially attractive architecture for multiple operati ng syste ms.
Alpha and Programming Languages
Alpha is an attractive architecture for compiling a large variety of programming languages.
Alpha has been carefully designed to avoid bias toward one or two programmi ng languages.
For exampl e:
•Alpha does not contain a subroutine call instruction that moves a register window by a
fixed amount. Thus, Alpha is a good match for programming languages with many
parameters and programming languages with no parameters.
•Alpha does not contain a global integer overflow enable bit. Such a bit would need to
be changed at every subroutine boundary when a FORTRAN program calls a C program.
1.2 Data Format Overview
Alpha is a load/store RISC architecture with the following data characteristics:
•All operations are done between 64-bit registers.
•Memory is accessed via 64-bit virtual byte addresses, using the little-endian or, option-
ally, the big-endian byte numbering convention .
•There are 32 integer registers and 32 floating- point registers.
•Longword (32-bit) and quadword (64-bit) inte gers are supported.
As shown in Figure 1–1, Alpha instructions are all 32 bits in length. Th ere are four major
instruction format classes that contain 0, 1, 2, or 3 register fields. All formats have a 6-bit
opcode.
Figure 1–1: I nstruct ion Format Overview
03126 25212016 155 4
NumberOpcode
PALcode Format
FunctionRCRB
Disp
Disp
Branch Format
Memory Format
Operate Format
Opcode
Opcode
Opcode
RA
RA
RA
RB
•PALcode instructi ons specify, in the function code field, one of a few dozen complex
operations to be performed .
•Conditional branch instructions test register Ra and specify a signed 21-bit PC-rela-
tive longword target displacement. Subroutine calls put the return address in register
Ra.
•Load and store instructions move bytes, words, longwords, or quadwords between
register Ra and memory, using Rb plus a signed 16-bit displacement as the memory
address.
•Operat e in stru ctions for floating-point and integer operations are both represented in
Figure 1–1 by the operate format ill ustr ation and are as follows:
–Word and byte sign-extension operators.
–Floating-point operations use Ra and Rb as source registers and write the result in
register Rc. There is an 11-bit extended opcode in the function field.
–Integer operations use Ra and Rb or an 8-b it literal as the source operand, and write
the result in registe r Rc.
–Integer operate instructions can use the Rb field and part of the function field to
specify an 8-bit litera l. There is a 7-bit extended opco de i n the func tion field.
1.4 Instruction Overview
PALcode Instructions
As described in Section 1.1, a Privileged Architecture Library (PALcode) is a set of subroutines that is specific to a particular Alpha operating-system implem entation. These subroutines
can be invoked by hardware or by software CALL_PAL instructions, which use the function
field to vector to the specifie d subroutine.
1–4 Alpha Architecture Handbook
Branch Instruct i ons
Conditional branch i nstruc tions can tes t a reg ister fo r p ositiv e/negat ive or fo r zero /nonze ro,
and they can test inte ge r registe r s for e ven/odd. Uncondition al branc h ins tru ctions c a n write a
return address into a register.
There is also a calculated jump instruction that branches to an arbitrary 64-bit address in a
register.
Load / S tore Instruction s
Load and store instruc tion s m ove 8-bit, 16-bit, 32-bit, or 64-bit a ligne d qu an tities from a nd to
memory. Memory addresses are flat 64-bit virtual addresses with no segmentation.
The VAX floating-point load/store instructions swap words to give a consistent register format
for floating-point operations.
A 32-bit integer datum is placed in a register in a canonical form that makes 33 copies of the
high bit of the datum. A 32 -bit floating -po int datum is pla c ed in a regis ter in a canoni cal fo rm
that extends the exponent by 3 bits and extends the fraction with 29 low-order zeros. The 32bit operates preserve these canonical forms.
Compilers, as directed by user decl arations, can generate any mixture of 32-bit and 64-bit operations. The Alpha architecture has no 32/64 mode bit.
Integer Operate Instructions
The integer operate instructions manipulate full 64-bit values and include the usual assortment
of arithmetic, compare, logical, and shift instructions.
There are just three 32-bit inte ger ope rates: add , subtrac t, and mul tiply. The y diffe r from the ir
64-bit counterparts only in overflow detection and in producing 32-bit canonical results.
There is no integer divide instr uction.
The Alpha architectur e also suppor ts the following additional operations:
•Scaled add/subtract instructions for quick subscript calculation
•128-bit multiply for division by a constant, and multiprecision arithmetic
•Conditional move instructions for avoiding branch instructions
•An extensive set of in-register byte and word manipul ation instructions
•A set of multimedia instructions that support gr aphics and video
Integer overflow tr ap enab le is en cod ed in th e fun ction field o f ea ch instruct ion, ra ther t han
kept in a global state bit. Thus, for example, both ADDQ/V and ADDQ opcodes exist for specifying 64 -bi t ADD w ith a nd w itho ut ov erfl ow check in g. Tha t m akes it eas ier to pi pel ine
implementations.
Introduction 1–5
Floating-Point Operate Instructions
The floating-point operate instructions include four complete sets of VAX and IEEE arithmetic instructions, plus instructions for performing conversions between floating-point and
integer quantiti es.
In addition to the ope ratio ns f ound in co nventional RISC arc hitec tur es, A lpha inc lud es con ditional move instructions for avoiding branches and merge sign/exponent instructions for simple
field manipulation.
The arithmetic trap enables and rounding mode are encoded in the function field of each
instructi on, rather t han kept in g lobal stat e bits. Tha t makes it eas ier to pipe line
implementations.
1.5 Instruction Set Characteristics
Alpha instruction set char acteristics are as follows:
•All instructions are 32 bits long and have a regular for mat.
•There are 32 integer registers (R0 through R31), each 64 bits wide. R31 reads as zero,
and writes to R31 are ignored.
•All integer data manipulation is between intege r register s, with up to two variable regis-
ter source operands (one may be an 8-bit liter al) and one register destination operand.
•There are 32 floating-point registers (F0 through F31), each 64 bits wide. F31 reads as
zero, and writes to F31 are ignored.
•All floating-point data manipulation is between floating-point registers, with up to two
register source opera nds a nd one register destination operand.
•Instructions can move data in an integer register file to a f loating-point register file, and
data in a floating-point register file to an integer register file. The instructions do not
interpret bits in the register files and do not access memory.
•All mem ory referenc e instructions are of the load/store type that moves data between
registers and memory.
•There are no branch condition codes. Branch instructions test an integer or floating-
point register value , whic h may be the result of a previous compare.
•Integer and logical instructions operate on quadwords.
•Floating-point instructions operate on G_floating, F_floating, and IEEE extended, dou-
ble, and single operands. D_floating "format compatibility," in which binary files of
D_floating numbers may be processed, but without the last 3 bits of fraction precision,
is also provided.
•A minimal number of VAX compatibility instructions are included.
1.6 Terminology and Conventions
The following sections describe the terminology and conventions used in this book.
1–6 Alpha Architecture Handbook
1.6.1 Numbering
All numbers are decima l unle ss oth erwis e ind icate d. Whe r e there is am bigu ity, numbe rs other
than decimal are indicated with the name of the base in subscript form, for example , 10
1.6.2 Securi ty Holes
A security hole is an erro r o f commission, omission, or oversight in a sy ste m tha t allows protection mechanisms to be bypassed.
Security holes exist when unprivileged software (software running outside of kernel mode)
can:
•Affect the operation of another process without authorization from the operating sys-
tem;
•Amplify its privilege without authorization from the operating system; or
•Communicate with another process, either overtly or covertly, without authorization
from the operating system.
The Alpha architecture has been designed to contain no a rchitectura l security holes. Hardwar e
(processors, buses, controllers, and so on) and software should likewise be designed to avoid
security holes.
16.
1.6.3 UNPREDICTABLE and UNDEFINED
The terms UNPREDIC TAB L E and UNDE FINE D are used through out this book. Their meanings are quite different and must be carefully distinguished.
In particular, only privileged software (software running in kernel mode) can trigger UNDEFINED oper ati ons. U npr ivil eg ed softwa r e cannot trigger UN DEF I NE D op era tion s. How e ver,
either privileged or unprivileged software can trigger UNPREDICTA BLE results or
occurrences.
UNPREDICTABLE results or occur rences do not disrupt the basic operatio n of the processor;
it continues to exe c ute instr uc tion s in its nor m al manner. In contras t, UND EF I NED ope r ation
can halt the processor or cause it to lose information.
The terms UNPREDICTABLE and UNDEFINED can be further described as follows:
UNPREDICTABLE
•Results or occurrences specified as UNPREDICTABLE may vary from moment to
moment, implementation to implementation, and instruction to instruction within
implementations. Software can never depend on results specified as UNPREDICTABLE.
•An UNPREDICTABLE result may acquire an arbitrary value subject to a few con-
straints. Such a result may be an arbitrary function of the input operands or of any state
information that is accessible to the process in its current access mode. UNPREDICTABLE results may be unchanged from their previous values.
Introduction 1–7
Operations that produc e UNPREDICTABLE results may also produce exceptions.
•An occurrence specified as UNPREDICTABLE may happen or not based on an arbi-
trary choice function. The choice function is subject to the same constraints as are
UNPREDICTABLE results and, in particular, must not constitute a security hole.
Specifically, UNPREDICTABLE results must not depend upon, or be a function of,
the contents of memory locations or registers that are inaccessible to the current
process in the current access mode.
Also, operations that may produce UNPREDICTABLE results must not:
–Write or modify the contents of memory locations or registers to which the current
process in the current access mode does not have access, or
–Halt or hang the system or any of its components.
For example, a security hole would exist if some UNPREDICTABLE result depended
on the value of a register in another process, on the contents of processor temporary
registers left behind by some previously running process, or on a sequence of actions
of different processe s.
UNDEFINED
•Operations specified as UNDEFINED may vary from moment to moment, implementa-
tion to implementation, and instruction to instruction within implementations. The
operation may vary in eff ect from nothing to stopping syst em opera tion.
•UNDEFINED operations may halt the processor or cause it to lose information. How-
ever, UNDEFI NED operations must not cause the processor to hang, that is, reach an
unhalted state from which there is no transition to a normal state in which the machine
executes instructions.
1.6.4 Ranges and Extents
Ranges are specified by a pair of numbers separated by two periods and are inclusive. For
example, a range of integers 0..4 includes the integers 0, 1, 2, 3, and 4.
Extents are specified by a pair of numbers in angle brackets separated by a colon and are inclusive. For example, bits <7: 3> specif y an extent of bits including bits 7, 6, 5, 4, and 3.
1.6.5 ALIGNED and UNALIGNED
In this document the term s A LIGNE D and NATU RA LLY ALIG N ED are u sed in terchange ably to refer to data objects that are powers of two in size. An aligned datum of size 2**N is
stored in memory at a byte address that is a multiple of 2**N, that is, one that has N low-order
zeros. Thus, an aligned 64-byte stack frame has a memory address that is a multiple of 64.
If a datum of size 2**N is stored at a byte address that is not a multiple of 2**N, it is called
UNALIGNED.
1–8 Alpha Architecture Handbook
1.6.6 Must Be Zero (MBZ)
Fields specified as Must be Zero (M BZ) must neve r be filled by software with a non -zero
value. These field s may be u sed at som e fut ure tim e. If the pro cess or en co unters a no n-zero
value in a field specified as MBZ, an Illegal Operand exception occurs.
1.6.7 Read As Zero (RAZ)
Fields specified as Read as Zero (RAZ) return a zero when read.
1.6.8 Sh ould Be Zer o (SBZ)
Fields specified as Should be Zero (SB Z) sho uld be filled by softw are with a zero va lue. Non zero values in SBZ fields produce UNPREDICTABLE results and may produce extraneous
instruction-issue delays.
1.6.9 Ignore (IGN)
Fields specified as Ignore (IGN) are ignored when written.
1.6.10 Implementation Depe ndent (IMP )
Fields specified as Implementation Dependent (IMP) may be used for implementation-specific
purposes. Each im plem e ntation must document f ully the beh avior of all fi elds m arke d as IMP
by the Alpha specification.
1.6.11 Illustration Con ventions
Illustrations that depict registers or memory follow the co nvention that increas ing addresses
run right to left and top to bottom.
1.6.12 Macro Code Example Conventions
All instructions in macro c ode example s a re e ither listed in Cha pter 4 or are stylize d code
forms found in Section A.4.6.
Introduction 1–9
2.1 Addressing
70
:A
The basic addre ssa ble un it in the Al pha archite c ture is the 8- bit by te . Vir tual ad dr esse s are 64
bits long. An im pl em en ta tio n m ay support a sm a ller vir tual a dd r es s sp ace . The minimu m vir tual address size is 43 bits.
Virtual addresses as seen by the program are translated into physical memory addresses by the
memory ma n agem en t mechanism.
Although th e da ta types in Section 2.2 ar e de sc ribe d in te rms of little -e ndi an byte addressing,
implementations may also include big -endian addressing support, as describe d in Sec tion 2 .3.
All current implementations have some big-endian support.
Chapter 2
Basic Architecture
2.2 Data Types
Following are descriptions of the Alpha architecture data types.
2.2.1 Byte
A byte is 8 contiguous bits starting on an add ressable byte b oundary. Th e b its are numbered
from right to left, 0 through 7, as shown in Figure 2–1.
Figure 2–1: B yte Format
A byte is specified by its address A. A byte is an 8-bit value. The byte is only supported in
Alpha by the load, store, sign-e xtend, extract, mask, insert, and zap instructions.
2.2.2 Word
A word is 2 contiguous bytes starting on an arbitrary byte boundary. The bits are numbered
from right to left, 0 through 15, as shown in Figure 2–2.
Basic Architecture 2–1
Figure 2–2: Wor d Format
A word is specified by its address, the address of the byte containing bit 0.
A word is a 16-bit val ue. Th e wor d is only supported in Alpha by th e lo ad, sto re, sign- exte nd,
extract, mask, and inser t instructions.
2.2.3 Longword
A longword is 4 contiguous bytes starting on an arbitrary byte boundary. The bits are num-
bered from right to left, 0 through 31, as shown in Figure 2–3.
Figure 2–3: L ongword Format
015
:A
031
:A
A longword is specified by its ad dress A, the add ress of the byte conta ining bit 0. A longword
is a 32-bit value.
When interpreted arithmetically, a longword is a two’s-complemen t integer with bits of
increasing significance from 0 through 30. Bit 31 is the sign bit. The longword is only supported in Alp ha by sign-ext ended lo ad an d store in struc tions and by lo ngwor d arithme tic
instructions.
Note:
Alpha implementations will impose a significant performance penalty when accessing
longword operands that are not naturally aligned. (A naturally aligned longword has zero
as the low-order two bits of its address.)
2.2.4 Quadword
A quadword is 8 contiguous bytes starting on an arbitrary byte boundary. The bits are numbered from right to left, 0 through 63, as shown in Figure 2–4.
Figure 2–4: Quadword Format
63
0
:A
2–2 Alpha Architecture Handbook
A quadword is specified by its address A, the address of the byte containing bit 0. A quadw ord
is a 64-bit value. When interpreted arithmetically, a q uadw ord is either a tw o’s-comp lement
integer with bits of increasing significance from 0 through 62 and bit 63 as the sign bit, or an
unsigned integer with bits of increasing significance from 0 through 63.
Note:
Alpha implementations will impose a significant performance penalty when accessing
quadword operands that are not naturally aligned. (A naturally aligned quadword has zero
as the low-order three bits of its address.)
2.2.5 VAX Floating- Poi nt F ormats
VAX floating-point numbers are stored in one set of formats in memory and in a second set of
formats in r egisters. The f loating-poin t lo ad a nd s tor e instructi ons c onv e rt be tw een these formats purely by rearranging bits; no rounding or range-checking is done by the load and store
instructions.
2.2.5.1 F_floating
An F_floating datum is 4 c on tiguous byte s in m em o ry sta rting on an arbit rar y by te bou nd ary.
The bits are labeled from right to le ft , 0 thro ugh 31, as shown in Figure 2–5 .
Figure 2–5: F_f loating Datum
31
1614
S
715
60
Frac. HiFraction Lo:AExp.
An F_floating operand oc cupie s 64 bits in a floati ng r egister, left-justified in the 64- bi t reg is-
ter, as shown in Figure 2–6.
Figure 2–6: F_floating Register Format
52 5129 28
S
Exp.Fraction0:Fx
The F_ f lo a ti ng lo a d instruction re o r der s bits on the way in from m e mory, ex p a nd s t he e xp onent from 8 to 11 bits, and sets the low-order fraction bits to zero. This produces in the register
an equiv a lent G_floating num be r suitable f or e ith e r F_ f loating or G _f lo a tin g o pe r ations. Th e
mapping from 8-bit memory-format exponents to 11-b it register-forma t exponents is shown in
Table 2–1. This mapping preserves both normal values and exceptional values.
1 11111111 000 1111111
1 xxxxxxx1 000 xxxxxxx (xxxxxxx not all 1’s)
0 xxxxxxx0 111 xxxxxxx (xxxxxxx not all 0’s)
0 00000000 000 0000000
The F_floa ting stor e ins truction reord ers regis ter b its on the w ay to m emo ry an d does no
checking of the low-order fraction bits. Register bits <61:59> and <28:0> are ignored by the
store instructi on.
An F_floating datum is specified by its address A, the address of the byte containing bit 0. The
memory form of an F_floating datum is sign magnitude with bit 15 the sign bit, bits <14:7> an
excess-128 binary exponent, and bits <6:0> and <31:16> a normalized 24-bit fraction with the
redundant m o st si gnificant fra ction bit not repr e sented. Within the f r acti on, bits of increa si ng
significance are from 16 through 31 and 0 through 6. The 8-bit exponent field encodes the values 0 thr o ug h 255. A n e xp on e nt va lu e o f 0, togeth e r with a sig n bit of 0, is ta k e n t o indicate
that the F_floating datum has a value of 0.
If the result of a VAX floating-point format instruction has a value of zero, the instruction
always produces a datum with a sign bit of 0, an exponent of 0, and all fraction bits of 0. Expo-
nent values of 1..255 indicate true binary exponents of –127..127. An exponent value of 0,
together with a sign bit of 1, is taken as a reserved operand. Floating-point instructions processing a reserved operand take an arithmetic exception. The value of an F_floating datum is in
the approximate range 0.29*10**–38 through 1.7*10** 38. The precision of an F_floating
datum is approximately one part in 2**23, typically 7 decimal digits. See Section 4.7.
Note:
Alpha implementations will impose a significant performance penalty when accessing
F_floating operands that are not naturally aligned. (A naturally aligned F_floating datum
has zero as the low-order two bits of its address.)
2.2.5.2 G_floating
A G_floating datum in memory is 8 contiguous bytes starting on an arbitrary byte boundary.
The bits are labeled from right to le ft , 0 thro ugh 63, as shown in Figure 2–7.
Figure 2–7: G_floating Datum
1614
31
2–4 Alpha Architecture Handbook
15
S
43
Exp.Frac.HiFraction Midh:A
0
:A+4Fraction MidlFraction Lo
Loading...
+ 341 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.