Digital Technical Journal, Volume 4, Number Special Edition, 1992 Dtj_v04 04_1992 Dtj V04 04

dtj_v04-04_1992 dtj_v04-04_1992

User Manual: dtj_v04-04_1992
Open the PDF directly: View PDF .
Page Count: 211
Download
Open PDF In Browser	View PDF
Editorial

Jane C. l.llake, Editor
Helen L. Parrerson, Associate Editor
Kathleen M. Stetson, Associate Editor

Circulation

Catherine M. Phillips, Administrator

Sherry L. Gonzalez

Production

Terri Autieri, Production Editor
AnneS. Karzeff, Typographer
Peter R. Woodbury, Illustrator

Advisory Board

Samuel H. Fuller, Chairman
Richard
Donald

W Beane
z. Harbert

Richard]. Hollingsworth
Alan G. Nemeth
Jeffrey H. Rudy
StanSmits
Michael C. Thurk
Gayn B. Winters
The Digital Technicaljournal is published quarterly by Digital Equipment Corporation,

146 MainStreet ML01-3/B68, Maynard, Massachusetts 0175 4-2571. Subscriptions to the
joumal are $40.00 for four issues and must be prepaid in

U.S.

funds.

University and col

lege professors and Ph.D. students in the electrical engineering and computer science

f ields receive complimentary subscriptions upon request. Orders, inquiries, and address
changes should be sent to the Digital Technicatjoumal at the published-by addre�s.
Inquiries can also be sent electronically to DTJ@CRL.DEC.COM.Single copies and back
issues are available for $16.00 each f rom Digital Press of Digital Equipment Corporation,

I

Burlington Woods Drive, Burlington, MA 01830-4597.

Digital employee� may send subscription orders on the ENET to ROVAX::JOURNAL
or by interof fice mail ro mailstop ML01-3/B68. Orders should include badge number,
sire location code, and address. All employees must advise of changes of address.
Comments on rhe content of any paper are welcomed and may be sent to the editor
at the published-by or network address.
Copyright

© 1993

Digital Equipment Corporation. Copying without fee is permitted

provided that such copies are made for use in educational institutions by faculty
members and are not distributed for commercial advantage. Abstracting with credit
of Digital Equipment Corporation's authorship is permitted. All rights reserved.
The information in the jouma/ is subject to change without notice and should not be
construed as a commitment by Digital Equipment Corporation. Digital Equipment
Corporation assumes no responsibility for any errors that may appear in thejournal.
ISSN 0898-901X
Documentation Number EY.J886E-DP
The following are trademarks of Digital Equipment Corporation: ACMS,

ALL·IN·l,

Alpha

AXP, the AXP logo, AXP, DEC, DEC 3000 AXP, DEC 4000 AXP, DEC 6000 AXP, DEC 7000 AXP,
DEC 10000 AXP, DEC DBMS for Open VMS, DEC Fortran, DEC OSF/ I

A.-'(P,

DEC

Pascal,

DEC RALLY, DEC Rdb for OpenVMS, DECchip 21064, DECnet, DECnet for OpenVMS

A.,'rmats. In his conclusion. h e projects evo l utionary

system are a l s o provi ded .

changes in the architecture and the res u l ting per

The DEC 7000 and DEC 10000 systems are power

fo rmance i ncreases of a thousandfold over the next

f u l m id - range and mainframe platforms i n tended

2'; years.

for large com mercial app l i cations and designed to

The first i mplementation of the Alpha AXP archi

utilize multiple future generations of the DECcb i p .

tecture is the DECchip 21064 microprocessor, which

Descr ibed b y B r i a n Al l ison and Catharine van

can execute u p to 400 m i l l ion operat ions per

I ngen. the heart of these systems is a high-perfor

second. Dan Dobber p u h l and members of the

mance interconnect that allows com m u n i cations

Alpha chip team offer an overview of the CMOS pro

bet ween m u l tiple pro cessors, memory arrays, and

cess tec hnol ogy, t he chip m i c roarcllitectur e , and

110 subsystem s. The authors review each o f the

the external interface . They then deta i l the circ u it

m o d u les and the 1/0 su bsystem design, w hich

i mp lementation ami explai n t he design cho i ces

includes i n terfaces for X,\11 and Futu rebus. Notably,

d i rected toward meeting arch itectura l performance

a 32 -bit VAX CPU mod ule has been designed to the

2

I
requi rements of the h igh-perform ance system
i n terconnect. Users who wish to m igrate from the
VAX system to Al pha AXP need o n ly swap m od u le
boards.
M igration to Alpha AXP from other architectures,
in particu lar from VAX VMS, is one of the major goa l s
s e t b y t h e Alpha architects. E x isting software
operating systems, languages, programs-must be
adapted to r u n effectively on 64-bir RISC systems. A
parer by N ancy Kronenberg, Tom Benson, Wayne
Cardoza, Rav i nd ra n .Jagannathan, ami Ben Thomas
addresses the chal lenges of porting the OpenVMS
operati ng system-original ly developed specifi
cal l y for 32-bit VAX systems-to A . lpha AXP systems.
To deal with the huge amount of code, the p roject
team developed a compi ler that treats VA)( assembly
l anguage (VAX ;\>IACR0-32) as a source language to be
compiled . The authors also d iscuss the major archi
tectural differences in the kernel, perf()rmance, and
some future d i rections for the system .
The GEM com p i ler system i s the technology
D igital is using to bu ild state-of-the-art com p i ler
rroducts. GEM is described here by Davi d
B l ickst ei n , Peter Craig, Caro l ine Davidson, Nei l
Fa iman, Kent G lossop, Rich Grove, Steve Hobbs,
and Bi l l Noyce. A significant achievement in the
deve lopment of t h is compiler is that a si ngle opti
m izer is used fo r a l l languages and platforms.
Developers of compilers will fi nd i n-depth i nforma
tion in the auth ors' d iscussions of optim i zation
techniques, code generation, compiler engineer
i ng, and future enha ncements.
Bi nary transl ation is another means of m ov i ng
complex software appl i cati ons from one archi tec
ture and operating system to another archi tecture
and operat ing syste m . Two bi nary translato rs are
the subject of a paper by D ick S ites, Amon Chernoff,
Matthew Kirk, Mau rice Marks, and Scott Robi nso n .
T h e au thors discuss the alternatives to r r an sl a w r s
performance issues, and the development of the
translators, VEST and mx, ancl the compl ementary
run-t ime environments. VEST translates OpenVMS
VA.-X i m ages to OpenV,viS AXP i mages. and mx trans
lates ULTRI X/MIPS im ages to DEC OSF/1 A.-XP i mages.
An easy migration path to Alpha AXP fo r two
database management systems used in large com
mercial applications is the subject of a paper by Jeff
,

Coffler, Zia Mohamed, and Peter Spiro. The authors
define the issues in volved in porting the complex
VAX DBMS and Rdb/VMS prod ucts to the AXP p l a t
form . Ad d i ng to the chal lenge bu t bal anced by its
advantages was the decision to have a common
source, or single code, base. The authors review

this design approach and prov ide details of the
individual port ing efforts.
The process of porting DECnet -VA"'\ to the
operat i ng system is described by J i m
Colombo, Pam Rickard, a nd Pau l Benoit. They dis
cuss the DECnet features suppo rted i n the operat

OpenVIviS A.-XP

ing system , the software techniques used, and the
importance of rhe decision to b u i ld c o m m o n code
for the VAX and Alpha A.-XP systems. The authors
share detai Is of the port and lessons learneel that
can be applied to future porting efforts.
Complemen tary to the previously mentioned
prototype hardware system are fo ur software simu
lato rs that enabled engineers to develop software
fo r Alpha A.-X P concurrently with hardware develop
ment. Described by George Darcy, Ron Bren der,
Steve Morris, and Mike l les, the Mannequ i n simu
lator was used by the OpenVMS group to boot
the entire operating system and debug u t i l i ties;
the ISP s i m u l ator was used by the DEC OSF/ 1 group
with s i m i l a r success. A m ajor section of the paper
focuses on the A lpha User-mode Debugging Envi
ron ment in which user-mode code bei ng devel
oped for Alpha AXP platforms can be compi led and
executed as Alpha AXP code.
The c losing paper i s an unusual one for the
journal because it addresses engineering manage
ment, not strictly technical issues. Peter Conkl in
offe rs i ns ights into the reasons for the success of
one of the largest engineering progra ms under
taken in t he i nd ust ry. He defi nes the enrol lment
management model used fo r the Alpha A.-XP p ro
gram and explains key concepts, i nc l u d i ng the
program office and project "cusps."
The edi tors are very gratefu l fo r the help of Bob
Supnik, Vice President and Corpo rate Consu ltant.
in p l ann ing this speci a l issue and fo r writing its
Foreword.
We are also plea s ed to note that fou r papers
i n t h is issue are being co published witll the
Communications of the ACIJ, i n c l u d i ng those on
the Alpha AXP architectu re , the Alpha Demon
stration Unit, OpenVtv!SAXP, aml bin ary translation.
Barbara Wat terson from Digital's sem iconducto r
o rgan iza tion; Diane Crawford, Execu tive Ed itor of
the CACM; the Dl:J editors; ami the authors cooper
ated so that these informative papers could be
macle avai I able to a broad tech ni c a l audience.

I

Biographies
Brian R. Allison

Brian Al l ison is a senior consultant engineer fo r D igital's

mid-range VA X/Aipha AXP systems group ami is the system a rchitect responsible
for the coord ination of the VAX and

DEC 7000

and 10000 system definition and

design. Prior to this work , he served as system arch i tect fo r the VAX oOOO
product. Brian holds a BSE . E . and a

B.S.C.S

from Worcester Polytech nic I nstitute

(197 7)

Randy Allmon

After receiving a B.S degree in el ectrical engineering from

the U n iversity of C i nci nnati, Randy Al lmon joined D igital in 19Hl. As a circu i t
designer i n the Sem iconductor Engineering Group , h e h as contributed t o the
development of numerous high-performance CMOS processors. Curre n t l y,
Randy is responsible fo r the tech n ical design and management of a next-genera
tion processor based on the Alpha AXP arch i tecture. He i s the coauthor of fou r
high-performance processor papers given a t ISSCC and has one patent pend i ng.

Robert Anglin

Robert Angl i n received S.l3. and S.M. degrees in e lectrical engi

neering in 1989 from the Massachusetts Institute of Techn o logy. In the same
year, he j oined Digital's Sem iconductor E ng inee ring Group, \Vhere he has
worked on the design of high-performance m i croprocessors. Robert is a mem
ber of Sigma Xi. He is currently pursui ng a n 1'rnia State University at Northridge.

James V. Colombo

Project/technical leader James Colombo is currently

responsible for the next release of DECnet/OSI for OrenVMS for the VA X a ncl

Alpha AXP comp u t i ng environments. Prior to this, he led the port of DECnet-VAX
Phase IV to the OpenVMS AX!' operating system; the team received a n Alpha
Achievement Award for early completion of the project. Jim also !eel the DECnet
for OS/2 V 1.0 and various PATHWORKS p roduct efforts. Before coming to Digital
in 1983, Jim worked at P rime Computer, Inc. and Computer Devices, Inc. He
holds a BSCS from Boston University and is a member ofJEEE.

Peter F. Conklin

Peter Conkl i n is d i rector of Alpha AXP Systems Develop

ment. Si nce j o i n i ng Digital i n 1969, he has held engi neering management posi
tions in large and sma l l systems and terminals groups. d i rect hard · w are a mi

software engi n eering, product management, base prod uct marketing, qua l i ty
m anagement, and advanced development. Peter was the f irst software engineer
on the VMS project i n 1975, ran the VA X architecture team, and was instrumen tal
in developing the key architectures and products for the VAX v:v1S l ayered p ro d
uct set. Peter recei ved an All. in mathematics f rom Harvard U n i versity in 1963.

I
Robert A. Conrad

Robert Conrad received

J

HS

degree in e lectrical and com

puter engineering from the University of C i nci nnati in 1 984 and an M.S. d egree in
electrical and com p u ter engineering from the U nive rsity of Massachusetts i n
1 992. I n 1 981 he joined Digita l 's Semiconductor E ngineering Group, \vhere he
worked as a co-op student in the Architectural ly Focused Logic Group. Since
1 984 Rob has been engaged in the research and devel.opment of VLSI m icro
processors, includi ng the .\1icroVA X CPU, a 50-:viHz RlSC CPU, and most recently
the DEC:chip 2 1064 microprocessor.

David G. Conroy

Dave Conroy received a BA.Sc. degree in electrica l engi

neering from the University of Waterloo, Canada, in 1 977 After wo rking briefly
in industrial automation , Dave moved to the United States in 1 980. H e cofounded
the Mark Wil liams Company and b u i l t a successfu l copy of the UNIX operating
system. In 1 983 he j oined D igital to work on the DECt a l k speech synthesis
system and related p roducts. In 1 987 he became a member o f Digital's
Sem iconductor Engineering Grou p , where and has been i nvolved with system
level aspects of RlSC m icroprocessors.

Peter W. Craig

Peter Craig is a p ri ncipa l software engineer in the Software

Development Technologies G roup. He is currently responsible for the design
and i mplementation of a dependence analyzer for use in future compiler prod
ucts. Peter was a project leader tor the VAX Code Generator used in the VA)( C and
VAX PI./I

compi lers, and prior to this, he developed CPlJ p erformance simu lation

software in the VAX Architecture Group. He rece ived a R.S.E.E. (m agna cum
l aude , 1982) from the U n iversity of Connecticut and jo i ned Digital in 1 983.

Geo rge A. Darcy III

As a senior sofnvare engineer in the Alpha Migration

Too l s G roup, George Darcy has worked on the Man nequ i n Alpha

i\Xl'

simulator,

the VEST binary translato r, and the Translated I mage Environment (TIE) run-time
l i b rary. In his ten years at Digit a l , he has also developed a virtua l disk d river for
t h e Open V MS V'i.O Si'vlP o perating system, sofrware behavioral models of a

end VA X processor, and various simu lation and

CAD

h igh

software tools. George

received a fi.S.CE. (cum laude, 1 984) from Boston Un ive rsity, where he was an
Engineering Merit Scholar and a member of Ta u Beta Pi .

Caroline S. Davidson

Since joining D igital in 1981 , Caro l i ne Davidson has

co n tribu ted to seve r a l software projects, primarily related to code generatio n .
Currently a pri ncip al software engineer, s h e is wo rking on t h e
generator p roj ec t

GE:VI

co mpi ler

and is responsible for the areas of I ifeti mes, storage al locat ion,

and en try-exit c a lls. Caro l ine is also a project leader for the I n tel code generation
effort. Her prior work i nvolved the VAX
Generator, and

FORTRAN IV

FORTRAN

for

lHTRIX, VAX

Code

software products. Carol i n e has a H.S.C:.S. from the

State University of New Yo rk at Stony Brook.

7

Biogmpbies

Daniel E. Dever

Dan Dever received a B S E . E. degree in 1988 from the

Universi t y of C i ncinnati. He joined D igital 's Semiconductor Engi neering G roup
i n 1 988, where h e worked on the design ancl logic ve rification of CMOS VAX
microprocessors. Si nce 1990 he has been involved i n the design of RISC architec
tu re microprocessors, i n c l u d i ng the floating-point u n i t of the DECchip 2 10()4
microprocessor. Dan is c urrently involved in the design of integer arithmetic
logic fo r the next-generation processor based on the Alpha AXP arch i tecture.

Daniel W. Dobberpuhl

Dan Dobberpu hl received a B.S. E . E . degree from the

Un iversity of Il l inois in 1967 Subsequent to p ositions with the Department of
Defense and General Electric Company, he joi ned Digita l 's Sem iconducto r
Engineering Group i n 1 976. Since that t i me , b e has been act ive i n the design of
fou r generations of microprocessors, including t he fi rst single-chip PDP-1 1 and
the first single-ch ip VAX . Most recen t ly, D a n was the project l eader for the first

VL'il im plementation of Digi ta l 's new 64-bit Alpha AXP com p u t i ng arch itect ure.
He is coauthor of the tex t, The Des(!{n and A nalvsis of Vl.SI Circu its.

Todd A. Dutton

A principal hardware engineer, Todd Dutton was responsible

for the overa l l design integra t i o n and timing verification of the OEC 3000 A X I'
Model 500. Prior to this, he led a team i n developi ng vector processor h a rdware
in the Advanced VAX Development G roup. To dd join ed D igita l in 1987. Pre
vious ly, he was employed at Numerix Corporation and at Signal Processing
Systems, Inc. Todd has a l i S. degree in compu ter science from the Massachusetts
Institute of Technology and was elected to Tau Beta Pi. He holds a patent on vec
tor processor technology and has published two papers on vector p rocessors.

Daniel Eiref

Dan Eiref j oined Digital i n 1987 after receiv ing BS and :.1s.

degrees in electrical engineer i ng from Columbia Un iversity. At Colu mbia l1e was
elected to Tau Beta Pi and was awarded rhe Steven Abbey Ou tsta n d i ng Stu d ent
athle te Award. He is c u rren t ly attendi ng Harvard Busi ness School. A principal
hardware engineer, Dan was responsible for the design of the memory and clock
syste ms of the DEC 3000 AXP Model ')00. He a l so designed the workstati o n 's

S LI CE and

ADDR ASIC:s. Prior to this project , he worked as an ECl hardware

designer in the Advanced VA X Devel opment Group.

R. Neil Faiman, Jr.

Ne i l Fa iman is a consu ltant software engin eer in the
Software Development Technologies G roup. H e was the primary archi tect of the
C EM i ntermed iate language a nd a project leader for the c ; EM com p i ler optimizer.

Prior to this work. he led the BUSS compiler project. Neil came to D igital in 198:�
fro m MDSI (now Sch l u m berger/Appl icon). He has FlS. ( 1974) and :VI.S. ( 197'))
degrees in computer science, both from M ic h igan State U n iversity. Neil is a mem
ber of Ta u Beta Pi and ACM , and an affi l i ate member of the IEEE Computer
Socie ty.

8

Bruce Gieseke

Bruce G ieseke received a H . S. degree i n electrical engineering

from the U n iversity of C i ncin na t i in 1984, a nd an .'vi .S. degree in electrical engi
neering from North Caro l i n a State Un iversity in 198'). I n 1986 he joined Digit a l 's
Semiconductor Engi neeri ng Group , where he has been engaged in the i m ple
mentation and circ u i t design o f RISC m i c roprocessors.

Kent D. Glossop

Ken t Gl ossop is a principal engi neer in the Software

Developme n t Technologies Group. Since 1987 he has worked on the GEM com
p i ler system, focusing o n code generation and i nstruc t io n - level transformations.
Prior to this, Kent was the project leader for a release of t he VA X PUI comp i ler
and contri buted to versio n I of the VA X Performa nce and Coverage Ana lyzer.

Ken t j o i ned D igital in 1983 after recei v i ng a H . S. in computer science from the
U niversity of Michiga n . He is a member of IEEE.

Richard B. Grove

Senior consu l tant software engi neer Rich Grove j oined

Digital in 1971 and is currently i n the Software Development Technologies
Grou p . He has led the G EM compiler project s i n ce the effort began in 1985. con
tributing to the code generation phases. Prior to this work, Rich was the project
leader fo r the PDP-1 1 and VAX FORTRAN compi lers, \vorked on VAX Ada V 1 , and
was a member of the ANSI X3.J3 FORTRAN Commi ttee. He is presently a mem ber
of the design team for Alpha AX!' ca ll i ng standards and architecture. Rich has B.S.
and M . S. degrees in mathematics from Carnegie-Mellon Un iversity.

Soha M.N. Hassoun

Soha Hassou n received a B.S E.£. degree from South

Dakota State U niversity in 1986, a n d a n S. M . E.E. degree from the Massach usetts
I nstitute of Tec hn o logy i n 19H8. From August 1988 to August 1991 she was
employed at D igital as a custom design engineer i n the Semiconducto r
Engi n e e r i ng Group. S h e contributed to the uesign of t h e floating-point u n i t o f

tbe D EC ch i p 21064 processor. S o h a was the recipient of a D igital M i n o r i t y and

Women 's Scholarsh ip i n 1991 anc.l i s pursuing a Ph . D. degree at the University of
\'\fashingto n , Seattle. Compu ter Systems Engineering Department.

Steven 0. Hobbs

A member of the Software Developme n t Technolr the in tegrated circ u i t technology in the

DEC

3000 AX.P Model '500 worksta t i o n . Prior to this project wor k , she \Vas a

com

ponent engineer in D igita l 's Semiconductor Busi ness Organiza t i o n .

I ';

niogmphies

Chuck Thacker h as been w i t h D i gi t a l ' s Sys tems Research

Charles P. Thacker

Center s i nce 1 9 H :) B e fo re j o i n i n g D i g i t a l , lle was a s e n i o r research fel l ow at t h e
Xerox Palo A l t o Research Center. His research i n t erests i n c l u d e c o m p u ter arc h i
tecture , com p u t e r n e tworking, a nd compu ter-aided design . He holds seve r a l
p a t e n t s i n t h e area o f com p u t e r o rga n iza t i o n a n d is co i nventor of the Et he r n e t
loca l area network. !n 1984, Chu c k was the rec i p i e n t
Ta y lor) o f t he i\C : M S o ftw a r e System Awa rd . H e

( wi t h

n: c ei ve d

B.

L a m p s on a n d R .

a n A . H . d eg ree i n physics

from the U n i ve r si t y of Ca l i fornia i n 1967. He is a member

of ACVI anci i EEE.

Ben j a m i n Thomas j o i n e d the O p e nV:'I·!S AX P project

Benjamin ]. Thomas III

l/0 su bsvst em design a n d p o rt i ng. In t h is role. he has
l/0 arch i t ect u re of c ur r e n t ami fu t u re AXP syste ms. Ben

in 1989 as p ro j e ct leader fo r
a lso c o n t r i b u ted to t h e

j o i ned Di gital i n 1982 ami has worked i n th e VMS gro u p s i n ce 198 4 . In p r i o r
wo rk, he was the d i rector of software engineering a t a m i cro c omp u te r fi r m . Ben
is a co n s u l t i n g engineer a n d has a H . S. ( 197H) in p h ys i c s from the U n ivers i t y of

New H a m p s h ire and a n J'vi . S C . S. (1990) from Wo rcester Pol yt ec h n i c Insti t u t e .

Catharine van Ingen

A cons u l ting soft w a r e e ngineer, Catha r i ne v a n ln gcn

was co- system arch i t ect for the VAX and DEC:

7000 pro d ucts. Catha rine is cur

re n t l y on leave from Digital and i s wo r k i n g on engi neering document m a n age
m e n t in l a rge he t ero ge n eo u s systems. Before j o i n i n g Di g i t a l i n 1 987. she worked

on data ac q u i s i t i o n systems for t wo l a rge phy si c s detectors a t the Fe r m i N a t i o n a l
Accelerator L a b or a tor y and S t a n ford L i n e a r A ccel e ra t o r Center. She holds sev
eral d eg re e s i n civ i l engineering, i n c l u d i ng

a

B . S. ami an iVIS from the U n ivers i ty

of Ca l i t(>rnia and a P h . D. from t h e Ca l ifornia I n s t i t u t e of Tec h n o l o g y.

Nicholas A. Wa rchol

N i ck Wa r c h o l , a consu l t i ng engineer in the E ntry

1/0 arch i tec t u re
4000 AX I' s y st em s . In pr ev i o u s work,
he c o n t r i b u ted t o the developm e n t of VAX 4000 s y st e m s . He was also a (lesigner
of t he ,\ll icroVAX 3300 and 3400 processor m o d u les :111 d t h e RQ DX3 d i s k con
Systems Bus i ne s s (;ro u p . is t l1e r r oj e c t l e a d e r re sponsible fo r

and

I/O m o d u le development for

the DEC

t rol ler. Nick j o i n e d Digital in 1977 after re c e i v i n g
Worce ster Polytechn i c Institute. He

Richard

T. Witek

a

B.S. E. E. (cum l a u de) from the

19H4 he received a n
has h>ur pa t e nt appl icati ons.

New Jersey I n stitute of Te chnology. In

:VI.S. E . E. from

Rich Witek j o i ned D i g i t a l i n 1977 to work on DECnet

network arc h i tecture d u r i ng Phase II. l n 1982 he j o i n ed D ig i t a l's Semico nd uctor
Engi n eering (�roup w here he worked on C :r\D de v e l o p m e n t , MicroVAX VLSf
ch ips, and a variety of i nte rn al !US C projects. Rich was a c od e s ig n e r of the A l pha

.\XP architectu re a n d the pr i n c i p a l m i croarc h i tect of the DECchip 2 1 064 CPU
c h i p . He re c e iv e d

a H A degree

in com p u t er science from Au r o ra C o l lege. Rich i s

currently e m p loyed by Appl e C o m p u t er, I n c .

l6

I

Foreword
the proposed sol u t i o n hac! to p rovide strong com
patibility with

current pro ducts. After several

months of study, the team concluded that only a
new RISC architectu re cou l d meet t he stated objec
tive of long-term com petitiveness, and that only t h e
exist ing V M S a n d U N I X environments cou.lcl meet
the stated constraint of strong compatibili ty. Thus,
the chal lenge posed by the task force was to design
the most competitive RISC systems that wou ld r u n
t h e curre n t software environments.
Key groups i n Engineering responded to this
chal lenge. A cross -fu nctional team from h ardware

Robert M. Supnik

and

Corporate Consultant,

software

defined

the

basic

architecture.

Advanced development teams began work on the

Vice President

k notty engineering problems: i n the semico nduc

Technical Director;

tor group , the specification and design of a fast

Engineering

microprocessor, and t h e automatic translation of
executable binary im ages; in t he operating systems
groups, on the porting of U LTRI X and of VMS (which
was n o t portabl e ! ) ; a n d i n the compiler group, on

It a l l started with eight people in a conference

superscalar code genera tion. ln the fall of 1989,

room.·:·

Alpha became an offi c i a l ly sanc tioned advanced

The

time

was the s u mmer of 1988.

D igital

Equi pment Corpora tion had just closed the best
fiscal year in its history, with record revenues and

development program t I n the s u m me r of 1990, i t
transit ioned t o product development.
From the origi nal core in semiconductors, oper

profits. Digital's VA..'< systems were the most widely

a t i ng systems,

usee! t imesharing systems i n the i n d ustry ancl were

t h roughou t Engineering. The server and work

and compilers,

work

expanded

the " b l u e-ri bbon standard " for mid- range comput

station hardware groups specified and started

i ng. Digital was the second-l argest workstation ven

designing a fam i l y of systems, from clesktop to data

dor. The company had just in trodu ced the VAX 6000

center. The networks group began porting OECnet,

system, its first expandable mu l t iprocessor, was

TCP/I P , X 25, LA'"l', and the many other network

developing a true VAX m a i nfra me, and had decided

i ng products. The layered software group i nven

on a rapid thrust into ru se workstations to capital

toried

ize on that growing market. What coul d possibly go

prioritized the order and importance of del ivery.

wrong'

The research group pitc hed in by Jesigning an

Nonetheless, senior ma nagers and engineers saw
trouble ahead. Workstations had d isplaced VA.."\ VMS
from i ts original technical market. Networks of per
sonal

compu ters

were

replacing

the

existing portfo l io

of products and

experiment a l m u l tiprocessor as a software devel
opment testbecl .
In parallel with the engineering work, market

ti mesharing.

ing, sa les, and service teams worked closely with

Appl ica t i o n investment was mov i ng to standard,

business partners and c ustomers to shape the del iv

h igh-vo l u me computers. Microprocessors had sur

erables and messages to meet external require

p assed t h e performance of trad itional m i d - range

ments. These teams briefe d key cu stomers a n d

computers and were c losing in on mainframes. And

partners e a r l y i n the development process a n d

advances i n !USC technology t h reatened to aggra
vate a l l of these trends. Accordingl y, the Executive
Com mittee asked Engineering to develop a long
term strategy for keeping Digi t a l 's systems compet
i t ive . Engi neering convened a task force to study
the problem.
The task force looked at a wide range of potential
s o l u t i o ns, from the application of advanced pipe
l i n ing techniques i n Vt\.,'\ systems to the deployment
of a new arch i tecture. A basic constraint was that

h e C o ro na

flore a l is conference room in the LT N I bcility i n

Littleton, Mass. LT N l was cl10s e:: n because i t was the geographic
epicenter o f the arc of Digital engineering fac i l ities on ,vbssa

chusct t s Route 49'>, t ile Corona l3oreal is
only c o n ference room with windows.
'After

going

because it was the

r h rough more than one n a me change.

The

original

study ream was called the ""lliSCy VAX "L•sk Force.·· Tile

advanced development work was l aht:led ·· [VAX."" When the

prog•·am

was approved, tile Executive Com m i nce demanded :1

n e u tral code name. hence

""Alpha.'"

17

Foreu •md

incorporated their advice i nto the development
progra m . Ongo i ng panner and customer advisory
boards provided regu l a r feedback o n a l l aspects
of the p rogram ami helped shape two criti c a l
extensi ons o f t h e original concept: t h e o p e n l i cens
ing of Alpha technology. and the port i ng of
Wi nd ows NT.
Ta ken together. the scope of the E ngineeri ng
effon, the need fo r Marketi ng. Fiel d , and Service
i nvo lve ment, ami the h igh degree of customer and
business partner participation, posed unique m a n
agement c h a l lenges. Rather than organ i ze a large
scale h ierarchica l project. the company chose to
manage AJpha as a d istributed progra m . A sm:t l l
program team used enro l l ment ma nagement prac
tices a nd strict operational discip l ine to coord inate
and i nspect activi t ies across the company. This net
worked approach to ma nagement gave the program
both flex i b i l ity ami resiliency i n the face of rapid l y
chan g i n g busi ness a n d o rgan ization a l con d i tions.

lH

The ·wo rk o f Engineeri ng, M a n u factur i n g , Mar
keti ng, Sales, a nd Service came together in Novem
ber 1992 w i t h the annou ncement of the Alpha AX!'
systems fa m i l y : seven systems, th ree opera t i ng sys
tems, six l a nguages, m u l t i p le networks, m igration
tools, o p e n l icensing of techno logy, hardware and
software partnersh ips. and more than 2000 co m


m i t ted a p p l ications. Today, Alpha AXP embo d ies a
fundamental repos i t i o n i ng of D i gi t a l E q u ipment
Corporation to be the technology and solutions
leader in twen ty-first cen tury computing : a com
pany d ed icated ro meeting customers· needs with
the best computing, busi ness, and service technol
ogy available. The del ivery of Alpha r\XI' required
the largest eng i neering program in Digital ·s h istory,
spanning more than twenty Enginee ring groups
worldwide. This iss11e of the Digital Technical
journal documents j u s t a tew of the hundreds of
projects i n volved in b ri ngin g Alpha to fru ition;
future issues wi l l continue the story.

Richard L. Sites I

Alpha AXP Architecture
The Alpba A XP

64- bit computer arc!Jitecture

is designed for higiJ pe!formance and

fongevi(V Because of thefocus on multiple instruction issue, the architecture does
not containfacilities such as branch delay slots, byte writes, and precise arithmetic
exceptions. Because of the focus on multiple processors, the architecture does con
tain a careful shared- memo1y model, atomic- update primitive instructions, and
relaxed read/write ordering. Tbe first implementation of tbe Alpha AXP architec
ture is tbe world's fastest single-chip microprocessor: The DECchip

21064 runs multi

ple opemting systems and runs natiue-compiled programs that u·ere translated
from the E4 X and MIPS architectures.

Thus i n a l l these cases the Romans d i d what a l l
wise pri nces ought to d o ; namely, n o t o n l y to look
to a l l present troubles, but a lso to those in the
future, against which t hey prov ided with the
utmost prudence.
-Niccolo iVbch iavd l i , T/Je Prince

Historical Context
The Alpha AXP architecture grew o u t of a small task
force chartered i n 1988 to explore ways to preserve
the VA X VMS customer base through the 1990s. This

Architecture Distinct
from Implementations
From the beg i n n i ng of the Alpha A X !' des ign, we
disti nguished the architecture from the i m plemen
tations, fol lowing the distinction made by the 113ivl
System/360 arch itects:
Comp u ter arch itecture is defined as the attribu tes
and behav ior of a computer as seen by a machine
language progra mmer. This defin ition includes the
instruction set, instruction formats. operation
codes, addressing modes, and all registers and
memory locations that may be directl y manipu
lated by a machine- l anguage programmer.

group eventua l ly came to the conclu sion that a new
reduced instruction set compute r (RJSC) architec
ture woul d be needed before the turn of the cen
tury, primarily because 32 -bit architectures wi l l run
out of address b its. Once we made the decision to
pursue a new arch i tecture, we shaped it to do
much more than j ust preserve the VMS customer
base.
This paper d iscusses the architecture from a

Tbus, the architecture i s a docu ment that
describes the behav i or of a l l possible i m p l e menta
tions; an i mplementation is typica l ly a single com
p u te r chip. 2 The archi tecture and software written
to the architecture are i ntended to last several

nu mber of points of view. I t begins by making the
distinction between arch i tecture and i m p le menta
tion. The paper then states the overri d i ng archi
tectu ral goa l s a nd d iscusses a n u m ber of key
a rchitectura l decisions that were derived d irectly
from these goals. The key decisions d i s t i nguish the
Alpha AXP arch itecture from other architectures.
The rem a i n i ng sections of the paper d iscuss the
architecture in m ore deta i l , from data and i nstruc

decades, w h i le i n d ividual implementations w i l l
have much shorter l ifetimes. The architecture m ust
therefore carefu l ly describe the behavi o r that a
m ach ine- l a nguage programmer sees, but must not
describe the means by which a particu l ar i mple
mentation achieves that behavior.
A s i m i l ar approach has been used with much
success in specify i ng the PDP-1 1 ancl VAX fa m i l ies of
compu ters. An al ternate approach is to design and

tion form ats t hrough the detai led i nstruction set.
The paper conclu des with a d iscussion of the
designed- i n fu ture growth of the arch itecture. An
Append i x ex plai ns some of the key technical terms
used i n this paper. These terms are h i g h l i ghted
with a n asterisk i n the text.

cessful in the marketplace. If so, successive i m p le
mentations are often forced to reproduce accidents
of the i n i t ia l design, or t o i ntrodu ce s l igbt software
i ncompatib i l it ies. This approach works, but with
varyi ng success.

Digital Teclmical journal

Vol. 1 i\1(). 4

Special f,·we I'J'J.!

Implementation is defined as the actu:il hardware
structure, logic design. and data-path orga nization
of a part i c u l a r embodiment of the architecture . 1

b u i l d a fast RISe" ch i p , then wait to see i f i t is suc

19

Alpha t\.,'1:]> Architecture and Systems

Architectural Goals

D i gi t a l RISC: design c a l led I'IUS M .' We pl aced the

When we start e d the d e t a i led design of the A l p h a

u n d e r p i n nings fo r i n te r r u p t d e l ivery a n d re t u rn ,

AXP a rchit ecture, w e h a d a s h o r t l i st o f goa ls:

exc ept ions. co n t ext swit c h i ng, m e m o r y ma nage
m e n t , and erro r h an d l i ng in a set of p r ivi leged

1. H igh performance

software s u b rou t i nes c a l led l'ALc ode. These s u b
rou t i nes have control led entry p o i nr s , run w i t h

2 . Longevity

3. C1 p a b i l ity to run both VMS a n d U N I X operating
systems

These goa l s d irectly i n f l u e n ced o u r key decisions
in designing the arch i tecture.

In consideri n g p e rfo r m a n c e and l o nge v i ty, we
set a 1 ') - to 2'5 -year design horizon and tried to avoid
any design e l ements t h a t we thought could become
.l i m i t a t i o n s d u r i n g th is L i me. In current a rch itec
a

ware ( i m p lement at ion) registers. By i n c l u d i n g d if
ferent sets

4. Easy migr a t i o n from VA X a n d ,\·l iPS a rc h i tectures

tures,

i n te r r u p t s t u rned o ff, a n d have access t o rea l h ard

p r i m a ry l i m i ta t i o n i s t h e 32 - b i t mem ory

a d d ress . Thus we adopted a fu i i 64-bit archi tecture,
with a m i n i m a l n u mber of 32 - b i t operations for
bac kwarcl compa t i b i l i ty.
We a lso considered how i m p lementation p e rfor
mance shou ld scale over 2') yea rs. D u ring the p a st
25 years, compu ters have become abo u t

I ,000

t i m es faster. Therefore we focused o u r design deci
sions o n a l l ow i ng Al p h a AXP system i m plementa
tions to become 1 ,000 times faster over the com i ng
25 years. In o u r projec t ions of hnure p e r fo r m a n ce ,

of PA!.code fo r d iffe r e n t op era t i n g

syste ms. n e i th e r the harclware n o r t h e operating
system is b urdened with a bad inte rface m a t c h , a n d
the archi tecture i tsel f i s not biased toward a p a r t ic
u l a r c o m p u ting style.
To run exis t i ng VAX and M I PS b i n a ry im ages, we
ado pted the idea of binary transla t i o n , ' as described
in a c o m p a n i o n paper.

' ' 1'

The com b i n a t i o n of

PA!.code a n d b i na r y t ran s l a t i o n gave u s the l uxury
of designing a new a rc h i t ecture. Other t h a n the fun
d a m e n t a l i nteger and floa t i ng-p o i n t data types,
there a re no sp ecific VAX o r Mil'S fe a tures carried
d i rectly i nto the Alpha AXI' i n structio n-set a rchi tec
t ur e fo r compatibi lity reasons.

Key Design Decisions
T h i s sec r i o n pre sents the design decisions t h a t d i s
t i ngu i s h the A l p h a AXP a rc h i te c t u re from o th e rs.

w e reasoned that raw clock rates wou l cl i m p rove by

RISC

a factor of 10 over that t i m e , a n d t h a t other design

T h e Al pha AXP a rc h i tect ure is a trad i t i o n a l R I SC

d i mensi ons wo u l d have to prov ide two m o re fac

l o a d/store a rc h i tect u re . Al l d a t a is moved between
registers and mem ory without computation, and a l l

tors of 10.

If the c l o c k cannot be m a d e faster, then m o re

com p u r a t i o n is done between val ues i n re gisters.

work m u s t be done per clock tick. We t h e refore

L i t tle-end ian byte add ressing a n d both VA X a n d IEEE

designed the Alpha A X P a rch i tecture to e n c o u rage

floati ng-point operations''' arc carried over from the

mu I t i p l e i nstru c t i o n issue'' i m p lementations that

VAX a n d ,'vl l PS architectures . - \Ve assu med that most

wi l l eventu a l ly susta i n about ten new instructions

i mp l e m e n t a t i o n s wou ld p i p el ine instru c t i o n s , i . e . ,

startin g every clock cycle. T h is aggressive tech

they would s tarr exe c u t i o n o f a seco n d , t h i rd , e t c .

n i qu e

d i s t i n

i n s t r u c t i o n befo re the exe c u t ion o f a f i r s t i ns L T u c

gu ishes t h e A l p h a A X I' a rc h i te c t u re from m a n y

tion completes. We assu med t h a t t h e i m p lementa

of start i ng

m u l t iple

i nstructions

tion

o t h e r I{ISC: archi tectures.

latency

of

m a ny

o pe r a t ions

wou l d

be

The re m a i n i ng factor of 1 0 wil l come from m u lti

i m p o rt a n t . Latency is the nu mb er of cycles a pro

ple p ro c essors. A single system will cont a i n per

gram m u st wait to use the re s u l t of a p reced i ng

haps

ten

therefore

processors
designed

a

and

share

We

i ns tr u c t i o n . We assu med t h a t the vast majority o f

memory

m e m o r y o p e r a n d s wo u ld be a l igned . A n a l igned

m e m o ry.

m u l t i p rocessor

m o d e l and m a t c h i ng instructions from

the begin

n i ng . This early accom m o d a t i o n for m u l t i p le pro
cessors

a lso

d i stingu ishes

the

Alpha

AXP

arch i tectu rc from many other RlSC architecm res,
whi ch try ro add the proper p r i m i t ives la ter.
To r u n the OpenVMS A X P a n d the OEC OSF/ 1

opera n d of s i ze 2**N bytes'' has a n ad dre , with
l ow-o rd e r

zeros.

O t her

m e m o ry

oper:111ds

N

are

termed u n a l igned.

Full 64-bit Design
T h e Alpha AX!' arch i tect ure uses a l i n ea r''' 64-bir v i r

AXP-and now the Microsoft Windows NT-operat

t u a l a d d ress s p a c e . Registers, a d d resses, in tegers,

ing sys tems, we adopted a n idea from a previous

floa t i ng-po i n t n u mbers, and c h a racter stri ngs are

20

l in/.

- 1 .\'u.

Special issue /')').!

D(�ilal Tec/Ju ical jourual

Alpha AX.P A rchitecture

a l l operated on as fu l l 6 4 -bit q u a n t i t ies. There are
no segmented addresses.''

Register File
In choosing the register file uesign, we consic.le recl
both a single combined register file and sp l i t integer
and floati ng-point register fi les. We chose a spl i t
register file to support aggressive mul tiple issu e . A
combined file is somewhat more flex i ble, espe
cia l ly for programs that are heav i ly skewed toward
i n teger-only or floati ng-po int- only compu tation. A
combined file a l so makes it easier to pass a mixture
of in teger and floating-point subroutine parameters
in registers. However, spl i t fi les al low gracefu l two
chip i mp lementations and smal ler i nteger-only
im plementations. They also need fewer read/write
ports per fi le to sustain a given amou n t of m u l t iple
instruction issue.
We also considered whether each file should con
tain 32 o r 64 registers. We chose 32, l argely because
I. Th i rty- two registers in each fi le are eno ugh to
support at least eight-way mu ltiple issue .
2 . Two valuable instruction bits are bet ter useu to
make a 1 6 -bit displacement fielcl in memory
format i nstructions.
More registers might seem better, bu t excess reg
isters consu me chip area and access time,
save/restore speed ac ross subroutines and context
switches, and i nstruction bits that might be put to
better use. Compi lers can del iver substantial per
fo rmance ga ins w hen given .'12 registers in stead of
16, but there is no clear ev id ence of s i m i l a r gains
with 64 registers. Demand for registers is l i kely to
increase s lowly in the fu t u re, bu t a number of
im plementation techniques, such as short l atency
pipel i nes and register renaming , sho u ld satisfy this
demand.

Multiple Instruction Issue
Our design sought to e l i m in ate any mecha n ism that
wou ld h inder aggressive m u ltiple instruction issue
implementations. The refore we tried to avoi d a ll
s pecial or h idden processor resources 8 Thus, the
Alpha AXP architecture has no cond ition codes, no
globa l exception enables, no m u ltiplier-qu otient or
string registers, no branch uelay slots, no sup
pressed instructi o ns or sk ips, no precise arithmetic
exceptions, anc.l no single-byte wri tes to memory.
Al l of these featu res, found in some !USC arc h itec
tu res, have the effect of hinde ring mu l tiple i nstruc
tion issue, or h i nderi ng pipe l i n ing of mu ltiple

D igital Tech11icnl jourunl

llr>l.

4 No. 4

Special Issue / 'J 'Jl

i nstances of the same in struction. For example, a
ded icated string register makes it hard to have three
unrelated string operations in the pipel ine at once.
To i l l ustrate the performance loss associated
with speci a l or h idden processor resources, con
sider a dual-issue implementation with a fou r-cycle
deep pipeline. At the begi nning of each cycle, up to
six prior instructions are part ia l ly executed a n d
two more are about t o b e issued . Six p r i o r instruc
tions can have six pending writes to res u l t regis
ters, plus six sets of side effects on speci a l or
hidclen processor resources. The next two i nstruc
tions can specify a total of fou r operant! registers,
two more resu lt registers, and two more sets of side
effects on sp ecial or h idden resources. The decision
to issue 0, I , or 2 of the next i nstructions i nvol ves
36 s imple comparisons of pairs of register numbers
and 12 complex comparisons of sets of side effects.
The nu mber of such comparisons increases as a
function of the issue width, the pip e l i ne depth, and
the n umber of special or b idden processor
resources. The comp lexity of these comparisons
can l i m i t the c lock rate . The register-nu mber com
parisons are unavoidable, therefore we tried to
l i m i t special o r h iuden p rocessor resources.

Branch Delay Slots The Alpha AXP archi tecture
has no branch delay s lots. The branch delay slots
fou n cl in some !USC architect ures require exactly
one fol low ing instruction to be execu ted after a
cond ition al branch. ln 19 88 this was, perhaps, a
goocl idea for overl apping branch l a tency i n a sin
gle-issue ch ip with a one-cycle instruction cache. In
1995, however, it wil l not scale wel l to a fou r-way
issue chip with a two-cycle i nstruction cache.
Instead of one instruction, u p to eight instructions
wou lcl be needed in the cle lay s lot. Branch delay
slots also introduce a restart problem if the i nstruc
tion in the delay slot fau l ts: one restart program
counter is needed fo r the delay slot and another one
for the actual branch target.
Suppressed Instructions The A lpha AXP a rchi tec
ture has no suppressed instructions, wl1ereby the
execution of one instruction co nditionally sup
presses a fol lowing one. Supp ressed (or skipped)
i nstructions are fou n d in other HISC architectu res.
The suppression bit(s) re presen t nonrepl icatecl
hid den state, so m u ltiple in struction issue is diffi
cu l t fo r more than one potentia l suppressor. I f an
interrupt i s taken between a suppressor and sup
pressee, or i f the su ppressee takes a restartable
exception (e .g. , page fa u l t), the correct version of

21

AJpha AXP Architecture and Systems

the suppress ion state must be saved and resto red .

a little more compl icated and a l ittle slower. With

There are also defi n i t i o nal problems with this

n o nrepl icated hid den state, i t is d i ffi c u l t to issue

approach: Are exceptions ever reported for sup

anot her byte store u ntil t he first one fi nishes.

pressed instructions' What happens if the sup
pressed instruction suppresses a t h i rd i nstruction'

Fin a l ly, the existence of a byte store i nstruction has

13yte Load or Store Instructions

The Alpha A X I'

architecture has no byte load or store i nstruc t io ns
and no impl icit u n a l i gned accesses. There also are
no partial- register writes. The byte load/store
instructions and u n a l igned accesses t(nll1 d in some

Jed to programs and l i brary rou t i nes for other ruse

implementations with single-byte move and com
p a re loops, String manipulatio;l on Alpha AXP
i mplementations is up to eight t i mes fastc:r by pro
cessing eight bytes at a time 9
Instead of includi ng byte load/store, we fol lowed
the R ISC phi losophy of exposing h idden comp u ta

!USC archi tectures can be a performance bott le

tion as a sequence of many simple, fast i nstructions.

speed-critical load and store paths, and they force a

In the Alpha A' 0
Con d itional move if reg � 0
Cond itional move if reg low
bit clear
Cond itional move if reg low
bit set
Compare bytes, unsigned
Clear selected bytes
Clear unselected bytes

Add longword
Add longword, scale by 4
Add longword, scale by 8
Add quadword
Add quadword, scale by 4
Add quadword, scale by 8
Compare signed quadword

Branch if reg 0
Branch if reg "F 0
Branch if reg < 0
Branch if reg :::; 0
Branch if reg > 0
Branch if reg � 0
Branch if low bit clear
Branch if low bit set
Branch
Branch to subroutine
Jump
Jump to subroutine
Ret u rn from subroutine
Jump to subrouti ne, ret u rn
=

Floating Point Branch

=

FBEQ

FP

FBNE

FP

FBLT

FP

FBLE

FP

b ranch
branch
branch
branch
branch

FBGT

FP

FBGE

FP branch

if = 0
if ;t 0
if < 0
if ::; 0
if > 0
if � 0
contin ued on next page

Digilal Technict�l journal

Vol. 4 No. 4

Specictl /ssu£' / '}').!

23

Alpha A.,'XP Architecture and Systems

Ta ble 1

Alpha AXP Arch itect u re I n structi o n Set Sum mar y (co ntin ued)

Floating Point Computation
and Conditional Move
CPYS

Copy sign
Copy sign, negate
Copy sign and exponent
Convert quadword to longword
Convert longword to quadword
FP cond itional move if reg = 0
FP conditional move if reg tc 0
FP conditional move if reg < 0
FP cond itional move if reg � 0
FP cond itional move if reg > 0
FP conditional move if reg 2 0
Move from FP control register
Move to FP control register
Add F format fYAX sing le)
Add G format 0/AX double)
Add S format (I EEE single)
Add T format ( I E E E dou ble)
Compare G format =
0/AX double)
Compare G format <
0/AX double}
Compare G format ::;
0/AX double}
Compare T format =
(IEEE double)
Compare T format <
(IEEE double)
Compare T format ::;
(IEEE double)
Compare T format
unordered (IEEE doub le}
Convert G format to quadword
0/AX double}
Convert quadword to F format
0/AX single)
Convert quadword to G format
fYAX dou ble}
Convert D to G format
0/AX double/double)
Convert G to D format
0/AX dou ble/double)

CPYSN
CPYSE
CVTQL
CVTLQ
FCMOVEQ
FCMOVNE
FCMOVLT
FCMOVLE
FCMOVGT
FCMOVGE
M F_FPCR
MT_FPCR
ADDF
ADDG
ADDS
ADDT
CMPGEQ
C M PG LT
C M PGLE
C M PTEQ
C M PTLT
CMPTLE
CMPTUN
CVTGQ
CVTQF
CVTQG
CVTDG
CVTGD

i n s t r u c t i o n s in the f i rst A l p h a A XP imp l e m e n t a t i o n

l ower s p er fo rm a n ce ;) p e rce n t ro 25 perc e n t in real

CVTGF

Convert G to F format
0/AX double/single)
Convert T format to quadword
( I E E E dou ble}
Convert quadword to S format
( I E E E sing le)
Convert quadword to T format
(I E E E double)
Convert T to S format
( I E E E double/single)
Convert S to T format
(IEEE si ngle/double)
D ivide F format fYAX sing le}
D ivide G format 0/AX double)
D ivide S format ( I E E E single}
D ivide T format (IEEE double}
M u ltiply F format 0/AX single}
M u ltiply G format 0/AX double}
M u ltiply S format ( I E E E single}
M u ltiply T format ( I E E E dou ble)
Subtract F format 0/AX single)
Subtract G format fYAX double)
Subtract S format (IEEE single)
Subtract T format (I EEE double)

CVTTQ
CVTQS
CVTQT
CVTTS
CVTST
D IVF
D IVG
D IVS
D I VT
M U LF
M U LG
M ULS
M U LT
SUBF
SUBG
SUBS
SUBT
System
CALL_PAL

Call privileged a rchitect u re
l i brary
Trap barrier (precise exception)
Prefetch (cache) date h i n t
Prefetch (cache) data,
mod ify h i nt
Memory barrier (seriali ze)
Memory barrier (serial i ze) write
Read process cycle counte r
Read and clear
Read and set

TRAPS
FETCH
FETCH_M
MB
WMB
RPCC

RC
RS
PALRESO

PALcode
PALcode
PALcode
PALcode
PALcode

PALRES1
PALRES2
PALRES3
PALRES4

reserved opcode 0
reserved opcode 1
reserved opcode 2
reserved opcode 3
reserved opcode 4

Sbared-JJWJJIOIJ' flllultiprocessing
The

Alpha

AXP

arch i tectu re's

s h a red- m e mory

f lo a t i n g- p o i n t programs ami k�s t ha n 1 p e rc e n t in

m u l t i pro cessing m o d l· l is an i n teg r a l parr o f the

i nteger p rograms, but i m r ro ves cycle t i m e a p p roxi

desi g n . I t is not the a d d o n fo und i n o th e r RISC

m a tely 1 0 percent.

arch itcctu res.

In co n t r as t to arithmeti c ex c ep t i o n s , nH:m ory

-

TL1c u n d t> r l � ing p ri m i t i v e for safe updat i n g of

managcmcnr excep t i o n s, s u c h as page fa u l ts, are

a

r epo r t ed p rec i se ]\'. Th i s is not as m u ch of a b u rden

s e qu e n c e of Rtl: i nstru c t i o ns load- locked , i n - regis

o n i m p l e m e n te r s

as

p rec i s e a r i thmet i c exce p t i o n s

w o u l d b e , a n d l ac k of precise memory management

fa u l ts wou ld

be

a

severe b u rd e n o n software

m u l t i processor-sh ared

memory locat ion

is a

tn m o d i h . store-co n d i t ion a L t e s t . If t h i s sequence
complete� w i t h no

i n t er r u p t s n o exceptions, a n d
,

n o i n t (.' r fcring \N ritc from a n ot h e r processor, t h e n

wri ters.

t he s to re- conditional ston:s t h e m o d ified res u l t ,

24

\ i ll.

1

\u. ·i

\jwcictl lssll<' I 'J'J.!

D ip, i t n l Tecbnical journal

Alpha AXP Architecture

and the test i n d ica tes su ccess: a n a t o m i c u p date

arc h i tecture cl iffers from other RlSC arch itect ures

was in fact pert(>rmed.

by care fu ll y spec ifying a c a n o n i c a l for m for 32 -bit

If anything goes wrong, tbe store- c o n d i t i o n a l

data i n 6 4 - b i t reg isters. A canonical fo rm i s a stan

d o e s n o t store a resu l t . a n d t h e t e s t i n d icates fa il

dard ized choice of data repre sentation for red u n

u re. The p rogra m must t h e n retry the sequence

d a n t l y enc oded v a l u e s . S i n ce 32 -bit operations

u nt i l it su cceeds. We chose t h is pri m i t ive sequence

assume canon i c a l o p e rands and give c a n o n i c a l

MIPS R4000 c h i p desig n5)

resu l ts, v e r y few expl i c i t co nversi ons between :)2-

(qu ite s i m i l ar to the

because it can b e i m p l em e nted i n a way that scales

a nd 64-bit rep resentations are needed.

up wi t h processor pe rf"() r m a n c e . ln the absence of

The fu ndam e n t a l u n i t o f data in t h e Al pha AXP

a n i nt e r fe r i ng write, the e n t i re sequence can be

a rc h itectu re is a 64-bit quadword . ' ' As show n in

done in a n on-chip write-back cache, and h u n d reds

figure l , qu adwords may reside in memory or regis

of ch ips can d o non i n t er fering sequences simu lta

ters.

neous ly. The sequence can also be used to acl1ieve

won l s':' may also be stored in m e mory

The Alp h a A X P architectu re h a s no strict m u l t i
read/w rite

o rderi ng,

w h e reby

:)2-bi t long

There are t h ree fu ndamental clara types: integer,

byte gra n u larity'' o f wri tes i n shared memory -'•
processor

For backwards c o m p at i b i l i ty,

the

I E E E floating p o i n t , a n d VAX floating poi n t; each
is ava i lable i n 32-bit a n d 64-bit for m s. 1 1 2 VAX floati ng

sequence of reads ancl writes issue.

I n essence, bit<31 > is kept as a

·'fat b i t ." This allows signed i n teger values to be

i mp l e m e n t a t i o n s avo ided pipel i n ed wri tes to m a i n

used d i rectly i n 6 4 - b i t a r i t h m e t i c a n d bra nches.

memo ry, m u l t i b a n k caches, w r i te-bu ffer bypassing,

This canonical for m i s m a i n t a i ned as a closed

rou t i ng networks, crossbar m e m o ry i n terco n n e c t ,

system (even fo r :32 -bit data considered to be

et c . , t o p rese rve strict read/write o rdering. The

" u nsigne d '') by using a c o m b i n a t i o n of 6 4 - b i t oper

Alpha AXP arc h itectu re's s h a red-memory model

ates, :)2-bit add/subtract/m u ltiply, and two- in struc

in stead specifies n o imp I icit orde r i ng between the

tion sequences fo r s h ifts.

reads and wri tes issued o n o n e p rocessor, as v iewed
by a d ifferent processor. This progr a m m i ng model

The

canonical

fo r m

of a

32 - b i t

value

in

a

64-bit floati ng-po i n t register has the 8 - b i t exponent

I I bits and tbe 2 3 - b i t m a n t issa

is a n enab l i n g techno logy fo r a wide variety o f h igh

field exp a n ded to

performanc e i m plementation t e c h n iques.

fie ld expanded to 52 bits. Except for I E EE d e n o r

S t r ict

o rdering can be specified \Vhen needed by in sertion

m a l s , ' ' this a l lows s i ng l e-precisi o n float ing- p o i n t

of expl i c i t memory barrier (:VIR) inst r u c t ions, qu ite
s i m i l a r to the JB,vl System/370 serialization design . 1 1

va l ues t o b e u s e d di rect ly in double-precision arith
metic a nd branches. This canonical fo rm is m a i n
tai ned as a cl osed system by using si ngle-precision

Data Representation
and Processor State

i nstructio ns.
Bytes ami words (16-bit quanti ties) are not funda

T h i s section descr ibes the fu ndamental Alpha A X P

mental

data types and their re pre s e n t a t i o n i n memory a n d

between

data

types.

m e m o ry

They
a nd

may

be

registers

t ra nsfe rred
with

s hort

registers. It a l s o describes the com plete h a rdware

sequences of i nstructions a nd man ipu l ated in regis

register state for each p rocessor ami

ters using n o r m a l a r i t h m e t i c a n d t h e byte-m a n i p u

the

additional

state

m a i n t ai ned

by

o u t l i nes

op erati ng

syste m - speci fi c PA I.code rou t i n e s . The A l p ha AXP

Digital Tee/mica/ jou rnal

Vol.

-i .\'u. -1

SjJecia/ lssue 1')'-)l

l a t io n

i nstructions

desc ribed

in

the

Operate

Instructions secti o n .

25

Alpha AXP Archi tecture and Systems

QUADWORD INTEGER (MEMORY)

63

El

0

I Fl

63

1

IEEE
(MEMORY)
63
MANTISSA
81 EXP1 1
52
VAX G-FLOATING (MEMORY)
63
M2 �I EXP
M3
I M416
16 1 11
16
LONGWORD INTEGER (MEMORY)
T-FLOATING POINT

POINT

1�1
1

I E EE FLOA NG
$-

�I

TI

1

POINT

0

8

63

I H 11XP

QUADWORD INTEGER (REGISTER)

0

63
I E EE T-FLOATING POI N T (REGI STER)

0

I M14 1
0

0

I

31
(MEMORY)
MANTISSA I
23

IRX

I

52
(REGISTER)
M4 I
M3
52
(REGISTER)
IRX
lsi
31
(REGISTER)
oooooooooooo_ooooo. .o�� F
52 ________ _____ x

MANTISSA

E

0

EXP

63

63
H1 1XP1 IM 11 M2
LONGWORD
63
1 sssssssssssssssssss
32
I E EE
6
��:1+lx_x�I_E_x_P+1----M-A_N_T_Is_s_A

VAX G-FLOATING POINT

FX

0

FX

E

INTEGER

s

0

1

$-FLOATING P O I NT

�__

__
__

1 1

VAX F-FLOATI N3G1
VAX F-FLOATI N G (REGISTER)
63
��--_M_2 _._Is�I__xE_P_._I__
M 1 ..JI lsjxxl I M1 I M2
ooooooooooooooooo . o
16
52
POINT ( MEMORY)

POINT

O

EXP

__
__

8

7

Figure 1

1

11

Data Representation

The hardware processor st·ate, shown i n Figure

2,

Hard wa re

of

state

reg isters

o p t iona l l y

R:3l i s a lways zero. There a r e a l s o :)2 floati ng- p o i n t

prefetcll ing (F ETCH/FETCJ-I_;vl i n s t ru c ti o n s ) , a n d an

regis ters FO . . f:)l of 6 4 b i t s eac h : F .31 is always zero.

o p t i o n a l i n terru p t flag for use o n l y by t r a n s l a ted

Writes to R:)l and F3l are ignored .

VA X openV.viS AXP programs r h a t repro d u c e com

word-aligned v ir t u a l byte a d d ress ( i . e . , tl1<.: low 2

p a ir

may

i n clude

A 64 -hit program cou n te r (PC) c o n t a i ns a long

a

implementations

i nc l u d es :)2 i n teger registers RO .. R:)l of 64 hits ea c h :

plex i ns t r u c t i o n set computer

for

(ClSc*)

memory

instruction

atomicity u s i ng a sequence of RISC i n st r u c t i o n s.''

b i t s of t h e PC are a l ways zero). The VA X arch i tecture

In a d d i t i o n to t h e above h a rdware state, the p r i v i 

keeps t h e PC i n general reg ister 1 5, \V here i t is

Jegnl arch i te c t u re l ibrary ro u t i nes fo r t h e various

d i rec t l y used fo r PC- relative memory ad dress i ng . In

o p e r a t i ng svstems i m plement add i t i o n a l state. Th is

the AJ pha r\XP a rc h i tecture, however, code and data

s t a t e may be maintai ned by h a rdware o r (I'AI.code)

pages are usu a l ly separated by 64 k i l obytes ( K ll) o r

soft ware, at the op t i o n of the i m pl e m e n t e r. ami i t

more to a l low separate m e m o ry protec t i o n , b u t t h e

varies

16 - h i t d is pl ac e m e n t i n load/store i ns t r u c t i o n s can

Ty p i c a l PA I .c o d e state i n c l udes a processor s t a t u s

n o t span m o re than 64KB.

(PS) word , k e rn e l a n d u s e r stack poi nters, a process

The hardware processor state i ncludes a lock fbg

fro m

one

o p e ra t i ng sys t e m

to a n o t h e r.

cont ro l block base fo r context switchi ng, a process

load

u n i q u e v a l u e for t h reads, a n d a p rocessor n u m be r

It also has a

for m u l t i p rocessor d is p a t c h i n g . Add i t i o n a l PA Lcode

float i ng-p o i n t c o n tro l register c o n t a i n i ng t h e I E E E

state may i n c l u d e a flo a t i ng- p o i n t enabl e bit, i n t er

d y n a m i c roun d i ng mode.'''

mpt

26

\'of. 1 ,\ u. -1

and

a

locked

physical

add ress

locke d/store- c o n d i t i o n a l sequence.

for

the

p r i o r i ty

l evel,

and

.\f!C'cial lssue f'-)')J

tran s l ation

l o o k-aside

D igital Tecbnical journal

Alpha A XP Arcbitecture

HARDWARE STATE

�

0

�

0

---: --1
- �::� ____1__..;, lr--1�-:l�------�F�3�1�,A�L�w�:���zE�R�o�)�---I
R30 (STACK POINTER)

R31 (ALWAYS ZERO)

0

PC

20

63
LOCKED PHYSICAL A D D R ESS

D
D

I E E E FLOAT I N G - P O I N T DYNAMIC R O U N D I N G MODE

LOCK_FLAG

OPTIONAL HARDWARE STATE

D

P REFETCH STATE B

P R EFETCH STATE A
INTR_FLAG
TYPICAL PALCODE STATE
PS

D
[§]

K E R N E L STACK POINTER

USER STACK POINTER

PROCESS CONTROL BLOCK BASE

PROCES S - U N I Q U E VALUE

(

WHO AM I PROCESSOR N U M B E R )

FLOATING-POINT E N A B L E ( F E N )

1
T

INTER R U PT P R IORITY LEVEL

I-STREAM T R A N S LATION BUFFER

Figure 2

1 1
T T

the PA Lcode rou ti nes for a specific operati ng
syste m . I n a m u l t iprocessor implementation, a l l of
t he above state is re plicated for each processor.

Memory Access
Alpha AXP memory is byte addressed , using the .low
est - n u mbered byte of a datu m . Only a l igned l o ng
words or quadwon.ls may be accessed: an a l igned
longword i s a fou r-byte datu m whose address i s a
m u ltiple of fou r ; an a l igned quadword is an eight
byte datum whose address is a m u ltiple of eight.
Normal load or store i nstructions t hat specify a n
u n a l igned address t a k e a precise d a t a a l ignment
trap to PALcode (whi c h m ay clo the access using

Vul. 4 No.

4

1
T

Pe1'processor State

bu ffers for mapping i nstruction-stream and data
stream v i rt u a l addresses. Al l of this state i s soft i n
t h e sense t h a t i t i s defined o n l y in rel ationship to

Digitnl Tecbuicnl journnl

D-STREAM TRAN SLATION B U F F E R

Speciul lssue !'}').!

two a ligned accesses or report a fatal error, depend
ing on the operating system design).
Alpha AXP i m p lement ations a l low data to be
accessed using either :.t l it tle-end ian'' view (byte 0 is
the low byte of a n i n teger), or a big-endian''' v iew
(hyte 0 i s the h igh byte of an i nt eger). As described
i n the Load/Store Instructions section, there is a
one-instru ction bias in the sequences for l ittle- and
big-endian byte manipu lation.
Virtual addresses are a fu l l 64 bits; i m p lementa
tions may restrict addresses to have some nu mber
of identical h igh-order bits, but must a lways distin
guish at least 43 bits. Virtual addresses a re mapped
in a n operating-specific way to physical add resses,
using fixed-size pages. Mem ory protection is clone
on a per-page basis. Add ress mapping errors (e.g. ,
protecti o n , page fa u l ts) rake precise traps ro

27

Alpha AXP Architecture and Systems

I'A Lcode . Each p age may a lso be m a r ked to p rovide

The

a fLt ult o n each read . write, or instruct ion-fetc h .

extension), l i tera l , or d isplaceme n t fields. To m i n i

rem a i n i n g

bits

contain .fu n ct i o n

(opcode

Virt u a l addresses m ay h e fu rt her q u a l i fied by

m i ze register fi l e ports i n fast implemen tations, Rll

ad(lress space n umbers (AS.\. s). to a l l ow m ul t iple

on a per-page basis. Each i m p l e mentation may have

is never wri t te n , and RC is never rea d .
AJ I t h e operate i n s t r u c t ions a r e t h ree-operand
register-to-register, c a l cu lating RC RA operate R8.
In i nteger operates, the opcode and a 7- b i t function
field specify the exact operatio n . I nteger opera tes
may have a n 8-bit zero-extended I i t era! in stead o f

a page s ize of 8KB, 16K K , :)2Kil. or o .:i K B . The (J 1 r.:: K

R B . I n f l o a t i ng- p o i n t operates, the opcode a n d an

d is j o i n t add resses spaces. T h e choice of d is j o i n r or
c o m m o n mapping across all p rocesses is done on a
per-page basis.
The virt ua l - to physical-add ress m a p p ing is done

upper bou n d al lows a l i n k e r to a l locate blocks of
memory with d i ffering prote c t i o n or ,\� '\ p r o p e r
ties far enough apart to work on a l l i m p lementa
tions. The virtual- to physical·a(iti rc·s� m a p p i ng can
be many to one, i.e . . synonyms arc a l hl\\·ed . I n a
mu l t iprocessor i mp lemen tation, shared m a i n mem

==

1 1 - b i t fun c t i o n field specify the exact o p e ra t i o n .

There a rc no floati ng-p o i n t l i terals .
.Vle m o rY fo rmat instruct ions a re u sed for loads,
stores. a n d a kw m isce l l aneous operations. Loads
and s to res a re two-operand instructions, s pec ify in g
a r egis t er RA and a base-d isplacement virtual byt e

ory l ocat ions have the same physica l a d d ress o n a l l

a d d ress. The effective a d d ress ca lcu l a t i o n sign

p rocessors. Per-processor u n.� l1a rctl l ocations a re

extcncls t h e 1 6 - b i t d isplacemen t to 64 bits am! adds
the 64-bit Rll b a s e register (ignori ng overflow). The

a l so a l lowed.
Memo ry has l ongword g ra n u l :t r i r y two proces

resu l t i n g v i r t u a l byte address is mapped to a physi

sors may si m u l taneously access adjaccnl lo ngwords

cal address. The misce l l a neous i nstructions make

m u tu a l in t er fe r e nce . 'file load- l o c ked/

o t h e r uses of the RA. R K , and di splacemen t fields.

without

store-con d i tional sequence d iscussed previously can

Branch fo r m a t i nstructions specify a single regis

be used to ach ieve m u l t i p rocessor byte gra n u larity.

ter R.A ami a s i gned t>c- relarive J o ngword d isplace

I n p u t/o u tp u t is memory m a p p e d : some p hys

m e n t . The branch target calc u l ation s h i fts the 2 1 - b i t
a

ical memor\· addresses m a\ refer to 1/0 device

(iispl acemcnt left b y 2 b i t s to m a ke it

registers whose access tr ig ge r s s i de effects (such
as the transfer of data). Side effects on rea ds a re

(not byte) d isplacement. then sign extends it and
adds it to the u pd a ted i>C. Condi ti o n a l bra n ch

cl iscou raged .

i n s t r u c t i o n s test regi ster RA . and u n c o n d i t i o n a l

branc hes write the u p dated PC to RA for subrout i n e

Instruction Formats

l i n kage. T h e l arge lo ngword d isplacemen t a l l ows a

Fo u r fu ndamental instruction t< >rma ts-op erate ,
memo ry, branch, a nd CAI.I._ J>AI.-are shown i n
Pigure :). Al l i n s tructions are )2 bits wide and reside
in mem ory at aligned l o n gword a d d ress es. Each
in stru c t ion contain s a 6 - bit opcode field and zero
to th ree '5 - bit register- n u m ber fie kls. RA, Hll, and RC.

OPERATE FORMAT

31

1312

21

26

LI T ERAL FUNC.
RB
FUNC.
FUNC.
RB

I

RA

6

5

31

6

5

5

DIS PLACEMENT
16

a

few dozen privi

leged arch itectu re l ibrary subrou tines.

31

I

BRANCH FORMAT

21

26

OP
6

31

I

I

Figure .)

2H

s ma l l i n teger speci fying one of

0

16

5

The CALL_PAL in struction has o n l y a 6 -b i t opcode
and a 26 - b i t fu nction field . The fu nction field is a

5

11

I RA I RB I
21

branches arou n d or to other b ra nches.

I N TEGER. LITERAL
RC INTEGER. REGISTER
FLOATING POINT

MEMORY FORMAT

26

OP

Ill 0

range or ± 4Nlll , substantia l l y red u c i ng t h e need for

0

5

1

OP

l o ngword

I

26

OP
6

RA

DISPLACEMENT

5

21

CALL_PAL FORMAT

I

FUNCTION
26

0

I

0

I

Instruction l'o r111als

I 'o /. . j .\'o. . f

. Sjwci{// /ss"'' ! ') <).!

Digitn/ Tecbuicnl journal

Alpha A X P A rchitecture

p l a c i ng it in t he low end of a register with h igh

Operate Instructions
There are five groups of register- t o - register o p e rate

order zeros. A p a i r of EXTxL/EXTxl-1 instruct ions can

i n structions:

byte

p e rfo r m u na l igned loads, p u l l i n g t h e two parts of

m a n i p u l a t i o n , floati ng-po i n t , and misce l l aneous.

a n u na l igned d a t u m out of two quadwords and

All

i nteger

instructions

arithmetic,

operate

on

logi c a l ,

64-hit

quadwords

[) l ac i ng the parts i n resu l t registers. A s i m p le OR
opera t i o n can t h e n combi n e t h e t wo parts i n to the

u n less othe rwise specified.

fu l l dat u m .

lnter,er A rithmetic Instructions

The i n t eger a r i t h

m e t i c i n s t r u c t i o n s are add, subtract. m u l t i p l y, a n d
compare . Ad d , subtract, and m u lt iply have variants
t h a t enable a r i t h m e t i c overflow traps. They a l so
have lo ngword variants that c he c k for :)2 - b i t over
flow (i nstead of 64) a n d fo rce the h igh

33 bits of the

resu l t to a l l equal bit<31 > . Add and subt ract a l so
have sca led v a r i a n t s t h a t s h i ft t h e first o p erand left
by 2 o r
up

3 bits (with no overflow chec k i ng) to speed

sim ple

subscripted

a d d ress a r i t h m e t i c .

The

l ! M l i LH in struction (from P R I S M ) gives the h igh 64
bits of a n u ns i gned 128-bit p ro d u c t ami m ay be

T h e insert ( fi \ Sxx) a n d m as k

(1\-lSKxx) instruc

t ions p o s i t i o n new d a t a a n d zero o u t old clara i n reg
isters fo r s t o r i ng bytes. words, and u n a l igned d a t a .
I f t h e Alpha AXP a rc h i tecture w e r e a fou r-operand
one. i nserting and m a s k i n g cou l d have been com
b i ned i n to a s i ngle i nst ruction .
The c o m p a re-byte i ns t r u c t i o n a l lows c h a racter
string search and com pare to be done eight bytes at
a t i m e . The ZAP i n s t r u c t i o n s a l low zero i ng o f arbi
trary p a t t e rn s of bytes i n a register. These i n s t r uc
t i o n s a l low very fast i m p le m e n ta t i o n s of the C
lang uage s t ring rou t i nes, a m ong other uses.

used for d iv i d i ng by a const a n t . There is no i n teger
The fl oat

d i v i de i ns t r u c t i o n ; a software subro u t i ne is used to

Floating-point Arithmetic Instructions

d iv ide by a nonconstant. The c o m p are i ns t r u c t i ons

i ng-p o i n t ari th m e t i c i n s t r u c t i o n s a re acid , subtract,

(0

m u l t ip l y, d i v id e . c o m p are. ami c o nvert. The fi rst

are signed o r u nsigned and w r i te a Boolean resu l t

1. ) to t he target register.

or

fo u r have v a r i a n t s for I E EE a n d VAX floa ting-p o i n t ,
and s i ngle- and d o u b le-prec i s i o n data t y pes. They

The logical i n stru ctions are

Loy,ical Instructions
AND,

OR,

and

optiona l l y

XOR,

with

c o m p l e m e n te d

the

s e c o nd

(A I DNOT,

a l so have variants that ena ble c o m b i n a t i o n s of a r i t h

operand

m e t i c traps a n d t h a t s p e c i fy t h e rou n d i ng m o d e .

O H NOT,

T h e s i ngle- p rec i s i o n instr uc t i o ns write c a n o n i c a l

XOHNOT). The s h ifts are s h i ft l eft logi cal , s h i ft right

64-bit

l og i c a l , and s h i ft r i g h t a r i t h me t i c . The 6 - b i t s h i ft

ro u nd i ng to sing le-preci s i o n ranges. The compare

c o u n t is given by RFl or

a

l i t era l . The c o nd i t i onal

resul t s ,

but

do

ex p o n e n t

i nstruct ions write a Boolean res u l t

checking and

(0 or nonzero)

m ove i nstructions test RA (same tests a s t h e branch

to t h e target register. The convert i ns t r u c t i o n s

i ng i nstruct ions) and c o n d i t io n a l l y move Hll to RC.

transfe r between s i ngle a n d d o u b l e , flo a t i ng-point

These can be u s eel to e l i m i n ate branches i n s h o rt

and i n teger, and t wo fo rms of VA X double (D-float

sequences such as M I N(a ,b).

a n d G - float). A c o m b i n a t i o n of har(i ware a nd soft
ware prov ides fu l l IE EJ: a r i th me t i c . O p e r a t i o n s on

Byte-num ipulation Instructions

The byte- m a n i p

ul ation in s t r u c t i o n s a re used w i t h the load a n d
store u na l igned i n s t r u c t i o n s to m an i p u bte s h o rt
u n a I igned st rings of bytes. Long s t r i n gs shou.ld be
m a n i p u l ated

in

grou ps

o f eig h t (al igned

quad

words) w h enever poss i bl e . The byte- m a n ip u l a t i o n
i n s t r u c t i ons a r e fu n d a m e n t a l l y masked s h i fts. They
d i ffer from n o r m a l s hifts by having a byte count

VA X reserved o p e r a n d s, ''' d i rty zeros,

IEEE denor

m a ls, i n fin i t ies, '" a n d not -a- n u m bers"'' are d o ne i n
software.
There are a lso a few fl o a t i ng- point i ns t ru c t i o n s
that move c l a r a w i t h o u t applying a n y i n t erpretation
to it. These i n c l u d e

a

c o m p lete set of c o n d i t i o nal

move i ns t r u c t i o n s s i m i lar to the i n teger cond i t ional
m oves.

(0 .7) i n s tead o f a bit cou nt (0 .6:1), and by zero i ng
.

some bytes of t h e resu l t , based on t h e data size

iHiscellc meous Instructions

given in the h111ction field .

i ns t r u ctions i n c l u d e : m em o ry p refe t c h i ng i nst ruc

The

m isce l laneous

The extract ( EXTxx) i n s t r u c t ions ex t ract part

tio ns to help decrease memory l a te ncy, a read cycle

1-, 2-, 4-, or 8-byte fiel d from a quadwonl

cou nter i n s tru ction fo r p e r f o r m a nce measu remen t ,

a n d rlace the resu l t i ng bytes in a fie ld of zeros. A

a t r ap barrier i nstru c t i o n for fo rcing precise a r i th

s i ngle EXTxL i n s t r u c t i o n can p e rfo r m byte or word

m e t ic traps, a n d m e m o r y harrier in s t r u c t i o n s for

loads, p u l l i n g the d a t u m out of a quallword a n d

fo rcing m u l t iprocessor read/write orderi ng.

of a

Digital Tecbnica/ journal

l'ri/. 4 No. 4

.SjJecio/ lss/11' /<)').!

29

Alpha AXP Architecture and Systems

Load/Store Instructions

conditional m oves, the architecture contains h i n ts

Tile load and store instructions o n l y move data.

to i m p rove branching performance.

Tiley never apply an i n terpret ation to the data ami

The i nteger cond itional branches test register RA

therefore never take any data-depe ndent traps. Th is

for an opcode-sp e c i fied cond i t i o n (>0 >=0 =0 ' =0

des ign a llows mov i ng completely arbit rary hit pat

<=0 <0 even odd) and e i t her branch to the target

terns in and o u t of registers and al lows com pletely

add ress or fa l l through to the u pdated PC address.

transparent saving/restO r i ng of registers.

The floating-poi n t c o n d i tional branches are t h e

The i nteger l oad ami store quad word una! igned

same, except they d o n o t i n c lude even/odd tests.

i nstructions ignore the low t h ree

Arbitrary testing (and fa u l t i ng on VAX or IEEE n o n fi 

bits of the byte add ress and always transfer an
al igned quadword . These in structions are used

n ite va l ues) can b e cl o n e by sequences of compare
instructions and branch instructions. Logical or

with the i n - register byte m a n ip u lation i nstructions

a r i t hmetic

to operate on byte , word. and unal igned clara by

resu l ts without using branches.

( LDQ_l l , STQ_U)

RA for subroutin e l i nkage a mi branch to the target

sequence for load ing a byte i n to the low end of a

address.

regis ter,

needed .

u s i ng

l i t t le-endian

byte

n u m bering.

compare

nco n d i t i o n a l branches write the upda ted PC to

short sequ ences of ruse in structions.
Example 1 i n Figure 4 shows a t wo-i nstruction

instructions can combine

RA

=

R :) l may be us ecl

if no l inkage is

Exam ple 2 shows a similar sequence for load i n g a

Calcu lated j u m ps write the u pdated PC to RA and

byte i nto the high end of a register, using big-endian

j u mp to the target address in Illi . Ca l c u lated jumps

byte n u mbering. Example 3 shows a sequence for

are used for subro u tine cal l , retu rn, CASE (or

sroring a byte (the first two and last t wo i nstru c

SWITCH) statements, and corou tine l i nkage.

t ions m ight issue simu l taneously on the first Al pha

The arch itectu re specifies th ree kinds of branch

A X I' i mple mentation). Example 4 shm.vs a sequence

ing h i n t s in i nstructions. The h i nts need not he

for an exp l icit u nal igned load quadwonl (no data

correct, but to the extent that t hey are, i mplemen ta

a l ignment trap).

t ions may perform faster.

The i n teger loacl-lockecl and store-co n d i tional
( l .DQ_L,

LDL_L,

STQ_C,

in structions are

STL_C)

inclu ded in the arch itectu re to faci l i tate atomic
u pda tes

of

described

m u l t iprocessor-shared

above,

pred iction

rule:

forward

conditional

branches are pred icted not- taken, and backward

As

ones taken. 'T(J the extent that compilers and hard

short

ware i mplementers fol low this rule , program s can

data.

they can be used i n

The first fo rm of h i n t is an archi tected static
bra n c h

instructions to do atomic read

run more quickly with l it tle hardware cos t . T h is

mod i fy-wri tes. Example 5 shows a sequence for

h i n t does not e l i m i nate the use of dynamic branch

seque nces of

RISC

doing a m u l.tiprocessor test -and-set.
changing the

LDQ_U!STQ_l l

in

Note that

Exa m ple

:)

to

prediction in an i m ple mentation, but it may red uce
the need to use it.

A N D/ LD Q_L!STQ_C/BEQ gives a byte-store sequence

The second form describes com p u ted j u m p rar

that is safe to use w i t h m u l t iprocesso r-shared data.
There are two rel ated load address i nstructi ons.

gets. Un used i nstru ction bits are defi ned to give t h e
l o w bits o f t h e most I i kely target, u si ng the same tar

I.DA calculates the effective add ress and writes

get ca lcu l a t io n as u ncond it io n a l branches. The 14

i t i n to RC. LDAH first shifts the di splacement
left 16 bits, then calcul ates the effective address

offset within a page , which is often enough to start

ami writes i t into RC . LDAH is incl uded to give a silu
ple way of creat i ng most .�2 -bit constants i n a
pair of instructions. (Because
the

displacement,

some

LDA

val ues

in

s ign-extends
the

range

bits provided are enough to specify the instruction
a fastest- leve l instruction-cache read many cycles
before the actual target v a l ue is known .
The t h i rd fo rm descri bes subro u t i n e and corou
tine returns. By marking each branch and j u m p as

000000007FFF8000 . . 000000007FFFF FFF require

cal l, ret u r n , or neither, the archi tecture p rovides

t h ree i nstru c t i o ns. ) Constants of 64 bits are l oaded

enough infor m a t i o n t o m a i n t a i n a s nu l l stack of

with

l.DQ

l ikely subrou t i n e return a d d resses w i t h i n a n i m p le

instructions.

mentation. This i m plementation stack can be used

Branching Instructions

to prefetch subroutine returns quickly.
cond itional

The conditional move instructions (discussed

branches, uncon d i ti o n a l branches, and calcul ated

prev i ou s l y in the Logical Instructions section and

ju mps. In a d d i t i o n to t he p reviously described

the Floating-p o i n t Arith metic Instructions section)

:)0

Vol. 4

The

branch

i nstructions

incl u de

Nu.

4

-Vieciol lssue I1

STQ_C R2,0 ( R 1 )
BEO R2,CONTENTION

Figure 4

Digilal Technicaljounwl

Vol. 4 No. 4

1

I

R2
R3

7

3

4

R2

BYTE R2

EXAMPLE 4 E X P L I C I T LOAD OUADWORD ( U NA L I G N E D , LITTLE- E N D I A N )
LDO_U R2,0( R 1 )

I

STORED?

I

R2

l

R2

I

R3
R2

I

R2

l

o r f11 t u re expansion.

m ising m u lt i p le i ns t r u c t i o n issue.

Sc\Tral o t her soft PA Lcocle reg is ters, su ch as the

I'S or AS1 · . that need on l y a few hits todav are a l lo
cated a full

Supervision
The act i o ns u n d e rp i n n i ng an operating system are

p erfo rm ed in PA J.code s u b rou t i nes and are a flexi
ble

part of t h e arch i tectu re. All async h r ono u s

events, such a s in terr u p ts , exceptions, and m ac h i n e
errors, a r e m e d iated by PA Lco d e routines. PA Lcode
esta blis hes the i n i t i a l s tate o f the m a c h i n e before
exe cu t i o n of the first software instructio n . PALcode
ro u t i n es mell i a t e a l l accesses to p hysical hardware
resources, i n c l u d i ng physical m a i n m e m o ry and
me m o r y- m a pp ed [/0 dev ice re g i s t e r s.
Tll i s design a l lows i m p le m e nters to craft a set of
PA Lc ode rou tines that c l o sely m a t cll an o p e r a t i n g

system design, not o n l y fo r traditional o p e r a t i n g
systems, bu t a l so for sp ecialized e n v i r o n m e n t s such

as rea l - t i m e or h igh l y secure c o m p u t i ng. As new
com p u t i ng parad igms are a d op t ed and new o p e rat
ing systems are created , the Alpha

AXP

architect u re

m ay wel l p rove f l ex i ble enough to accommo(late
them effi c ie n t ly.

In a d d i t i o n to the l'A Lcode

f l c x i b i l ity d i s c u ssed above, exp l i c i t perfo r mance
flex i b i l i t y and i n s t r u c t ion-set flex i b i l i t y exist in
the arc h i te ct u r e.
A rc h i tec tura l fields that are too sm a l l can l im i t

p erfo rm a nce . The Alpha A X P arch i tecture t h e re
fo re h a s manr fiel d s d e l iberately s i zed fo r l a t e r
expansion.
A l t h ough i n i t i a l implemen t a t i o n s use o n ly -H
bits o f virtual add ress. t hey check the rem a i n i ng
21 bi t s , so t h a t soft wa re can run u n m o d ified on
l a t e r i m p l e m e n t at i ons that use (up to) a l l () 4 b i ts .
Furt herm ore, al tho ugh i n i t ial i m plem e n t a t i o n s use
only 54 bits of ph y s i c a l ad dress, t h e arch i tcc ted
table

PA I.code ro u t in es del i ve r except ions to an ope ra t 

i ng

so

system,

i m p rovnl

the

llt: s ign

can

be

grad ual ly

In fact, PA Lcode rou t i n es h>r the data

a l ign m en t l1ave been i mproved i n the Open\ \·IS A XI'
and

DEC OSF/ 1 A X P

o p e r a t i ng syste m s . Some c u r

re n t l y s p e c i fied software exceptions (such as liTE
dcnormal arithmetic) c o u l d be moved i n to PA Lcod c

or hardware.
There a re a n u m b e r of a re as o f i n s t r u c t i o n - s e t
flexi b i l i t y d e s i g n e d i n t o the architect u r e . Four o t
the

6 - b i t o p c o d e s are

n o m i n a i J �-

reserved for

a d d i ng i n teger a n d fl oating-po i n t a l igned

octa

word ( l2H-bir) load/store inst ructions. 1 ' N i ne more

() -bit o p code s re m a i n

fo r

other expansion. W i t h i n

ea ch op c od e , t h e function fie l d c o n t a i ns roo m fo r
fu rther expansion . Fo r e,'a mple. the s c a l e d all d/sub
t ran fun c t i o n s were a d d e d b e t ween p rototyt)C
chip a n d p rod u c t ch i p . The fact that t h e fu n c t i o n
\\li t b i n tl1e IEEE floati ng-p oint fu n · t i o n fiel d ,

The Al ph a A X P arch itecture wi l l surely change

page

b i t s for future expan s i o n .

f i e l d s a r c n o t fu l l y pol iced i s a mi stake .

Future Changes
d u r ing its l i fet i m e .

64

Exception p rocessing can 1 i m it p e r fo r m a nce .

en try (PTE)

for m a t s

and

page- s i ze

c h o ices a l low growth to 48 b i ts. By ex p a n d i n g into

code p o i n t s are nomi n a l l y reserved for dou ble
exten ded '' prec ision ( 1 28-bi t) a r i t h m e t i c . W i t h i n
t h e memory barrier instru ction gro u p , t h ree code
p o i n t s were reserved fo r subset barriers. One o f
t h ese h a s a .l ready b e e n redefined as a w r i t e-write
barr i e r.
Not a l l changes invo lve growth .

Th e r e

are su bs e t

ring ru les defined for remov ing e i t h e r one or both
( I ITL ami \I,\ X) f l oa t i ng -p o i n t dau t �-p e s . I f both a re
removed, the f l o at i ng- po i n t r eg i � t c r s c a n a l so be

re m o ve (! . The

r\\lOVx:· Pr\ Lcode ro u t i n e s

a n cl !{S/RC:

i n s t r u c t i on s are defined as o p t i o n a l and can be
d e leted when the transition of t r a n sl at e d VA X code
i s comp leted. Ot her unneeded l'A I .code ro u t ines

can a l so be re m oved eve n t u a l ly.

StttlliiUIIJ!

a 16 - b i t PTE field that is not curren t l y used by map

The go a l s t ha t shaped t he A l pha A X !' a rc h i t e c t ure

p i ng hardware, a n o t h e r 16 bits of p hysical add ress

design have l arge ly been realized . For h i gh p e rf(>r

growth can be ach ieved, if ever n eeded .
I n i t i a l i m p lementations a l s o u s e o n l y S K i l p ag es,

mancc ,

the

fi rst

i mp l ement a t i o n

(the

DU chi p

2 1 064 m icroprocessor) is l isted in the October 1992

b u t the design accom modates l i m i ted growth to

Guilllll..'ss nook of Records as

(J i KB p a ge s . Beyo nd t h a t , page t a b l e g ra n u l a ri t y

g l e - ch i p m i crop rocessor. It is t o o c:trly to measu re

h i n t s al l ow gro u p s of 8, 64, or � 1 2 p a g e s to be

longevity, h u t t he fact t hat

t rea tt:d as a si ngle la rge p a ge, thus effect ively

h i l i t �· in places that changed during cl cvelopment is

c.

a t le as t encouraging. OpenV.Vl� ,\X I', DEC : OS I / 1 A X !'.

· te n d i n g tht: page- size range by a bctor of ovn

l id.

1

.\"n.

i

.\jJecial lsslll! 1 ') 92

we

the wo rld 's fastest s i n

h:�d d e sig n e d- in fkxi

Digital TeciJIIical .founwf

Alpha AXP A rchitecture

and Windows NT operating systems a l l r u n on

IEEE

Alpha A X P i m plementations today. Programs from

encoded in a floating-poi n t format. The I E E E stan

the VAX and M I PS architectures transport easily to

dard specifies some exceptional resul t s (e . g . , 0/0)

Alpha AXP i mplementations and run q u ickly. Many

to be NaNs.

of the ideas in the Alpha AXP design are now bei ng
adopted by other architectures in t he industry.

not-a-number (Na.N)-A symbo l i c entity

Linear addressing-A memory addressing tech
n i que in wh ich a l l add resses fo r m a single range,
from 0 to the largest possible address. Subscript cal

Appendix
Binary translation-A software tech n i qlle to
change an execu table program written for one
arc h i tecture/operati ng-system pair into an equ iva
lent program for a d ifferent architecture/operati ng
system pair.

c u lations can create any address in the entire range.

Little-endian mem01:y addressing-A v iew of
memory in which byte 0 of an operand contains the
least significant bit of an i nteger. The terms little
endian

and

big-endian

are

borrowed

from

Gulliver's Tmvels in which religious wars were

Big-endian memory addressing-A v i ew of mem
ory i n wh ich byte 0 of an operand conta ins the
most significa nt (sign) bit of a n i nteger. Compare l i t

waged over w h i c h end of an egg to break.

Longword-A 32-bit datu m.
Multiple instruction issue-A h igh-p erformance

tle-end ian memory addressing.

computer i mplementation techn ique of starting

Byte-An 8 -bit datu m.

more than one instruction at once. An i mplementa

Byte granularity- The appearance that two pro

tion that starts (up to) two instructions at once is

cessors can u pdate adjacent bytes in memory with

cal led dual-issue; four i nstructions, quad-issue or

out in terfering with each other.

fou r-way issue; etc.

C/SC- Complex i nstruction set compu ter, charac

Octaword-A 1 28-bit datu m .

terized by variable-length i nstructions, a wide vari
ety of mem ory addressing modes, and instructions
that combine one or more memory accesses with

Quadword-A 64-bit datu m.
RISC- Reduced instruction set computer, charac

ari t h metic . CISC designs express computation as a

terized by fixed- length i nstructions, simple mem

few complex steps.

ory addressing modes, and a strict clecoup l i ng of

IEEE

denormalized number (denormal)-A float

ing-point number w i th magnitude between zero
ami the smal lest representable normalized n u mber.

load/store memory access instructions from regis
ter-to-register arithmetic i nstru c t i o ns. ruse designs
express computation as many simple steps.

N u mbers i n this range are typically not rep re

Segmented addressing-A m emory addressing

sentable in other floating-point arithmetic systems;

tech nique in w h i ch addresses are broken into two

such systems might signal an underflow exception

or mo re parts (segments) . Subscript calculations

or force a resu l t to zero instead .

can only be done within a si ngle segment, and elab

IEEE

do uble-extended format-A loosely specifed

floating-poi n t format with at least 64 significant

orate software techniques are needed to extend
addressing beyond a single segment.

bits of precision and at least 15 bits of exponent

VA X

width; typicall y i mplemented usi ng a total of 80 or

non-zero faction; m ust be converted to a true zero

128 bits.

resu lt.

IEEE dynamic

rou nding mode- O ne of fou r d iffer

jloating-point-A form of com p u ter arith

metic specified by the VAX architecture manual . '

ent round i ng rules.
lEJ::J:."

VA X

dirty zero -A zero value represented with a

floutingpoint-A fo rm of compu ter arith

metic specified by IEEE standard 754 J 2 IEEE arith

VAX

arithmetic

includes

ru les

for

reserved

operands and d irty zeros.

metic i ncludes ru les for denormal i zed numbers,

VA X rese·rved operand-A non-number that signals

i nfinities, and not-a-numbers. It also specifies four

an exception when used as an operand in VA X float

d ifferent modes fo r round ing resu lts.

ing-p o i n t arithmetic.

IEEE

infini�J'-All operand with an arbitrarily large

magnitude.

D igital Technical journal

VA X

word swapping- The rearrangement needed

for the 16-bit p ieces of a VAX floating-point number

Vol. 4 No. 4

Special Issue 1')92

33

Alpha AXP Architecture and Systems

to put the fields in a more usual order; t h is is an arti

R

fact of t he I'DI'-.ll 16-bit architecture.

There are two speci a l - resou rce anomal ies i n
t h e architecture t h a t we were u nable to avoid :
the

Word-A 16 -bit datum.

ded icated

state

for

the

load-locked

i nstruction and the dynamic round ing-mode
register required fo r ful l I EE E conformance.

Acknawledgments
H u n d reds of p eople have worke(l on the Al pha AX I'

9.

C string manip u lation benchmark resu l t , r u n

arch i tecture, h a rdware, ancl software. Many Al rha
AXl' archi tectura l ideas came from the

n i ng 3 to 6 ti mes faster than the customer's

PRISM

expectation (which was based solely on clock

design, most notably the PALco de i d ea . 1 The archi 

rate ratios).

tecture work w a s d o n e i n t h e rich environment o f
dozens a nd l a t e r hundreds of bright, thoughtfu l ,

Th is is borne o u t i n a l a rge customer's recent

10.

Cn�p-1 Computer System Reference Ma nual,

a n d ou tspoken p ro fessional p eers. E l len Batbou t a ,

Form 2 240004 (Min neapol is : Cr:�y Research,

D i leep

Inc . , 1977).

Bhaml a rkar,

Richard

Brunner,

Wayne

Cardoza, Dave Cutler, Daniel Dobberp u h l , Robert
(rigg i .

Henry

Grieb,

Richard

Grove ,

1. 1.

Robert

!>:vstem/370 Principles of Operation,

Form GA22-7000-4 (Ar monk, NY : IB.Vl Corpo

H a l stea d , Jr. , M ichael Harvey, Nancy Kronenberg,

ratio n, 1974): 28.

Raymond Lanza . S tephen Morris, Will i a m Noyce,
Charles N y l a nder, Dave Orbits, Mary Payne , Audrey

!lUI

12.

Institute of E lectrical a n d E lectro n i cs Engi
neers, " B i nary Floating-point Arithmetic t<>r

Reith , Robert S u pn i k , Benjamin Thomas, Catharine
van l ngen , and Rich Witek a l l contri b u ted d i rectly

Microprocessor Systems," Standard Number

to the wri t ten specifica t i o n . Rich Witek is co-archi

I E E E -754 (New York, 1985).

tect and is the other half of the term "we" used in
t h is pap er.

1 .3.

The carefu l reader wi l l notice that Alpha A XI'
imp lementations requ i re a l ongword sh ifter
in t h e lo ad/store path for :)2-bit operands.
A l t hough we briefly considered a design with

References and Notes
1.

G. Amdahl, G.

no 32 -bir operands, we decided to keep .12 -bir

B l aauw, and E Brooks, Jr. ,

load/store support fo r good business reasons.

"Architecture of the IBM System/360," lf),Jd

S i m i la r l y, Alpha AXP i mplementations require

jou rna l ofResearch and Det.1elopment, vol . 8,

a word swap per in the load/store path fo r VAX

no. 2 (April !967): 87- 10 1 .
2.

3

floating-p o i nt operands. We decided to keep

R . S i tes, ed . , Alpha Arch itectu re Reference
J;Ja nual ( B ur l ingro n, �1A : Digital Press, 1992).

VAX floa t i ng-p o i nt support for good b u s iness

R. Conra(l et a l . , "A 50 MIPS (Peak) 32/6 4b

future .

M i croprocessor," ISSCC D iges t of Technical

Papers (February 1989): 76 -77
4.

reasons. Depend i ng on ma rket needs, VAX
floati ng-point support can be removed in the

14.

R. Brunner, ed . , l'l!X Architecture Reference
1l1an ual Second Edition (Bedford, MA: D i g i t a l

(>.

successfu l

a rchi tec

implementations i n m i d - l ife: the lB.'vl 709
series from 36 to 72 bits: the 1 11�·1 System/:)(>()
series from 32 to 64 bits: the Digita l I'Dl'-1 1
series from 16 to 32 b i ts: and the D i g i t a l

G. Kane and J Heinrich , MIPS RISC Architec

ture (Englewood C l i ffs,
1992).

commercially

tures have grown to dou ble-w i d th memory

Press, 199 1 ) .
'5

Many

NJ:

VAX series from 3 2 t o 6 4 b i t s . This trend i s

Prentice-Ha I I ,

l ikely to continue.

R. Sites, A. Chern off, M . Kirk, M . Marks, and
S

Rob inso n, " B i nary Translat i o n ,'' Digital
Technical joumal, vol . 4, no. 4 (1992, this

issue): 137- 1 52.
7.

The l it t le-end i a n b ias is very s l ig h t ; both big
and l it t le-e ndian Alpha A X P systems and soft
ware are in fact being bu i l t .

\ 'tJI.

-i .\'o. 4

.SjNcir�l lsslle 7')')2

Digital TeciJuical journal

Limn Madden
Edward) McLellan
Derrick R. Meyer
james Montanaro
DonaldA. Priore
Vidya Rajagopalan
Sridhar Samudrala
Sribalan Santhanam

Robert A. Conrad
Daniel E. Dever
Bruce Gieseke
Soha M.N Hassoun
Gregory W. Hoeppner
Kathryn Kuchler
Maureen Ladd
Burton M. Leary

Daniel W. Dobberpuhl
Richard T. Witek
Randy Allmon
Robert Anglin
David Bertucci
Sharon Britton
Linda Chao

A 200-MHz 64-bit Dual-issue
CMOS Microprocessor
A 400-mips/200-MFLOPS (peak) custom 64-bit VLSI CPU chip is described. The chip is
fabricated in a 0. 75-f.Lm Cil!fOS technology utilizing three levels of metalization and
optimizedfor 3.3- V opemtion. The die size is 16 8 mm x I3.9 mm and contains I. 68
million transistors. The chip includes sepamte 8KB instruction and data caches and
a fully pipelined floating-point unit that can handle both IEEE and VAX standard
floating-point data types. It is designed to execute two instructions per cycle among
scoreboarded integer, floating-point, address, and branch execution units. Power
dissipation is 30 W at 200-L'r!Hz operation.

A reduced instruction set computer (RJSC)-style

CMOS Process Technology

m icroprocessor has been designed and tested that

The chip is fabricated i n a 0.75 -J.I.m, 3.3 -V, n-we l l

operates up to 200 megahertz (MHZ). The chip

CMOS process optim ized for h igh-performa nce

implements a new 64-bit arch itecture, designed to

microprocessor design. Process characteristics are

provide a h uge linear address space and to be devoid

shown in Table 1 . The thin gate oxide and short

of bottlenecks that would impede h ig h ly concur

transistor lengths resu l t in the fast transistors

rent imp l ementations. Fu lly pipelined and capable

required to operate at 200 MHz. There are no

of issu i ng two instructions per clock cycle, this

explicit bipolar devices in the process as the i ncre

implementation can execute up to 400 mil l ion oper

mental p rocess complexity and cost were deemed

ations per second. The c h ip includes an 8-ki lobyte
(KB) 1-cache, 8KB D-cache and two associated trans
lation buffers, a four- entry, 32-byte-per-entry write
buffer,

a

pipel ined 64-bit integer execution u n i t

w i t h a 32-entry register file, a n d a pipelined floating
point unit (FPU) with an additional 32 registers. The
pin interface includes i ntegral support for an exter
nal secondary cache. The package is a 431-p i n p i n
grid array (PGA) w i t h 140 pins dedicated to

v[wl\.55

(power supply vol tage/grou nd). The ch ip is fabri

Table 1

Process Description

Featu re size

0.75 �-tm

Channel length

0.5 1.�.m

Gate oxide

V,/V,p

Power supply

1 0.5 nm
0.5 V/- 0.5 V
3.3 v

Substrate

P-epitaxial with n-well

Salicide

Cobalt-disilicide in diffusi ons
and gates

measures 16.8 millimeters (mm) X 13.9 m m and con

Bu ried contact

Titanium nitride

tains 1 .68 mill ion transistors. Power dissipation is

Metal 1

0.75-�-tm AICu, 2.25-/l.m pitch
(contacted)

Meta1 2

0.75-/l.m AICu, 2.625-/l.m
pitch (contacted)

Metal 3

2.0-/l.m AICu, 7.5-/l.m pitch
(contacted}

cated in a 0.75 -micrometer (J.I.m) n-wel l comple
mentary

metal-oxide

semiconductor

(CMOS)

process with three layers of metalization. The clie

30 watts ( W ) from a 3.3-vol t (V) supply at 200 MHz.

© IEEE. Reprinted, w i t h permission, from t h e IEEE journal of
I I , page� 1555 to 1567,

Solid-State Circuits, vol u me 27, number
November 1992.

D igital Techuical journal

Vol. 4 No. 4

Special Issue 1992

35

Alpha AXP Architecture and Systems

too l a rge in comparison to the benefits provided

--I

r---

principal ly more area-efficient large drivers such as
clock a nd 1/0.
The metal structure is designed

to support

is very thick and h a s a rel a tively large pitcl1 . I t

t

�

is important at these speeds t o have a low-resis
t a nce metal layer ava i l able for power a n d clock

BIU

d istribu tion . I t i s also used fo r a s m a l l set of special

IRF

signal wires such as t he data bu ses to the pins

-

mum t h ickness by planarization and by fil l ing metal

I
I

1 a nd metal 2 contacts with tungsten plugs. This
removes a p otential weak spot i n the electromi

�
�,

gration characteristics of the process and a llows
more freedom i n the design without compromising
'-----

Alpha AXP Architecture

Figure

The computer architecture i mplemented is a 64 -bit

1

F-BOX

-

i �

I - BOX
-

FRF

-

t

and the c o ntrol wires for the two shifters. M
. etal I
a n d metal 2 are main tai ned at c lose to their maxi

rei iabili ty.

�
E-BOX

the h ig h operating frequency of the chip. M etal 3

I

I - CACHE

l

T

A-BOX
WRITE BUFFER

1-

D-CACHE

CPU Chtp 13loclz Diagrmn

load/store RJSC archi tecture with 168 instructions,
a l l 32 bits wide. 1 Supported data types include

E -box), the floating-poi n t u ni t (fRf p l us F-box), the

8 -, 16-, 32-, and 64-bit in tegers ancl both D igital a n d

l o ad/store u n i t (A-box), and t h e branch unit (dis

I E E E 32- and 6 4 - b i t floating-p o i n t formats. E ach o f

tributed). The bus interface u n i t (UIU), described in

t h e two register files, i nteger a n d floating point,

the

contains 32 entries of 64 bits with one entry in each

between the chip and externa l components. The

next

section,

hand les

all

communication

being a hardwired zero. The program cou n ter a n d

m icrophotograph (Figure 2) shows the boundaries

virtu a l add ress are 64 bits. I mplem e n tations can

of the major fu n c t i o n a l u ni ts. The d u a l -issue ru les

subset the virtual address size, but are requ ired to

are a d i rect co nsequence of the register file ports,

check the fu l l 64-bit address for sign extension.

the fu nctional u n its, and the !-cache i nt erface. The

This ensures that when later i mplementations

in teger register file (I RF) bas two read ports and one

c hoose to support a larger v i rtual address, pro

write porr dedicated to t h e in teger u ni t , and two

grams w i l l still run and not find addresses that have

read and one write port shared between the branch

d irty bits i n the previously " u nused " bits.

unit a n d t he load/store u n i t . The floating-poin t reg

The architecture is designed to s u pport high

ister fi le (FRF) has two read ports a n d one write

speed multi- issue implementations. To this encl the

port dedicated to the floating u nit, a n d one read

arch i tecture does not include condition codes,

and one write port shared between t h e branch u n i t

i nstructions wi th fixed source or destination regis

a n d t h e load/s tore u n i t . T h i s leads to d u a l-issue

ters, or byte writes of any k i n d (byte operations are

ru les that are quite general :

supported

by

extract

and

merge

i nstructions

within the CPU itsel f ) . A lso there are no first -gener
a t i o n artifacts that are optimized arou nd today's
technology, which woul d represent a long-term l ia
bility to t he architecture.

Chip Microarchitecture
The block diagram (Figure 1) sh ows the major func
tional blocks and t heir interconnecting buses, most

•

Any load/store in para l lel with a n y operate

•

An i n teger operate in parallel with a floating
operate

•

A floa ting operate ancl a floating branch

•

An in teger operate and an i nteger branch

except that integer store and floating operate and

of which are 64 bits wide. The chip i m plements

floating store and i nteger operate are d isal lowed as

four fu nctional u nits: the i nteger u ni t (IRF plus

p airs.

36

lk>l. 4 No. 4

Special Issue 1992

D igital Technical jounw/

A 200-Jli/Hz 64-bit Dual-issue CMOS Microprocessor

Figure 2

Micropbotograp!J of Chip

As shown in Figure 3 a , the integer pipeline i s

subrou tine return s t ack. The archi tecture provides

7 stages deep, where e a c h stage i s a 5 -nanosecond

a convention for compi lers to predict branch deci

(ns) clock cycle. The first fou r stages are associated

sions and destination aclclresses, including those for

with instruction fetching, decod i ng , and score

register indirect j u mps. The pena l ty for branch m is

board checking of operands. Pip e l i ne stages 0

predict is four cycles.

t h rough 3 can be stallecl. Beyond 3, however, a l l

The flo a t i ng-point u ni t is a fu l ly pip elined 64-bit

pipeJine stages advance every cycle. M o s t arith

float ing-poi n t processor that su pports both VAX

metic and logic u n i t (ALU) operations complete in

standard and lEEE standard data types and rou nd i ng

cycle 4 , allowing s ingle-cycle l atency, w i th the

modes. I t can generate a 64-bit resu l t every cycle

shifter being the excep t i o n . Primary cache accesses

for a l l operations except d ivide. As shown in Figure

complete in cycl e 6, so cache l atency is three cycles.

3b, the floating-po i n t pipe l i n e is identical a n d

The chip wi l l do hits u nder m isses to the prim ary

m ostly shared with t h e i nteger pipeline in stages 0

D-cache.

through 3; however, the execution phase is three

The !-stream is based on a u tonomous prefetch 

cycles longer. A l l operations, 32- and 64-bit (except

ing in cycles 0 a n d 1 w i t h the f i n a l reso l u t i o n o f

divide) have the same timing. Divide is handled by a

1-cache h i t n o t occur r i ng u n til cycle

5.

The

prefetcher i nc l udes a branch history table and a

D igital Technical jounutl

Vr>l. 4 No. 4

.\jH!cial /ss11e

1992

nonpipelined , single bit per cycle, ded icated divide
unit.

37

Alpha AXP Arc h i tecture and Systems

1

0

IF
CACHE
ACCESS

2
10

SW

4

3
11

DECODE
SWAP
PREDICT

5

A1
ALU1

6

A2

ISSUE
RF READ

WR
WRITE

ALU2
PC GEN

} BYPASS

ITB

I - CACHE
HI T/MI S S
DTB D-CACHE
HIT/MISS

VA GEN

(a) lnteger Unit Pipeline Tirning

0

IF

1

sw

CACHE
ACCESS

2

10

'�·�F-�--�--F-�--�---:3

3
11

DECODE
SWAP
PREDICT

ISSUE
RF READ

I

L1 D
MUL1

ADD
3X

___;4

-r

__

:_s

-t

__

SHIFT ADD/AND
MUL2 ADD/AND

!

F0 R� BYPASS
__
FRF WRITE
FRF WRITE

+-

__
_ __

__

(b) Floating-point Unit PijJe!ine Timing

KEY:
PC GEN
VA GEN
ITB
OTB

GENERATE NEW PROGRAM COUNTER VALUE
GENERATE NEW VIRTUAL ADDRESS
INSTRUCTI O N TRANSLATION BUFFER
DATA TRANSLATI O N BUFFER
Figure .)

Pipeline Timing

In cycle 4, the register file data is fo rma tted ro

pages and 4 tbat map 4 -megabyte (MB) pages. ·rhe

fraction, exp onent, and sign. In the firs t - stage

data transl ation bu ffer contains 32 entries that can
m;�p 8 K.ll, 64 KB, 512KB, or 4 M B pages.

add er, exponent d i fference is calcu lated and a :1 x
m u l tipl i cand is generated for m u l tipl ies. In addi

The CPU supports p e rformance measurement

t i o n , a predictive lead i ng 1 or 0 uetector using

with two counters that accu m u l ate system events

the i n put operands i s i nitiated fo r use i n resu l t nor

o n the chip such as d u a l-issue cycles and cache

m a l iza t i o n . In cycles 5 and 6, fo r add/su btract,

m isses or external eve n ts t h rough two ded icated

a t ignment or normalization sh ift and st icky-b i t cal

pins that a re sa mpled at the selected system clock

culation are performed . For both si ngle- a ncl dou

speed .

ble-precision multipl icat i o n , the m u l t iply is done i n
a radix-8 pipe l i ned array m u l tipl ier. I n cycles 7 and

External lnter:face

8, the final addition and rounding are performed i n

The external i nterface (Figure 4) is designed to

para] Jel and the fin a l resu lt i s selected a n d d r iven

d i rectly support a n off-chip backu p cache that can

back to the register file in cycle 9. With an a l lowed

range in size from

bypass of the register write data, float i ng-po i n t

co nstructed from ordinary SRA Ms. For most opera

latency i s six cycles.

tions, the CPU c h ip accesses the cache d i rectly

The CPU contains a ll the hardware necessary to
support a demand paged virtu a l memory system. It

in

a

1 28KB to 8MB and can be

combinatorial loop by prese n t i ng an address

and w;�iting N CPU cycles for contro l , wg, and data

N is a mode-progra m m able n u m

incl udes two translation bu ffers to cache virtual-to

to appear, where

physical ;�ddress tra nsl;�ti o n . The instruction tra ns

ber between :) a n d 1 6 set at power-up t i m e . For

lation bu ffer co n t a i ns 1 2 entries, 8 that m ;� p 8KB

wri tes, both the total n umber of cycles and the

VrJ/. 4 ,\'o. .:f

Special issue 1992

Digital Tecbuical journal

A 200-MHz 64-bit Dual- issue CMOS LViicroprocessor

adr
sys RAM ctl
RAM ell
I
I B-CACHE
I
I
rr-LOGIC I
SYSTEMr-DEPENDENT
I
h<33:5>

�

-

-

-

-

-

-

-

-

I �� � ll � � I

CPU
CHIP

TAG
CTL
RAM

I
1
I

tagctiV. :.D�
tag
data
mise out
mise in
sysCik
1Adr
h<33:n>

i

-

@]

- - 1-

-

DATN
CHECK
RAM

I

I

MEMORY
SYSTEM
I NTERFACE

- - - - I

h < 1 27:0>, check h<27:0>

OSC<2>
(400

MHz)

h< 1 2:5>

Figure 4

CPU External Interface

dura t i o n and position of the write signal are

the 16-byte p i n bus. Tn 64-bit mode, i t is four cycles.

program mable in u n i ts of CPU cycles. This a l lows

This yields a m a x i m u m backup cache read band

the mod u le designer to select the size and access

width of 1 .2 gigabytes per second (GB/s) and a write

time of the SRt\..\1s to match the desired price/

bandwidth of 7 1 1 M fl/s

performance point.

be i nv a l i d ated at the rate of o ne l in e per cycle

The in terface i s designed to a llow a l l cache pol
icy decisions to be con trol led by logic external to

u s i ng

the

ded icated

Internal cache l ines can
i n v a l idate

address

pi ns,

iAdr_h< l 2 : 5 > .

the CPU chip. There are th ree contro l bits associ

In the event exte rn a l intervent i o n i s required , a

ated w i t h each backup cache (B-cacl1e) l i ne: val id ,

request code is presented by the CPU chip to the

shared , a n u u i rty. The c h i p comp letes a B-cad1e

external state machine in the time domain of the

reau as long as valid i s t rue. A write i s processed by

SYS_CLK as descri bed previously. F igure 5 shows

the CPU only i f val id is true and shared is fa lse.

t he read m iss t i m i ng where each cycle is a SYS_C L K

When a write is performed, the u irty bit is set to

cycle. T h e externa l transaction starts w i t h t h e

true. In a l l other cases, the c h i p defers to a n exter

address, t h e quadword w i t h i n block a n d i nstruc

nal state machine to complete the transaction. This

tion/data i n d ication s u p pl ied on the cWMask_h

state machine operates synchronously with the

pi ns, and READ_BLOCK fu n c t i o n suppl ied on the

SYS_CI.K output of the ch i p , which is a mode-con

cReq_h pins. The external logic returns the first

t rol led submu ltiple of t he CPU clock rate ranging

16 bytes of data on the data_h and error correct

from d iv ide by 2 to divide by 8. I t i s also possible to

i ng code (ECC) or parity on the check_h p ins. The
CPU latches the data based on recei v i ng acknowl

operate without a backup cache.
As shown i n the d iagra m , the extern a l cache

edgm e n t on rdAck_H . The d iagram shows a sta l l

is con nected between the CPU c h i p and the sys

cycle (cycle 4 ) between the request a n d the ret urn

tem memory i nterface. The combinatorial cache

data; this depends o n the external logic and could

access beg ins with the desired address d e l ivered

range from zero to many cycles. The second 10

on the ad r_h l i nes and resu l ts in c t l , tag, data,

bytes of data are returned i n the same way with

and check bits appearing at the chip receivers

rdAck_h signa l i ng the return of the data and cAck_h

within

128-b i t

sign a l ing the completion of the transaction. cReq_h

mode. B-cache accesses requ ire two extern a l data

returns to i d le and a new tra nsaction can start a t

cycll's to transfer tbe 32-byte cache I ine across

t h i s time.

the prescribed access time.

Digitn/ 1eclmicnljournal

Vol. "' .Yo. 4

In

Special issue 1')92

:3 9

Alpha AXP Architecture and Systems

sysCLKOut_h
adr_h �
cWMask_h
cReq_h
data ' hI
ecccheck_h
rdAck h
cAck_h

VALID

�

c
X

VALID

X VALID �
I \
J·(c;ure

5

X VALID X
I \

CPU Extemal Timing

The c h ip i m pl e m e n t s a novel set of fe a t u res s u p

One d i ffic u l t y i n herent in t h i s c lo c k i ng met hod

node, :).25

port i ng chip a n d m o d u l e test. When the ch i [J is

is t h e s u b s t a n t i a l l oad o n the cl oc k

reset. the first ac t i o n is to reaLI from a s e r i a l read

n a nofaracl (nf) i n o u r design. T h i s load and t h e

o n l y me m ory

(SHO�I)

i nto the 1-cacbe via a pri vate

requ irement fo r a fast c l o c k edge l e d us to t a ke p a r

th ree-wire port. The CPU i s then e n a bled and the

t i c u l a r care ·w i t h c l o c k rou t i n g a n d to do extensive

program counter (PC) i s forced to

0.

Thus with o n l y

a n a lysis on t h e re s u l t i n g grid . F i gure 6 shows the

three fu n c t i o n a l components (CPU c h i p , SROJvl , a nc.l

d is t ri b u t io n o f c l ock load am o ng the m aj o r func

c l o c k i n p u t) , a s ys t e m is a b l e to begin execu ting

t i o n a l u n i ts . The c l o c k d rives i n to a grid o f vert i c a l

2.

i n s t r u ct i ons. This i n i tial set of i ns t r u c t i o n s i s used

meta l 3 and h o r i zo n t a l m e t a l

to write t h e bus c o n tro l registers i n side t h e CPU

o c c u r s i n t h e integer and fl o a t i ng- p o i n t u n its t h a t

c h i p to s et the cache timing

a r e fed f ro m t h e m o re robust m e t a l 3 l i nes. To

a nd to te st the ch ip and

M o s t of the l oa d i n g

mod u le from the CPl o u t . After the SIZOM loads t h e

ensure the i n tegr i t y of the c l o c k grid across t h e

!-cache. the p i n s u sed for t h e S l{O,vl i n t e r face arc

c h ip, th e grid w a s ext racted f ro m the l ayo u t and the

e n a bled as serial i n and o u t ports. Tlu:se pons can

resu l t i ng n e t work, w h i c h c o n t a ined

be used to load m o re data o r to ret u rn status of test

m e n ts, was s i m u l ated using a c i rc u i t s i m u l at i o n

ing and setu r .

program b a s e d o n

6 30,000 RC ele

t h e AWEsim s i m u lato r fr om

Ca rnegie-Me l l on l ! n iversi q'. Figure 7 shows a t h ree

Circuit Implementation

d i m e n s i o n a l rep rese n t a t i o n o f the o u t p u t of t h i s

M a n y novel circ u i t s t r u c t u res ami d et a i l ed ana lysis

s i m u l a t i o n and shows the c l o c k delay from t h e

tech niques were d evel op e d to s u p p o rt the clock

d river t o e a c h o f the

rate i n conj u n ct i o n with the c o m p l ex i ty demanded

necteLI to the c l ock grid .

by the c o n c u r r ence ami wide data raths. The clo ck

The

200-MI-Iz

6 ),000

transistor gates con

c l o c k s i g n a l is fe d to t h e driver

ing method is s i ngle wire level s e n s i t ive . The bus

t h rough a bi nary fa n n i n g tree with five leve l s o f

i n terface u n i t op erates fro m a b u ffered ve rsion of

b u ffe r i n g . There i s a h o r i z o n t a l short i ng bar at t h e

the m a i n c l o c k . Signals t h a t cross t h is i n te r face are

i n p u t to t h e c l o c k d r iver to h e l p s m oo t h o u t p oss i 

des kewed to el i m i n ate races. T h is c l ocking method

b l e asymmetry in t h e i ncom i ng wave front. The

145

e l i m i n ates dead t i m e between p h ases ami req u i res

d river i t s e l f consists o f

o n l y a single clock sig n a l to be rou ted t h ro u g ho u t

of which c o n t a i n s fou r levels of presc a l i ng i n t o a

the c h i p .

f i n a l o u t p u t s t a ge th at d r ivl's the c l o c k grid .

40

l'o/. . j No. ..j

.ljJeciol Issue I'.J'.Jl

separate e l e m e n ts. each

Digital TeciJIIical jou runl

A 200-MHz 64-bit

I NT UNIT
1 1 29 pF

Dual-issue

Clv/05 Micmprocessor

WRITE
BUFFER
82 pF

I-CACHE

373 pF

D-CACHE

208 pF
FPU

803 pF
TOTAL BYPASS CAPACITANCE =

1 28 nF

Note: Total ellective switching capacitance = 1 2 . 5 nF

Figu re 6

Clock Load Distribu tion

•

(j)

c...

>"'

a;
Cl

2.93E+01

<

•

5.86E+01

300

•

8.79 E+01

200

D

1 . 1 7 E+02

1 00

1 . 47E+02

0

1 . 76 E+02
2.05 E+02
2.34E+02

6'
·o

<"�
'?9� <9· o

2.64E+02

�

� -qo

<0�
�<:>

�'
"0e'�

Figure

7

•

<

2.93E+02

�'
\...�

CPU Clock Skew

The clock driver and p red rive r represent about

on-chip. Th is consists of thin oxide capacita nce

40 percent of the total effect ive swi tching capaci

that is distribu ted around the chip, primarily under

tance determined by power measu rement to be

the data buses. In addition, t h e re a re horizonta l

l2.5 nF (worst case i n c l u d i ng ou tput pi ns). To

metal 2 power a n d clock short i ng straps adjacent

manage the problem of di/dt on the chip power

to the clock generator, and the thin oxide decoup

pins, explicit decoupl i ng capacitance is provided

l i ng cap under these l i nes suppl ies charge to

Digital Techu icnl jourua/

Vul .

·1

,\u. 1

.\jJ('cial lssue /1;)').2

41

Alpha AXP Architecture and Systems

the clock driver. di/dt for the driver alone is about

fe red versions of CLK. The resu l t i ng clock skew i s

x 1 0 n a mp eres per seco n d . The total decoupl ing

managed o r eliminated with special latch structures.

2

capac i t a nce as extracted from the layo u t measures

The latches used in the chi p can be classified into

128 nF Thus the ratio of decou pl ing capacitance

two categories: custOm and standard. The custom

to switching cap is about 10: l. With t h is capacitance

la tches were used to meet the u n ique needs of data

ratio, the decoupl ing cap could supply a l l the charge

path structures and the special constraints of criti

associated with a complete CPU cycle with only a 1 0

c a l p aths. The s t a ndard l a tches were used in the

percent reduction i n the on-chip supply vo l tage.

design of noncritical control and i n some data-path
appl ications. These l atches were designed prior to

Latches

the start of i m plementation and were i n cluded in

As previously describe d , the chip employs a single

the I ibrary of usable elements for logic synthesis. All

p hase approach , with nearly a l l latches in t h e core

synthesized logic used only this set of l a tches.

of the chip receiv i ng the c l o c k node, CLK, d i rectly.

The stand ard latches are extensions of previously

A representative example is i l l ustrated in Figure 8.

published wo rk, and examples are shown i n Fig

No t i ce that L1 and L2 are transparent l a tches
separated by random logic and are not simu ltane
ously active; L1 is active when CLK is hig h and L2
is active when CLK is low. The m i n i m u m numbe r of

ures 9 to 1 J . 2 To understand the operation of
these latches, refer to Figure 9a. When CLK is h igh,

P1, Nl, and N3 function as an i n verter complement
ing IN l to produce X P2, N2, and N4 fu nction as a

delays between l a t ches is zero and the maximum

second inverter and comp lement X to produce

nu mber of delays is constrained only by the cyc le

OUT. Therefore, the structure passes IN 1 to OUT.

time and the deta i l s of an y releva nt critica l paths.

When CLK is low, N3 and N4 are cut off. If !N l , X,

The bus i nterface unit, many da ta-p ath structures,

and OUT are i n i tially h i g h , low, and h ig h respec

and some critical paths deviate from t his approach

t ively, a transition of !N l falling p u l l s X high

and use bu ffered versions ancl/or cond itio naJ ly buf-

th rough Pl causing P2 to cut off, which tristates
OUT h igh. I f IN l , X, and OUT are i n i t i a l l y low, high ,
and low respective ly, a transition of IN 1 rising
causes PI to c u t off, which t rista tes X h igh leaving
out tristated low. In both cases, additional transi
t ions of IN1 leave X t ristated or driven h igh with
OUT tristated to its i ni t i a l v a l u e . The refore, the
structure impl e ments a latch that i s t ranspare n t
when CLK i s h igh a n d opaque when CLK i s low.
Figure 9c shows the dual circu it of the latch j u s t d is
cussed ; this struc ture i mplements a latch that is
transparent when CLK is low and opaque when
CLK is high. Figures 9b a n d 9d depict latches with

an o u t p u t buffer used to protect the sometimes
dynamic node OUT and to d rive large loads.
The design of the stand ard l a tches stressed three

(a) Latching Schema

primary goals: flex i bi l ity, i m m u n i t y to noise, a n d
i m mu n i t y t o race- th rough . To achi eve t h e desired

TR

-

TF
-

..1--------!..

CLK

flexibi l i ty, a variety of l a tches l ike those in F igures 9
to 1 1 in a variety of sizes were characterized for the
i m p lemen tors. Thus the designer could select a
latch with an optional output buffer and an embed

L2 OPAQUE
L1 OPAQUE
L2 TRANSPARENT l1 TRANSPARENT
(b) Latch Timing

ded l ogic fu nction t h a t was sized appropriately to
d rive various loads. Fu rthermore, it was decided to
allow zero delay between l a tches, completely free
i ng the designer from race- t h rough considerations
when designing static logic wi t h these latches.
In the circu i t methodology adopted fo r the imple

Figure 8

42

Chip Latches

mentation, o n ly o n e node, X (Figure 9a). poses

vbl.

4 No. 4

Special issue 1992

Digital Tecbnical journal

A 200-MHz 64-bit Dual- issue CMOS Microprocessor

--c}-CLK

IN1

�
CLK

OUT

I N1

0UT

OUT

( b) Inverting A ctiue-high Latch

(a) Nonin verting A ctive-high Latch

+
CLK

IN1

�
CLK

0UT

IN1

OUT

IN1
CLK

---r�sr----r-��-

OUT

(c) No ninverting Actiue-low Latch

(d) In vertin/!, A ctive-low Latch

Figure 9

Basic Latches

inordinate noise margin r i s k . As noted above, X

the variety of avai l able la tches, and the zero delay

may be tristated high with OUT tristated low when

goal between latches. The clock skew concern

the latch is opaque. This maps into a dynamic node

was actual ly the easiest to address. If data propa

dri v i ng in to a dynamic gate that is very sensitive to

gates in a direction that opposes the propaga tion of

noise that reduces the voltage o n X, causing leakage

the clock wave fro n t , clock skew is functional. ly

was addressed by the addition of P5. This weak

cycle time local ly. M i n i m izing this effect is of con

through P2, thereby destroying OlJT. This problem

feedback device is sized to source enough current
to cou nter reasonable noise and hold P2 in cu toff.
N5 plays an analogous role in Figure 9c.

harm less ancl tends only to redu ce the effect i ve
cern when designing the clock generator. If data
propagates in a direction s i m i l a r to the propagation
of the clock wave front, clock ske"v is a functional

r

Race- through was t he major fu nction a l concern

concern. This was addressed by rad ial ly distrib

with the la tch design. It is agg ava te d by clock skew,

uting the clock from the center of the chip. Since

Digital Technical journal

Vol.

4 Nu. 4

Special Issue

1992

Alpha AXP Arc hitecture and Systems

CLK

IN2 �
�
IN 1

CLK
IN 1
IN2

0 UT

�
�

0UT

OUT

(o)

Tll 'o-input AND Actiue-higb Latch

( IJ)

Tz l 'o-input NAND Actiue-b(f!,b Latch

CLK

IN 1
IN2

�
�

CLK

IN1

0UT

I N2

IN1
CLK

�
�

OUT


IN1

---t-----!e--t---lf--9--.--

CLK
OUT

(c) Tu ·o-injmt A ND A ctir•e-lo u · La tch

Figure 10

---t-----!e---+�f---{:l--.--

N2

(d) Tu·o-input NAND A ctiue-lo u · Latch

A NO/NA N!) la tc!Jes

tile clock wave fro n t moves o u t rad i a lly from the

Then m a ny s i m u l a t i o n s with v a r y i n g CLK rise a n d

clock d r i ver toward the p e r i p hery of the d ie , i t is

fa l l t i mes, tempera t u res, and p ower s u p p l y vo l t 

not possible for the data to ove rtake the clock i f the

ages

c lock network is p roperly design ed .

a p p reciable evide nce o f race- through for

11> ve r i fy the rem a i n i n g race-through co ncerns, a

were

performed .

T h e res u l t s

showed

no

CLK

rise

a n d fa l l t i mes at or below 0.8 ns. With 1 .0-ns rise

m i x-ami - m a r c h a p p roach was take n . Al l reason a b l e

and fa l l t i mes, the l a tches showed s i gns of fa i l ure.

c o m b i n a t i o n s of l a r c hes w e r e cascaded together

'11> g u a ra n tee fu nctiona l i ty, CLK was spec i fi e d and

a n d s i m u l a ted . The s i m u l ations were stressed by

designed to have a n edge rate of Jess t h a n 0.5 ns.

e l i m i n a t i ng a l l i n te rconn ect ancl d i ffu sion capaci

T h i s was n o r a

tance a nd by p u s h i n g each device i n to a corn e r

c i rcu i t s i n t h e c h i p required s i m i l a r edge rates of

of t h e

the clock.

,

,. ,

p rocess

that

e m p h as i zed

race- t h ro u g h .

l l1/.

··I

.Vo.

-1

seri ous

.\j;ecial !ss11e

1992

constra i n t

s i nce

other

Digilal TeciJ nical jo urnal

A 200-JI!/Hz 64-bit Dual-issue CMOS ililicroprocessor

CLK

CLK

IN1
IN2 ---fL
-LY OUT

IN1 �
�0UT
IN2

(a) Two-illp u t OR A ctive-high L a tch

( {;)

Two-inp ut NOR Actiue-bigb La tch

CLK

CLK

IN __,-'j\,__ OUT
IN2 �

I N1 --1L OUT
IN2 �

1

OUT

(d) Two-inpu t NOR A ctil'e-low La tch

(c) Ttuo-input OR A ctiue-low La tch

Figure 11

OR/NOR l.a tc!Jes

A last design issue wo r t h not i ng is t he feedback
dev ices,

N'; a n d P5, in F ig u res lOc, lOci, l l a , and

11 b. Notice that t hese dev ices have their g<�tes tied

t h ro u g h

P I can d ri v e X dow n by m o re than

t h re s h o l d

even

with

weak

feed back,

a

t h e reby

d es t roy ing O l IT. l() counter t h i s phen ome n o n , P';

to C I .K i nstead of OUT I i k e the or her l a t ches. This

c a n n o t be a wea k feedback device and t h e re f o re

d i ffe rence i s requ i red to acc o u n t for <�n etfect not

cannot be t ied to OUT if t h e l a t c h is to fu nction

present i n t he other l a t ch es. I n these latches, a
StKk of dev ices is connected to node

X, without

pass i ng t h ro u g h t h e clocked t ransistors

P 3 o r N3.

pro p e rl y when CLK is h i g h . Note t h at t a l ler stacks
aggravate

this

problem

because

the

dev ices

become larger and there are more devices to part i c

Refe r r i ng to F igure l l a , <�ss u me CLK i s l ow, X i s

ipate in cou p l i ng. For t h i s reas o n , s t acks in these

high, <�nd OUT i s low. I f m u l t i p l e random transitions

l a tches were l i m ited to t h ree h ig h . Also, note that

are a l lowed by IN I w i t h JN2 h ig h , then co u p l ing

cl o c k i n g P'; i n t ro d uces another race- through path

Digital Tecbuical journal

1-rJI. 4 No. 4

Special Issue 1')91

Alpha A.XP Archit ecture and Systems

si nce X wi l l u n c o n d i ti o n a l l y go h i gh w i t h CLK

The longword carry select is built as a d i stributed

fa l l i ng, ami O l !T must be able to reta in a stored ONE.

cascode stru cture used to com b i n e the byte gen

So th ere is a two-sided constr a i n t : P5 m u s t be l a rge

erate, k i l l , and propagate sign als across the lower

enough to counter cou pl i ng and sm a l l e nough not

32 -bit longworcl . It controls the f i n a l d ata s e lection

to cause race- through. These trade- offs were an a

i n to the u p p e r lo ngworcl o u t p u t latch a n d is o u t of

lyzed by s i m u l a tion i n a man ner s i m i l a r to the one

the c r i t ic a l path.

o u t l i ned above.

The NMOS byte carry select switches are con
t rol led by a cascade of closest ne ighbor byte carry
o u ts. Data i n the most significant byte of the u p p e r

64-bi t Adder
A d i fficult circ u i t problem was the 64-bit adder por
t i o n of rhe i n teger and floati ng-p o i n t ALUs. U n l ike a
pre vious

h i gh-speed

design,

we set

a goa l to

achie ve single-cycle latency i n this u n it .\ Figure 12
has an organi zational d i agram of i t s structure. Every
path through the adder i n c l u d es two l a t ches, a l low
i ng fu l l y p i pelined operat i o n . The resul t l a tches are
shown ex pl i c i t l y in the d i ag.r-

�
"'
�.
�
:;;"·
!::
"'
......

\,::
'o
'"

LOOK
AHEAD

�1\.)
aa
K_.::::

MUX

:J::
N

�
9:
....
\:::1

;::
!::)
";'<
-.
"'
"'
;::
(1)

I N PUT OPERANDS
BYTE 7

INPUT OPERANDS
BYTE 6

I N PUT OPERANDS
BYTE 5

I N PUT OPERANDS
BYTE 4

I N P U T OPERANDS
BYTE

I N P UT OPERANDS

3

BYTE

2

I N PUT OPERANDS
BYT E 1

I N P UT OPERANDS
BYTE

0

�

�
S;;
�"

Figure 12

64-bit Adder Block Diagram

.g
2

�

�
--J

v,
0
"

Alpha AXP Architecture and Systems

G E N E RATE
DEVICE
VDD

VDD

VDD

VDD

VDD

VDD

VDD
CARRY
IN

'

P R E D I SCHARGE
AND KILL DEVICE

PR OPAGATE
DEVICE

(a) A dder Ca n)' Chain

SUM_ OUT_ASS U M I N G_ NO_CAR RY

C 1 GETS C 1
C 1 GETS C 1 L
CO G ETS CO L
CO GETS CO

SU M_I N_ASSU M I NG_N O_CARRY
S U M_.I N_ASS UMING_CARRY

(b) A dder

Carry-select Switches

Figw·e

13

Adder Carry

trans isto r to no more than 4 V Q6 is

a

PMOS p u l l- u p

dev ice t h a t shares a c o m m o n n-we l l with Q7
t h rough QIO, which have responsib i l i ty for supply
ing the we l l with a positive bias voltage of either

�Jo or the l/0 pin potential, wh ichever is h igher. Q3

through Q5 control the source of voltage for the
gate of Q6-eith er the output of the i nverter or the
110 pacl if it moves above

�Jo·

Rl and R2 provide

50-ohm series term ination i n either operating mo de.

Caches
The t wo i nternal caches are a lmost identi cal in con
stru ction. Each stores u p to 8 K.B of data (D-cache)
or instruction (!-cache) with a cache block size of
32 b)rtes. The caches are d i rect ma pped to rea l ize
Figure

48

14

Floatin g-well Driver

a single cycle access, and can be accessed u s i ng

Vr!l. 4

No. 4

Special Issue 1')92

Digital Technical journal

A 200-MHz 64-bit Dual-issue CMOS Microprocesso1·

untranslated bits of the virtual address since the

tor c e ll . A segmented word l ine is used to accom

page size is also 8KB. For a read, the address stored

modate the banked design, with a global word l ine

in the tag and a 64-bit quadword of data are

implemented in third-level metal and a local word

accessed from the caches a n d sent to either the

l ine i mplemented in first-metal layer. The global

memory management u n i t fo r the 0-cache or the

word l ine feeds into local decoders that decode the

instruction u n it fo r the I-cache. A write-through

lower two bits of the address to generate the local

protocol is used for the 0-cache.

word li nes. As shown i n Figure 15, the word J i nes

The 0-cache incorporates a pending fill latch

are enabled while the clock is h igh, and the sense

that accu m u l ates fi l l data for a cache block while

ampl ifiers are fired on the fal I ing edge of the clock.

the 0-cache services other load/store requests.
Once the pend ing fil l latch i s fu l l , an entire cache

Summary

block can be written i n to the cache on the next

A s i ngle c h ip m icroprocessor that i m plements a

avai lable cyc le. The !-cache has a s i m i lar fac i l ity

new 64-bit high-performance architecture has been

called the stream bu ffer. On an [-cache miss, the

described . By using a h ighly optimized design style

1-box fetches the required cache block from mem

i n conj unction with a high-performance 0.75 -p,m

ory and loads i t i nto the 1-cache. I n addition , t he

technology, operating speeds up to 200 MHz have

I-box will p reterch the next cache block and place i t

been achieved.

i n t h e stream buffer. T h e data is held i n t he stream

The chip is superscalar degree 2 and has 7- and

buffer and is written into the l-cache only if the data

10-stage p ip e l ines for i nteger and floating-point

is requested by the 1-box.

instructions. The chip includes primary instruction

Each cache is organized i n to four banks to reduce

and data caches, each 8KB in size. I n each 5-ns

power consu mption and current transients during

cycle, the chip can issue two instructions to two of

precharge. Each array is approxi mately 1 ,024 cel l s

fou r u nits, yielding a peak execu t ion rate of 400

wide by 6 6 cel ls t a l l w i t h t h e top t w o rows used

m ips and 200 MFLOPS.

as red undant elements. A six-transistor, 98-p,m2

The chip is designed with a flexible external

static RAt\1 cell is used. The cel l utilizes a local in ter

interface providing i ntegral support for a sec

connect layer that connects between polys i l i con

ondary cache constructed of ord i nary SRAt\1s. The

and active area, resu lting in a 20-percen t reduction

interface is fu lly compatible with v irtua l ly any

i n cel l area compared to a conventional six- transis-

m u l tiprocessor write cache coherence scheme,

3

CLK

D I S PLACEMENT
ADD
CACHE
WORD-LI N E
SENSE AMP
ENABLE
CACH E DATN
TAGS OUT
R E G ISTE R FILE
WRITE PORT

ALU BYPASS I N

Vol.

No. 4

P I PE L I N E STAGE
5

6

7

8

-------�---------�fl�--------�1\�---------���---------���--------���-

Figure 15

Digital Technical journal

4

D-cache Timing Diagram

Special Issue 1992

49

Alpha AXP Architecture and Systems

and can accom modate a wide range of tim ing

3. R. Conrad e t a l . , "A 50 MIPS (peak) 32/64b

parameters. It can i nterface d irectly to standard TIL

Microprocessor," JSSCC Digest of Technical
Papers ( February 1989): 76-77.

and CMOS as well as lOOK ECL teclmology.

References
1 . Alpba An.:hitecture Handbook (Maynard: Digital
Equ ipment Corporation, Order No. EC-H1689-10,
1992) .
2. ). Yuan and C. Svensson, " High-Speed CMOS

50

4. J. Sklans ky, "Conditional-Sum Addition Logic,"
IRE

Transactions on Electronic Co mpu ting,

vol . EC-9 (1960): 226-231 .
5. H. Lee et a!. , "An Experimental 1 M b CMOS SIV\.J\1
with Configurable Organization and Operation,''

Digest of Technical Papers ( Febru ary

C i rcuit Techniques," IEEE journal of Solid-State

JSSCC

Circuits, vol. 24, no. 1 ( February 1989).

1988): 180-181 .

Vol. 4 No. 4

Special Issue 1992

Digital Teclmical journal

Charles P. Thacker
David G. Conroy
Lawrence C. Stewart

The Alpha Demonstration Unit:
A Highpeiformance Multiprocessor
for Software and Chip Development
Digital's first

RJSC

S)'stem built using the 64-bit Alpha AXP architecture is the

prototype known as the Alpba dem onstration unit or ADU It consists of a backplane
containing 14 slots, each of w!Jich can hold a

CPU module,

a 64MB storage module,

or a module containing two 50MB/s l/0 channels. A new cache coherence protocol
provides each processor and l/0 channel with a consisten t view of shared memory
Tbirzvjive ADU systems were built within Digital to accelerate software develop
ment and early chip testing.

There is noth ing more d i fficul t to take in hand.
more perilous to conduct, or more uncertain in irs
success, than to rake the lead in t he i n troduction of
a new order of t hings.
-Niccolo Nlachiavel l i , The Pri11ce

I n t roducing a new, 64-bit computer archi tecture
posed a nu mber of chal lenges for D igital . In
addition to deve lop ing the archi tecture and the
first i ntegrated i m p le me ntatio ns, an enormous
amount of software had to be moved from the VAX
and MIPS ( M I PS Compute r Systems, Inc.) architec
tures to the AJpha AXP arch itecture. Some software
was original l y written i n h igher-level languages and
cou ld be recompi led with a few changes. Some
could be converted using bi nary translation tools. 1
AJJ software, however, was subject to testing and
debugging.
It became clear in the early stages of the p rogram
that b u i l d i ng an AJpha demonstration u n i t (ADU)
wou ld be of great benefit to software developers.
H aving a fu nct i o n i ng hardware system wou l d moti
vate software developers and reduce the overa l l
time t o market considerably. Software develop
ment, even in the most d iscipl i ned organizati ons,
proceeds much more rapi d l y when rea l hardware is
avai lable f(>r programmers. In addi tion, hardware
engi neers could exercise early i m p l ementations of
the processor on the ADU, since a part as complex
as the DECch i p 2 1064 CPU is difficult to test using
conve ntional in tegrated circ u i t testers.
For these reasons, a project was sta rted in early
1989 to bu ild a number of p rototype syste ms as

Digital Tecbuical journal

Vol. 4 No. 4

SfJecial lssue I'J92

rap i d l y as possible. These systems d id not require
the h igh l e vels of rel iability and ava i l ab i li t y typical
of D igital products, nor did they need to have low
cost, since o n l y a few wo u ld be b u i l t . They did need
to be ready at the same time as the first chips, and
they had to be sufficiently robust that t h e i r pres
ence wou l d accelerate the overa l l program.
D igital 's Systems Research Center (SRC) in Palo
Alto, CA had had experience in bui l d i ng s i m i la r pro
totype systems. SRC had designed and b u i l t m u ch of
its computing equ ipment.1 Being l ocated in Silicon
Val ley, SRC cou l d employ the services of a nu mber
o f local medi u m -vo l u m e fabrication and assembly
companies without impeding the m a i nstream
Digital engineering and manufactu r i ng groups,
which were developing AXP product systems.
The project team was d e l iberate ly kept s ma l l .
Two designers were located at SRC. one was with the
Semiconducto r Engineeri ng Group's Advanced
Development Group in Hudson, MA , and one
was a member of Digita l 's Cam br idge Research
Laboratory in Cambridge, ,viA. A lthough the p roject
team was separated bo th geographically and organ
zational l y,
com m u nication flowed smoothly
because the individuals had co l laborated on simi lar
projects i n the past. The team used a common set of
design tools, and Digita l 's global network made i t
possible t o exchange design in formation between
s i tes eas i ly. As the project moved from the design
phase to production of the systems, the group
grew, but at no point d id the entire tea m exceed ten
people.

51

Alpha AXP Architecture and Systems

Since m u ltiprocessing capabil ity is central to the
Alpha AX P architecture, we decided that the ADU
had to be a multiprocessor. We chose to implement
a bus-based memory coherence protoco l . A h igh
speed bus connects three types of mod u les: The
CPU modu le contains one m icroprocessor chip, its
external cache, and an i nterface to t he bus. A stor
age module conta i ns two 32-megabyte (M B) i nter
leaved banks of dynamic random-access memory
(DRAM). The 1/0 modu le contains t wo 50MB per
second (MB/s) 110 channels that are connected to
one or two DECstation 5000 workstations, which
provide disk and network 1/0 as wel l as a h igh
performance debugging environment. Most of the
logic, with the exception of the CPU chip, is emit

(a) CPU Module

ter-coupled logic (ECL), wh ich we selected for its
high speed and predictable electrical characteris
tics. Mod u les plug into a 14 - s lot card cage. The card
cage and power suppl ies are housed i n a 0.5 -meter
(m) by 1 .1-m cabinet. A fu lly loaded cabinet d issi
pates approximately 4,000 watts and is cooled by
forced air. Figures 1 and 2 are photographs of the
system and the modu les.
In the remaining sections of this paper, we dis
cuss the backplane i n terconnect and cache co her
ence protoco l used in the ADU. We then describe
the system modules and discuss the design choices.
We a lso present some of the uses we have found for
the ADU in addition to its original purpose as a soft
ware development vehicle. We conclude with an
assessment of the project and its im pact on the
overall Alpha A.'\P program .

(b) Storage 1�fodule

(<-) l/0 Module
Figure 1

52

F(�ure 2

The Alpha Demonstration Unit

V!JI. 4 No. 4

A D U Modules

.\jH!Cilll lssue 1.992

Dip,itnl Tecbuicaf jou nwl

The Alpha Demonstration Unit

Backplane Interconnect

Ta ble 1

The choice of a backplane i nterconnect has more
i mpact on the overal l design of a m u l tiprocessor
than any other decision. Complexity, cost, and p e r
for mance are the factors that m ust be ba l a nced to
produce a design that is adequate for the i n tended
use. Given the overa l l p urpose of the p roject, we
chose to m i n i m ize complex ity and m a x i m ize per
formance. System cost is i m portant in a h igh-vol
ume prod uct, but is not i mportant when o n ly a few
systems are p roduced .
To min i m ize complex ity, we chose a p ip e l i ned
bus design in which a l l operations take p lace at
fixed ti mes relative to the time at which a request is
issued . To maxim ize perfo rmance, we defined the
operations so that two i ndependent transactions
can be i n p rogress a t once, which fu l ly u t i l izes the
bus.
We designed the bus to provide high bandwid th,
wh ich is su i table for a m u l t iprocessor syste m , a n d
to offer m i n i mal latency. As the CPU cycle t i me
becomes very sm a l l , 5 nanoseconds (ns) fo r the
DECchip 21064 ch i p, the m a i n memory latency
becomes an i mp o rtant component of system per
formance. The ADU bus can supply 320MB/s of user
data, but still is able to satisfy a cache read m iss i n
just 200 ns.

Bus Signals
The ADU backplane bus uses ECL lOOK vo ltage lev
els. Fifty-ohm contro l led-i m pedance traces, termi
nated at both ends, provide a well-characterized
e lectrical environment, free from the reflections
and noise often present i n h igh-speed systems.
Table 1 l ists the signals that make up the bus. The
data portion consists of 64 data signa ls, 14 error
correction code (ECC) signals. and 2 parity bits. The
ECC signals are stored in the memory modu les, but
no checking or correction is done by the memories.
I nstead. the ECC bits are generated and checked
only by the u lt i mate producers and consumers of
data, the I/0 system and the CPU chip. Secondary
caches, the bus, and main memory treat the ECC as
u ni n terpreted data. This arrangement i ncreases
perform ance, since the memories do not have to
check data before del iveri ng i t . The memory mod
u les wou l d have been less expensive had we used
an ECC code that protected a larger block. Since the
CPU caches are l arge enough to require ECC and
s ince the CPU requ ires EC:C over 32-bit words, we
chose to combine the two correction mechanisms
i nto one. This decision was consistent with our goa l

Digit aT Technical journal

Viii. 4 No. 4

.\jJeciaf Issue 1')'}2

Bus Signals

Sig nal Name

P i ns

-Data[63 .. 00]
- ECC0[6 .. 0]
- ECC1 [6 .. 0]
-P[O]

64
7
7
1

- P[1 ]

Use
Data
ECC on Data[31 .. 00]
ECC on Data[63 .. 32]
Even Parity over
Data[31 . . 00], ECC0[6 .. 0]
Even Parity over
Data[63 . . 32], ECC1 [6 .. 0]

8-shared
8-di rty

1
1

Cache coherence
Cache coherence

Retry
Error

1
1

Storage module busy
Data or address parity error

Arb Request

8

Arbitration for the bus

Clock
Phase

2
1

1 00 MHz d ifferential clock
50 M Hz Reset 1

nTy peCik
nType
nld

1
1
4

Module identification
Mod u le identifi cation
Modu le slot nu mber (0 .. 1 3)
set by backplane wiring

of simpl ifying the design and i m provi ng p erfor
mance at the exp ense of i ncreased cost. The parity
bits are provided to detect bus errors duri ng
address and data transfers. A ll modu les generate
and check bus pari ty.
The module identification signal s are used only
d ur i ng system i n i t i a l ization. Each module type is
assigned an 8-bit type code, and each backplane slot
is wired to prov ide the s lo t numbe r to the modu le i t
contains. E a c h module i n t h e system reports its
type code seria l l y on the nType line during the 8 X
slot n u m be r nTypeCik cycles after the deassertion
of system reset. A configuration process running
on the console processor toggles nTypeClk cycles
and observes the nType l in e to determ i ne the type
of m odule i n each backplane slot.
The 100 -megahertz (MHz) system clock is d is-
tributed rad i a l l y to each module from a clock gen
erator on the backplane. Constant -length w i ri ng
and a strictly specified fan-out path on each mod
u le controls clock skew. S i nce a bus cycl e takes two
clocks, the phase signal is used to identify the first
clock period .

Addressing
The bus supports a physical address space of 64
gigabytes (2Y' bytes). The resolution of a bus address
is a 32-byte cache block, which is the o n ly unit
of trans fe r supported; consequently, 31 address
bits suffice. One-quarter of the address space is
reserved for control registers rather than storage.

53

AJpha AXP Architecture and Systems

Accesses to this regi o n are treated speci a l l y : CI'Us
do not store data from this region in their caches,
and the target need not supply correct ECC b its.
'The method used to select the target module of
a bus operation i s geographic. The i n i t iator sends
the target module's slot number with the address
du ring a request cycle. Jn addition to the 4-bit slot
number. the ini tiator suppl ies a 3-bit sufJn ode iden

monitors a l l bus operations and m u st request only
those cycles that it knows the target can accept .
I n i tiators are a llowed to arbitrate for a particu l a r
target n i ne or more cycles after t h a t target has
started a read, or ten or more cycles after the target
h as started a write. To arbitrate, an i n i tiator asserts
the ArbRequest l i ne corresponding t o its current
priority. Priorities range from 0 (lowest) to 7 (high
est) If a m odu le is the h ighest priority requester
( i . e . . no h igher priority ArbRequest l ine tha n its
own is asserted). that module wins the a rbitration,
and i t transmits an add ress ami a co m m ancl i n the
next cycle. The winning mo dule sets its priority to
zero, and a l l in itiators w i t h priority less than the i n i
t i a l priority of the winner i ncrement their priority

tifier with the address. Subnodes are the u n i t of
memory inte rleaving. The 64Mll storage m od u l e ,
for example, contains two i ndependent 32 MB sub
nodes that can operate concu rrent l y.
The geographic selection of the target means that
a particu lar subnode o n ly needs to com pare the
requested slot and subnode bits with its own slot
a nd subnode numbers to decide whether i t is the
target. This reduces the time requ i red hlr the deci
sion compared to a scheme i n which the target
i nspects the address fielcl, but it means that each ini
tiator must m a i ntain a mapping between physical
addresses and slot and subnocle numbers. This m ap

regardless of wbether tbey made a request du ring
the arbitration cycle. Initial ly, each i n i ti ator's prior
ity i s set to its slot nu mber. Priorit ies are thus
d istinct i n i t ia l ly and remain so over time. This a lgo
rithm favo rs in itiators that have not made a recent
request, since the pri ority of such a n i n it i ator
i ncreases even if it d oes not make requests. If a l l ini
tiators m a ke conti nuous requests, the algori thm
prov ides rou nd-rob i n servicing, but the i mpl emen
tation is simpler than round robin.
An arbitration cycle is fol lowed by a request
cycle. The i n i t iator pl aces an address, nocle and
subnode n u mbers, and a command on the bus.
There are only three com mands. A read com mand
requests a 32-byte cache block from memory. The
target memory or a cache that contains a m o re
recent copy supplies the data after a five-cycle
delay. A write com mand transm its a 32-byte block
to m e mory, u s i ng the same cycles for the data trans
fer as the read com m and . Other caches m ay also
take the bl ock and update their contents. A victim
write is issued by a CPU mod u l e when a block is
evicted from the secondary cache. \Vhen such an
evic tion occurs, any other caches that con tain the
bl ock are guaranteed to con tain the same value, so

ping is performed by a RA.tv1 i n each i n i t iator. For
CPll modules, the RAM lookup does not redllce per

formance, since the access is done in paral l e l with
the access of the modu le's seco ndary cache. The
slot-mapping RAMs in each in i tiator are loaded at
system i n i t i a l i zation time by the configuration pro
cess described previously.

Bus Operation
The timing of addresses and data is shown in Figure 3.
A l l data transfers take place at fixed t i mes relative
to the start of an operati on. E ight of the backplane
slots can contain modu les capable of i n i tiating
requests. These slots are numbered from 0 to 7, but
are located at the center of the backplane to reduce
the transit time between i n i t i ators and targets.
A bus cycle starts when one of the init iators arbi
t t·ates fo r the bus. The arbitration method guaran
tl'es that no initiator can be starved. Each i ni tiator

CYCLE
A R B REQUEST
DATA

0

1

2

3

5

6

7

8

9

10

12 13

11

I

R3

R2

R1

14

1 5 1 6 1 7 1 8 1 9 20 2 1 2 2 2 3 2 4 25
R4

A 2 0 1 01 0 1 01 A3 02 02 02 D2 j A4 03 0 3 03 03

A1
81

B-SHA R E D . B - D I RTY

ERROR

4

E1

E2

S2

This f i g u re shows the contents of the bus during four read cycles.

If

E3

04 04 04 1 04

S4

S3
E4

requests are made at full rate, the bus i s fully occupied

with addresses and data. B-shared and B-diny are sent in the fifth cycle after the arbitration request. If any module detects a
parity error during an address cycle, it assens error two cycles later.

Figure 3

'5 4

Bus Timing

Vol. 4 No. 4

.)fH!Cial lssu" 199.!

D igital Tecbuical jounwl

Tbe Alpha Demonstra tion Unit

they need not part icipate in the transfer at a l l. The

the blocks in other caches whenever the associated

block is stored in memory, as in a normal write.

CPU pe rforms a write. I f no other cache shares
a block, this write through is unnecessary and is
not done. When a secondary cache receives an

Cache Coherence
Tn a m u l tiprocessor system with caches, it is essen
tial that writes done by one processor be made
avai lable to the other processors in the system in
a timely fas hion. A n u m ber of approaches to the

cache coherence problem have appeared in the lit
erature. These approaches fa l l i n to two categories,
depen d i ng on the way in which they hand le proces
sor writes. Invalidation or ownership protocols
require that a processor's cache mus t acqu ire an
exclusive copy of the block before the write can be
done ..' If another cache contains a copy of t he
block, that copy is invalidated. On the other hand,

update protocol s maintain coherence by perform
ing write- t h rough operations to other caches that
share the block . 2 Each cache m aintains enough
state to determine whether any other cache shares
the block. I f the data is not p resent in another
cache, then write through is un necessary and is
not done.

The two protocols have q u i te d i fferen t pe rfor
mances, depending on system activity. ' An update
protocol pe rforms better than an invalidation pro
tocol in an application in which data is shared (and

u p date (i.e . , it observes a write on the bus d irected
to a block it contains), it has two options. It can
invalidate the block a n d report to the writer that
i t has clone so. If it is the only cache sharing the
block, subsequent write-through operations will
not occu r. Alternatively, i t can accept the update
and report that it did so, i n wh ich case the cache
that performed the write-through operation con
tinues to send updates whenever its CPU writes the
bloc k .
The actions t a k e n b y a cache that receives an
update are determi ned by whether the block is in
tbe CPU's on-chip cache. The secondary cache con
tains a table that a l lows i t to determine this without
interfering with the CPU. If the block is in the on
c h ip cache,

the secondary cache accepts the

update and i nval idates the block in the on-chip
cache. lf the block is not in the on-chip cache, the
secondary cache block is i nval idated. If the block is
being actively shared , it wi ll be reloaclecl by the CPU
before the next update arrives, and the block w i l l
continue t o b e shared . If not, t h e block w i l l b e inval
idated when the second update arrives.

written) by mult iple processors (e .g. , a paral lel
a lgo rithm executing on severa l processors). In an

Implementation of the Protocol

invalidation protocol, each time a processor writes

The i m plementation of the coherence protocol is

a location , the block is inval idated in a l l other
caches that share it. A l l caches require an expensive
miss to retrieve the block when it is nex t refer
e nced. On the other hand, an up date protocol per
fo rms poorly in a system in which processes can
m igrate between processors. Wit h m igration, data
appears i n both caches, and each time a processor
writes

a

location,

a

write- t h rough

operation

updates the other cache, even though its CPU is no
longer interested in the bloc k. Larger caches with
long block lifetimes exacerbate this problem.

not complex. The five possible states of a secondary
cache block are shown in Figure 4. Initial ly, a l l
blocks i n t h e cache are m a rked inva l i d . Misses i n
t h e CPU's on-ch ip cache cause a bus read to be
issued if the block is not in the secondary cache. If
the cache block is assigned to another memory loca
t io n and is di rty (i .e . , has been written since it was
read from memory), a v ictim write is issued to evict
the block, then a read is issued. Other caches moni
tor operations on the bus and assert the block
shared (B- shared) signal if they contain the block.
If a cache contains a d irty block and it observes

Coherence Protocol

a bus rea d , it asserts 8- shared and B - d i rty, and

The coherence protocol used in the ADU is a hybrid

suppl ies the data . B-dirty i n h ibits rhe memory's

of a n update and a n invalidation protocol, and l ike

delivery of data.

many hybrids, it combines the good features of

The CPU's on-chip cache uses a write- through

both parents. The protocol depends on the fact that

strategy. A CPU write to a shared block in the sec

the CPU chips contain an on-chip cache backed by

ondary cache i n itiates a bus write to update the

a m u ch l arger secondary cache that monitors a l l

contents of other caches that share the block.

bus operations. I n i t i a l ly, the secondary caches use

Memory is written, so the block becomes clea n . If

an update protocol . Caches that contain shared

a nother cache takes the update, it asserts B-shared,

data p erform

a

write-through operation to update

D -ig ital Teclmical journal

Vol. 4 No. 4

Sjlel'ial /ssue 19?2

and the initiator's state becomes Sharecl not (-)

55

Alpha AXP Architecture and Systems

C-READ
C-WRITE

C-READ

-SHARED
- D I RTY

r-------����---.
C-READ
( -B-SHARED)
B-WRITE,
-INC

C-WRITE

(-B-SHARED)

- S HA R E D
D I RTY

B-WRITE,
-INC

B-READ

B-WRITE, I N C ;
B-READ
C-READ
(B-SHARED)
B-WRITE,
-INC

SHARED
- D I RTY

B-WRITE, I N C
B-WRITE, I N C; C-WRITE (B-SHARED)

C-WRITE (B-SHARED)
C-READ
B-WRITE, I N C
B-READ

SHARED
DI RTY

C-READ
B-READ

Transitions occur as a result of CPU reads and writes (C-read, C-wrile) and bus operations

initiated by other caches o r 1/0 controllers (B-read, B-write). A C-read or C-write to an invalid

block causes a B-read; a C-write to a shared block causes a 8-write. The B-shared response

indicates that some other cache contains the block. I N C indicates that the block is in the CPU's

on-chip cache.

Figure 4

Secondary Cache Line States

Dirty. I f no other cache takes the u pdate, either
because i t does not contai n the block or because it
decides to inval idate it, then the B-shared signal is
not asserted , and the i n i t iator's state becomes
-Shared - D i rty. The B-sh ared and B - d irty sign a ls
may be asserted by several modu les d ur i ng cycle
five of bus operations. The responses are ORed by
the open-emi t ter ECL backplane drivers. More than
one cache can conta i n a block with Shared
true,
but only one cache at a time can contain a block
=

with Dirty

=

true.

Designi ng the bus interconnect and coherence

By running this program with sequences o f simu
l ated memory requests, we were able to refine the
design rapid ly and measure the performance of the
system befo re designing any logic. Most design
errors were discovered a t this time, and prototype
system debugging took much Jess time than usu a l .

System Modules
In this section, we describe the system modules
and the packagi ng of the ADU. We d iscuss the
design cho ices made to produce the CPU modu le,
storage modu les, and I/O modu l e on sched u l e . We
also d iscuss appl ications of the ADU beyond its
intended use as a vehicle for software development.

protocol was an experiment i n specification. The
informal description required approximately 15
pages of prose to describe the bus. The real specifi
cation was a m u l t i th readed program that repre
sented the various inte rfaces at a l evel of derail
su fficient to describe every sign a l , but, when exe
cuted, simu l ated the components at a higher .leve l .

The ADU CPU m o d u l e consists of a single CPU chip ,
a 256 -ki lobrte (KB) secondary cache, and an i nter
face to the system bus. Al l CPU modu les in the

56

Vu/. 4 No. 4

CPU Module

.\fJecial lssue

1992

D igital Technical journnl

The Alpha Demonstration Unit

system a re identica l .

The C: P l l

modu les are not sel f

s u fficie n t ; t he y m ust be i n i t i a l ized by t h e console

workstation before the

CPU

inval idation fi lter and s ele cts between u pdate a nd

inval idation strategies.

The system bus i nterface watches for reads and

can he enabled.

The CPU modu l e contains extensive test access

logic that a l l ows other bus agents to read and write

writes o n the bus, and looks up each address in the
secondary cache. O n read hi ts, i t asserts B -shared

most of the mod u le 's in ternal state. We imple

on the bus, and, if the block is d i rty i n t h e sec

mented this logic becau se we knew these mod u l e s

o ndary cache, it asserts B-dirty and s u p p l ies re ad

would be used to debug CPU ch ips Test access logic

d:.�ta to the bus. On write hits, it selects between the

.

chip

inva l idate and update st r at e g ies , mod ifies the con

ma l fu nction and wou ld make i t possible for us to

trol field in the secondary cache tag store appropri

wou ld h e l p us determine the cause of a

CPU

introduce errors i n r o t h e secondary cache to test

ately, and, i f the u p d ate strategy is selected, it

the error detection and correction capabil ities of

accepts data from the system bu s .

th e

CPU

chip. This logic was used to perform almost

a l l initial ization of th e
used to troubleshoot

CPU

Unl ike most bus d e vi ces

,

the

CPU modu le 's

mod u le and was a lso

system bus i nterface must accept a new address

mod u les after they were

every five cycles. To do this, it is impl eme n t e d as

CPU

two indepe ndent finite state machines connected

fabricated.
The centra l feature of the

CPli module (shown

in Figure '5) is the secondary cache, built using 16K
by 4 BiCMOS static RAMs. Each of the 16K h a l f

together i n a p i p e l i ned fashion.

The tag stare m a c h i n e , which operates d uring
bus cycles

I through 5. watches for addresses, per

blocks i n t h e d a t a store is 1 '5 6 bits wide (4 long

forms a l l tag store reads (in bu s cyc l e 4. just i n time

words of data, each protected by 7 ECC bits). Ea c h

to assert B-shared and 8-dirt y in bus cycle 5) , and

of the 8K entries in the tag store is an 1 8 -bit address

p erforms any needed rag store wri tes ( i n bus cycle

( p rot ecte d by parity) and a :'1-bit control field

'; ) . If the tag state machine determines that bus data

(va lid/shared/d i rt y, also p rot ec t e d by p arity) . I n

m ust be suppl ied o r accepted, it enables the data

addition, a secondary cache dupl icate t a g store,

state machine, and, a t the same time, begins p ro

c onsist ing of an

cessing the next bus request.

1 8 -bit add ress and a v a l id bit

(protected by parity), is used as a h i n t to speed pro

The data state machine, which operates d u ri ng

cessing of reads ami writes encou n tered on the

bus cycles 6 through 10. moves data to a mi from

chip data cache dupl icate

the bus and hand les the read i ng and writing of the

tag store (protected by pa rity) fu nctions as an

s e conda ry cache data store. The h ig h l y p i pe l i ned

system bus. Finally, a

CPU

BYPASS

Figure 5

Digital Tee/mica/ journal

Vr>l. 4 No.

4

.\jJecial fssue 1')91

CP 1\1/odule

57

Alpha AXP Arc hitecture and Systems

nature of the system bus makes reading and writi ng

The bidirectional data bus of the CPU chip is con

the data store somewhat trich-y. Figure 6a shows

verted into the u n i d i rectional data buses used by

a write h i t that has selected the update strategy

the rest of the CPU modu le by transparent cu toff

i m mediately fo l lowed by a read hit that must supply

l atches. These latches, which are located in a ring

data

surround i ng the CPU , also convert the quasi-ECL lev

to the

bus.

High performance m a ndates

the use of c locked transceivers, which means the

e l s generated by the CPU chip into t r u e EC L levels

secondary cache data store m us t read one cycle

for the rest of the CPU module. These l a tches are

ahead o f the bus ancl must write one cycle behind

norma l ly h e l d open, so the CPU chip is, in effect,

the bus, resu l t i ng in a conflict in bus cycle 1 1 .

connected d i rectly to the secondary cache tag and

However, the bus transfers data i n a fixed order,

data RA...VIs. Con t ro l s ignals from the CPU chip's i n te

so the read w i l l always access quadword 0 of

grated secondary cache con trol ler are simply ORed

the block, and the write wil l a l ways access quad

i nto the ap propriate secondary cache RAM drivers.

word 3 of the block. By implementing the data

These latches are a l s o used to pass data across

store as two 64-bit-wide banks, i t i s possible to han

the

d le these back-to-back transactions without creat

latches are open. On reads, logic in the CPll chip

ing any special cases, as shown i n F igure 6b. This

clock domain c l oses a l l the latches and sends a read

two-clock-domain

boundary.

Norma l ly

al l

example is typ ica l of the style of design used in the

request into the bus clock domain. Logic in the bus

ADl l , which e l i m i nates extra mechanisms wherever

clock domain obta ins the data, writes both the sec
ondary cache and the read latches, and sends an

possible.
The CPU inte rface hand les the arbitration for the

acknowleJgment back into the CPU chip cl o c k

secondary cache and generates the necessary reads

d o ma i n . Logic i n t h e CP\ J c h i p clock d o m a i n

and wri tes on the system bus when the CPl . sec

accepts the f i r s t h a l f-block o f t h e d a t a , o p e n s the

ond ary cache misses.

f irst read latch, accepts the second h a l t� l i n e of the

The CPU chip is supplied with a clock that is not

data, and opens a l l rem a i n i ng latches. \'hires are

rel ated to the system c lock i n frequency or phase.

s i m ilar. Logic in the CPU chi p clock domain w r i te s

This factor made i t easier to use both the 100-MHz

t h e first h a l f- l i ne i n t o t h e write l atch, ma kes the

frequency o f t h e D C 2 27 proto type c h i p and the

second h a l f- I ine valid (beh i n d the latch), and sends

200 -MHz frequency of the DECch ip 21064 CPU. It

a write request in to the bus clock dom a i n . Logic in

also al lowed us to vary the operating frequency

the bus clock dom ain accepts the first hal f-l i n e of

dur i ng CPU chip debugging. However, the data

data, opens the write latch, accepts the secoml ha l f

buses connecting the CPU chip to the rest of the

block of data, and sends an acknowledgment back

CPl l modu le must cross a clock-domain boundary.

i nto the CPl J chip clock domain .

Pe rhaps more sign ificant, the secondary cache tag

Logic i n the C P l J chip clock domain contro l s a l l

and data stores have two asynchronous sources of

l atches. Only t wo signals pass through synchro n i z

contro l , since the CPU ch ip contains an i ntegrated

ers:

secondary cache control ler.

clock d o m a i n to the bus c l oc k d o m a i n , and a s ingle

CYCLE
WRITE CYCLE
READ CYCLE

0
WO

Vl/ 1

WRITE CYCLE
READ CYCLE

CACHE EVEN

CACHE ODD

0

wo

W1

4

5

6

7

8

W2

Vl/3

Vl/4

W5

W6

W7

W8

Vl/9 Vl/ 1 0

Vl/7

W8

9

RO

R1

R2

R3

2

3

4

5

6

7

8

W2

W3

Vl/4

W5

W6

W7

W8

RO

R1

R2

R3

Vl/7

R4

R4

Vl/8

11

12

t

10

R5

Vl/9

si ngle request signal passes from the CPU chip

13

14

15

R9

R10

Figure 6 a shows a

to

conflict

for access

the secondary cache RAMs caused

by back-to-back cycles. In the marked

R 5 R6
R7
W9 W 1 0 R8
R7

W9 Vl/ 1 0

Figure o

'58

10

3

CAC H E

CYCLE

9

2

a

R8

R9

R10

11

12

13

14

R6

R7

R8

R9

cycle. the cache writes the bus data
that arrived i n cycle Vl/ 1 0 . but i t also

needs to read data to supply it during
cycle R7.

15

Figure 6b shows how this conflict can

be resolved by treating the cache as

two independent banks (even and
R7

Vl/ 1 0 R 8

R9

R10

odd).

R10

CPU Timing

Vol.

4 No. 4

.\jJeCi(f/ /sm e

I'J'Jl

Digital Tecbuica l jourual

The Alpha Dernonstration l!nit

acknowledge signal passes from the bus c lock
domain to the CPU chip clock domain.
The seco ndary cache arbitration scheme is
unconventional because the system bus has no sta l l
mechan ism . I f a read o r a write appears o n the
system bus, the bus inte rface must have u ncondi
tional access to the secondary cache; i t cannot wait
fo r the CPU to finish its current cycl e. I n fact, the
bus interface cannot detect if a cycle is i n progress
in the CPU chip's integrated cache controUer.
Nevertheless, a l l events in the system bus inter
face occur at fixed times with respect to bus arbi
tration cycles. As a res u l t, the system bus inte rface
can supply a busy signal to the CPU interface, which
al lows it to predict the bus interface 's use of the
secondary cache in the im med iate future. The CPU
inte rface . therefo re, wa its u n t i l the secondary
cache can be accessed without conflict ami then
performs its cycle without add itional checking.
This waiting is performed by the CPU ch ip's i nte
grated secondary cache control ler for some cycles,
and by logic in the CPU in terface r u n n i ng in the bus
clock domain for other cycles. To reduce l atency,
the CPU reads the secondary cache while wa i t i ng.
and ignores the data if it i s not yet valid.
All operations use ownersh ip of the system bus
as an inte rlock . For example, if the CPU writes to a
location i n the secondary cache that is ma rked as
shared, the CPU interface acquires the system bus,
ancl t hen updates the secondary cache at the same
time as it broadcasts the write. This cloes not e l im i
nate all race conditions; i n particu lar, it a l lows a
dirty secondary cache block to be inval ida ted by
a system bus write wh ile the CPU i n terface is wait
ing to acquire the bus to write the block to memo ry.
This is easily hand led, however, by having the CPU
i nterface generate a signal (always_u pdate) that
insists that the system bus interface select the
U [)date Strategy.
The combination of arbitration by predicting
fut u re events and the use of the system bus as an
interlock makes the CPU module's control logic
extremely s imple. The bus interface and the CPU
i nterface have no knowledge of one another
beyond the busy and always_update s ignals. Since
no compl icated i nteractions between the CPU and
the bus exist, no ti me-consum ing simu lations of the
i nteractions needed to be performed, and we had
none of the diffi c u l t - to- track-dow n bugs that are
usua l l y associated with m u ltiprocessor systems.
The CPU module contains a nu mber of control
registers. The bus cycles that read and write these

Digital Techuical ]ounwl

VrJI. 4 No. 4

Special Issue 1 ')')2

registers are processed by the sysrem bus inter
face as ord inary, but somewhat degenerate, cases.
The local CPU accesses its local registers over the
system bus, using ord i nary system bus reads ami
writes, so no special logic is needed to resolve race
conditions.
To keep pace with our schedule. we arranged ti.> r
most of the system to be debugged befon: the CPU
chip arrived . By using a suitably wired in tegrated
c ircu it test c l ip, we could place com mantis onto
the CPU chip's com mand bus and ver ify the control
signa ls with an oscil loscope. The results of tiH:se
rests left us fa irly confident that the system worked
before the first chip arrived.
We resu med test ing the CPU mo du le :t ft<:r the
CPU chip was instal led . We placed short ( th re<: to
five instructi ons) programs into main memo ry,
enabled the CPU chip for a short time, then
i nspected the secondary cache (using the Cl' l l mod
u le's test access logic) to examine the results.
Eventua l ly we con nected an external pu i s<: gen
erator to the CPU chip's clock and an extern al
power supply to the CPU chip. These mod ifications
permitted us to vary both the operating frequencv
and the operating vol tage of the CPU chip. By using
a p ulse generator a nd a power su pply that cou ld be
remotely con trol led by another computer, we were
able to write simple programs that could run CPU
chip diagnostics, without manual i ntcr ve ntion,
over a wide range of operati ng cond itions. This
greatly simplified the task of col leering the raw data
needed by the chip designers to ver i fy the critical
paths in the chip.

Storage Modules
The ADU's storage modu les must prov ide high
bandwidth, both to service cache m isses and to
support demanding 1 /0 devices. More impo rtant,
they must prov ide low l atency, since in t h e case of a
cache m iss, the processor is stal led until the mi ss is
satisfied. It is a lso im portant to provide a modest
amount of memory in terleaving. Although the bus
protocol a l lows o n ly two memory suhnodcs ro be
active at once, higher interleave increases rhe prob
abil i ty that a m od u le wiJJ be free when a memory
request is issued.
Each storage module is organized as two
independent bus subn odes, so that even in a sys
tem with one modu l e , memory is two-way in ter
leaved. Each of the subnodes consists of fou r banks,
each of which stores two longwords of data
and their associated error correction bits. \'1/ith

59

AJpha AXP Architecture and Systems

!-megabit (Mb) RAM chips, the capacity of each

A memory cycle consists of a five-bus -cycle

module is 64,VIB. Figure 7 shows the organ ization

access period fol lowed by four bus cycles of data

of the storage module. The modu le consists of

transfer. Each data transfer cycle m oves t wo 39 -bit

two i ndependent subnodes, each with fou r banks

longwords between the modu le and the backplane

of storage. Control signals are pi pel inetl through

bus, for a total of 32 data bytes per memory cycle.

the banks so that the module can del iver or accept

This is the size of a CPU module cache block. A read

a 64-bit data word (plus ECC) every 20 ns. With

operation takes 10 bus cycles to complete, but a

the exception of the DRAM i nterface signa ls, a l l

write requires 1 1 cycles.

signals are ECL levels. The G014 gall i u m arse

Since a data rate of I word every 20 ns is beyond

n ide (GaAs) driver chip improves performance

the capabilities of even the fastest ni bble-mode

by a l lowing para l lel termination of the DRAM

RAMs, we needed an approach that did not requ ire

address I ines.

each RAM to prov ide m o re than 1 bit per access.

I - - - -__
-__
-__
- - - - - - - - - - - - - - - - - - ,
BA N_
K 3
�
I
_ _

I
I
I
I

�
1 M BY 39-BIT

STORAGE C A R D

G014

1 M BY 39-BIT
STORAGE CARD

CHIP

I

1M BY 39-BIT
STORAGE C A R D

1 M BY 39-BIT
STORAGE CARD

I

BANK 1
1 M BY 39-BIT
STORAGE CARD
1M BY 39-BIT
STORAGE CARD

1 M BY 39-BIT
STORAGE CARD
1 M BY 39-BIT
STORAGE CARD
_

_

_

_

_

_

_

_

ADDRESS

_

_

I
J
_

_

j

BANK ENABLES

DATA + ECC,
ADDRESS (39)

CONTROL

DATA +
ECC (39)
BACKPLANE

Figure

60

7

ADU Storage /11/odu/e

HJI. 4 No. 4

Special issue 1992

Digital Tecbnica/ journal

The Alpha Demonstration Unit

We chose to pipel ine the fo ur banks of each sub
node. Each of the fou r banks contributes onl y one
78-bit word to the block . The banks are started
sequential ly, with a o ne-cycle delay between each
bank.

A

The h igh performa nce of the storage module
is ach ieved by ma intai n i ng ECL levels and using
ECL

V Vh0
_______r----
VB Vh1,
Vhs--0
VC: Vh__j
0

lOOK components wherever possible.

The

RAM I/O pin levels are converted to ECL levels by

la tch i ng transc eivers associated with each bank.
Fo rtun ately, the tim ing of accesses t o the t wo sub

-1

nodes of a modu le makes it possible to share these
transce ivers between the same banks of the mod
u le 's two subnodes.

l

-

2t

Series termination resul1s in a half-amplitude signal at the first
RAM on the line until the signal reflects from point C

The DRAM ch ips are pac kaged on s m a l l daughter
cards that plug int o connectors on both sides of the
main array module. There are

(a)

2 daughter cards fo r

Series Termination

each bank within a subnode, fo r a total of 16 daugh
ter cards per module. The DRAM address and co n
trol l i nes are carried on control led i m pedance
traces. Since each of the 39 DRAMs o n an address
l i ne represents a capacit ive load of approximately 8
picofarads, the loaded i m pedance of the l i ne is
about 30 ohms.
The usual approach to driving the address and
control l i nes of a RAM array uses series termination,
as shown in Figure 8a. This arrangement has the

VA: Vh0
vc v0h__j

advantage that the driver c u rrent is reduced, si nce
the load i mpedance seen by the driver

(Rs

+

twice that of the loaded transmission l in e

Z0 is
(Z).

Parallel termination saves one line transit time, but increases
driver current.

UnJort unately, the RANI access time is i n creased,

because the sign a l from the driver ( �,) m u st propa

( b)

Parallel Termination

gate to the far end of the l i ne, be reflected, and
return to the driver before the first RAM on the I ine

Figure 8

sees a fu l l-ampl itude sign a l . Sinc e the capacitive

Address L ine Termination

load ing added by the RAM p i ns lowers the signal
propagation ve locity in addition to reducing the

address l i nes, and a driver fo r one of the three RAM

impedance, the added delay can be a significant

control signa l s (RAS, CAS, Write). To reduce the cur

fract i o n of the overa l l cycle time.

rent switched by each chip, each add ress bit drives

Since low latency was a prim ary design goa l , we

two output p i ns. One pin carries true data, and the

chose paral lel termination of the HA.�\1 address and

other is complemented. The total current is there

control l i nes, as shown i n Figure 8b. Each address

fo re constant. Each p i n drives one of the two RAM

I ine is t e r m i nated to +3 vol t s with a series resistor

modu les of a bank. A total of three GaAs chips

of 33 ohms, sl ightly hi gher than the l i ne

is required per bank. In the present module, with

(R)

im pedance. In this configurat ion, each line's driver

I M- by 1 - bit RAM chips, only 10 of the

must sink a cu rrent of al most 0.1 am pere. Since no

drivers are used, so the

com mercial c h ip cou l d meet this req u i rement at

expanded to make use of 16M RAMs.

the needed speed, we comm issioned a semicustom
GaAs chip.'

The

storage

m o d u le

12 address

system can be easily

contains

only

a

sm a l l

amount of control logic. This logic generates th e

As shown in Figure 9, each GaAs ch ip contains a

con trol

signa l s

fo r

the

RANis

and

the

various

register fo r eight address bits, row/col u m n address

transceivers that route data from the bac k p l a ne to

m u l tiplexing and h igh cu rrent drivers fo r the RAM

each ban k. This logic a l so generates the sig nals

Digital Technical Journal

11)/. 4 No. 4

Special Issue 1992

61

AJpha A.XP Architecture and Systems

to exercise new CPU chips and u n tested software.

A31

I

A20
A2 1

0
A1

A3
-A3

With t h i s in m i n d , we orga n i zed the 110 system
aro u n d a D ECstation 5000 \vorkstation as a fro n t 
e n d ;� n d co nsole processor. T h i s reduced our work

I

considera b l y, as a lJ I/O is done by the workstation. A

I

TLI RBOchannel m o d u l e connects the DECstation

I

:

A2
-A2

5000 over a 50M B/s cable to the 1/0 m o d u le in the
ADU. \Ve selected 50:vil:l/s in order to s u pport the
s i m u l t a neous, peak-bandwidth opera t i o n of two

SCSI

I
I

disk strings, a n E t hernet, and a fi ber d is

trib uted data i n terface

(F DDl) n e t work adapter. The

I/O m o d u le contains t wo of these cha n n e l s, w h i ch

I

a l lows t wo DECs tation 5000 wo rkstations to be

I

a ttache d .
A t the hardware leve l , t h e l/0 system supp o rts
block tra nsfers of data from the m a i n mem ory of
the workstat i o n to and from

r-.::-----l. AO
LA5----+ -AO
I

bel l registers, which are used by ADU processors to
attract the attention of the l/0 syste m .
I n software, 1/0 requests are pl aced b y A D U pro

I

cessors i n to com mand ri ngs in A D U memo ry. The

I

memory add ress of a com mand ring i s placed i n t o
SELOUT
CTRLA
CTRLB

CTRLOUT

C LK

mem ory. In add i

I

I
I

-

AD l J

tion, the l/0 module i n c l u d e s com m a n d a n d door

a n l / 0 co n t rol register, a n d the associated doorb e l l
is rung. The doorbell caus es a h a rdware i n terrupt
on the fro n t - e n d DECs tation 5000, which alerts the
l/0 server process that action is neede d . The 1/0
server reads the command ring from A D U memory
and pe rforms the requested l/0. 1/0 completion sta

L

_

_

_

_

_

_

_

_

_

_

_

_

_

l

tus is stored i nto ADU memory, a n d an i n terrupt is
s e n t to the requ esting ADU processor.
ln a d d i t i o n to its role as an l/0 fro n t - e n d proces

h�C{ure 9

Address and Control Driver

sor, the DECstation 5000 workstat i o n acts as a d i ag
nostic and console processor. W h e n an ADU is

ncl:lied to refresh the RAMs a n d to assert the retry
s i gnal i f another node att e m p ts to access the m od
u le w h i le it is refreshing itself.

1/0 m od u le is tested . Then the A D I J module iden t ifi

cation process determines the types and locati ons
of a l l CPU and storage m o d u les in the system .

1/0 ,Hodule

Di agnostics are then run for each m o d u l e .

The 1/0 module for the A D l l cont <�ins two 50Mfl/s
1/0 c h a n n els ami a l oc a l

powered on, d i agnostic software is r u n from the
workstation. First, the correct fu n c t i o ning of the

Cl'U

subsystem . The 1/0

O n c e d iagnos tic software h a s run, the console
software is given con tro l . This software is responsi

channels connect to one o r t wo DECstation 5000

ble t(>r loading privileged architecture I i b rary ( PAL)

wo rkstations, w h ich act as 1/0 fro n t - end proces

a n d operating system software. Once the operating

sors and also p rovide console and d i a gnostic func

system i s r u n n i ng, the wo rkstation becomes an 1/0

tions. The local CPU su bsystem is used to provide

server.

i n te rval timer and ti me-ofday clock services to ADU
The origi n a l specifi cation fo r the ADU 110 system
requ i red support only fo r serial l i n e , small com
puter systems i n terface

(SCSI)

disk, and Ethernet

1/0 devices. We k new that the AD

62

The presence of t h e DECstation 5000 gave the
chip team a n d operating system developers a stable

processors.

wou ld be used

place to stand w h ile checking out their own c o m
ponents. In add i t i o n , the complete d i agnostic capa
b i l ity and error checking cove rage of the ADU
hardware helped to iso late fau I ts.

Vol. 4 No. 4

Special Issue I')')!

Digital Technical journal

The Alpha Demonstmtion Un it

The central featu res of the 1/0 module, shown i n
Figure 10, are two l K- by 80 -bit register fi les b u i l t

block- transfer state machine

that

hand lt:s

bus

transfers.

from 5 -ns ECL RAMs. These memories a r e cycled

Each l/0 channel carries 32 bits of data p l u s 7 bits

every 10 ns to s i m u l a te dual -ported memories at the

of ECC i n parallel on a 50-pair cable. Each data word

20-ns bus cycle rate. One memory is used as a stag

also carries a 3-bit tag t hat specifies the destination

ing RA.tvl for block transfers from the 1/0 processors

of the data. The cable is h a l f-du plex , with t he (]irec

to ADU memory. The other memory is shared

t i o n of data flow under the control of software on

between use as com mand register space for the 1/0

the DECstation. Data arriving from the DECstation is

system and a staging RANI for transfers from ADU

bu ffered in 1 K F!FOs. These FIFOs carry data across

memory to t he 1/0 syste m .

the

On t h e b u s s i d e , t h e register files are connected
d i rect l y to the backpl a ne bus tra nsceivers. On the

l/0 side, the register files are connected to a shared
40-ns bus that connects to the two 110 channels.

clock-dom a i n

boundary

between

the

110

system and the ADU and permit both 110 channels
to run at fu l l speed simultaneously.
Each l/0 channel i nterface a l so has an address
counter and a slot - m a p p i ng IV\,\1 , which are loaded

The buses are ti me-slotted to el i m i nate the

from the workstat ion. The slot-mapping function

need for arbitration logi c. As a consequence, the

sets

110 module control logi c is contai ned in a sma l l

add resses and the geographical ly addressed storage

the

correspondence

between

ADl l

bus

nu mber of progra m m able array logic chips that

and CPU modu les. The address r
its original p urpose of supplying d isk, netwo rk , and
console 1/0 service for A D U processors. This capa
b i l i t y was put to use in mid-1991 when rhe demand
for ADUs became so inte nse t hat we consid ered
bui lding addi tional systems. I nstead. by using the
excess 1/0 resources. the slot-m a p p ing features of
the hardware, and the capab i l i ties of PAI.code, we
were able to use a three-processor ADli as th ree
i ndependent v i rt u a l compu ters. I ndependent
copies of the console program shared the l / 0 ba ni
ware through software lock ing and were al located
one CPU and one storage modu le eac h .
M u l tiprocessor A Dl ls now routi nely r u n both
OpenV,VlS A X P and DEC: OSF/ l AXP operati ng S\'S
tems at the same t i m e .

Packaging

used to hold d isks. Power suppl ies are off- the-shelf
u n i ts. Three suppl ies are requi red to provide the
4,000 wat ts consumed by a system con ta i ning a ful l
complement of modules. A standard power condi
tioner p rovides line fi l te ring and d istribu tes pri
mary AC to the power supplies. This u n i t al lows the
system to operate on 1 10 -vol t AC in the Un i ted
Sta tes, or 220-volt AC in Europe.
Cool ing was the most d ifficu l t part of the packag
i ng effort. The use of ECL t h roughout the system
meant t ha r ·we had to p rovide an a i rflow of a t least
2.5 m/s over the modules. After study i ng several
a lternatives. we selected a reve rse i m p e l ler blower
used o n Digi tal's VAX 6000 series m achi nes. Two of
these blowers provide the requ i red airflow, while
gene ra t i ng m u ch less acoustic noise than conven
tional fans.
Since blower fai l ure wou l d resu l t i n a catas
trophic mel td own, a irflow and temperature sen
sors are p rovided . A s m a l l mod u le conta ining a
m icrocontrol ler moni tors these parameters as well
as all power supply volrages. In the event of fai l u re,
the au tonomous con troll e r can shut down the
powe r supplies. This module also generates the
system clock.

Conclusions
Sometimes it is berter to have twenty m i l l ion
instruerions by friday than twe n t y m i l l ion instruc
tions per seco n d .

-Wesley Clark

One h u n d red CPU ami storage modu les and 35 I/ O
modules have been built, packaged as :)'5 A D U sys
tems, ami del ivered to soft ware development
groups throughou t D igital Not just l aboratory
curiosities, these systems have become part of the
mainst ream AXP developmen t environment. They
are in regu lar usc by com p i ler development groups,
operating system developers, a nd a p p l i cations
groups.
The A D l l a l so prov ided a fu l l -speed , in- system
exerciser for the ch i ps. By using the A Dl l, the chip
developers were able to detect several subtle prob
lems in early chip implementati ons.
The ADl l project was quite su ccessfu l ADU sys

A D U package . Our short schedule d e m a nded that

tems were in the hands of developers approx i mately
ten mon ths before the first product pro totypes.

we avoid i n novation and use standard parts wher
ever possi ble.
The ADU's modules and card cage are standard 9U
(280 m i l l imeter by :)67 m i l l i meter) E urocard com
ponen ts, w hich are ava i l able from a n u m ber of ven
d ors. The cabinet is a standard Digital unit, usua l ly

The systems exceeded our i ni t i a l exp ectations for
re liabi l i ty, and p rovi d ed a rugge d , stable platfo r m
for software develo pment and c h i p test. The p roj
ect d e monstrated that a small team, with focused
objectives. Gin produce systems of subst antial com
plexity in a short time.

64

Vol.

Simpl icity was the primary goal in the clesign of the

CJ

1\"o. 4

.\jJ('Cial lssue 1992

D igital Technical journal

The Alpha Demonstration Unit

Acknawledgments

2. C. Thacker, L. Stewart, and E. Satterthwaite, Jr. ,

.John D i l lo n designed the power control su bsystem
and the package . Steve Morris wrote the ADU con
sole software. Andrew Payne contributed to ADU
d iagnostics. Tom Levergood assisted with the physi
cal design of the 110 modules. Herb Yeary, Scott
Kreider, and Steve Lloyd d id mod u le debugging and
testi ng at Hudson and at SRC : . Ted Equ i hand led proj
ect logistics at Hudson, and Dick Parle was respon
sible for ma terial acqu isition and supervision of
outside vendors at SRC.

References
l.

R. Sites, A. Chernoff, M . Kirk, M . Mar ks, and
S. Rob inson , " Binary Translation," Digital
Technicaljournal, val . 4, no. 4 (1 992, this issue):

A

M u l t iprocessor

Transactions on

Wor kstatio n ,"
val . 37,

Computers,

no. 8 (August 1988) : 909-920.

3. R. Katz, S. Eggers, D. Wo od, C. Per k i ns, and
R. Sheldo n , "Implementing a Cache Consistency
Protocol," in Proceedings of the 12th Interna

tional Symposium on Computer Architecture
(IEEE, 1985).
4 . J Archibald and L. Baer, " Cache Coherence Pro

tocols: Eva l uation Using a Multiprocessor Simu
l ation Model ," ACM Tra nsactions on Computer
.s:ystems, val. 4 (November 1986) 275-298.

5 . 1991 GaAs

!C Data

Book and Designe1·'s Guide

(GigaBit Logic, Newbury Park, CA, 1991): 2 - 39.

1 37- 1 '52.

Digital Techt�ical jounwl

" Firefly:
IEEE

Vol. 4 No. 4

Special Issue 1992

65

Todd A Dutton
Daniel Eiref
Hugb R. Kurth
james]. Re-isert

Robin L. Stewart

The Design ofthe DEC 3000 AXP
Systems, Two Highperformance
Workstations
A family of bigh-performance 64-bit R!SC workstations and servers based on tbe
new Digital Alpha A XP architecture is described. Tbe IJardware implementation
uses tbe powerful new DECchip 21064 CPU and employs a sophisticated new system
interconnect structure to acbieve the necessmy bigh bandwidth and low-latency
cache, memory, and l/0 buses. Tbe memory subsystem of tbe bigh-end DEC 3000
AXP Mode/ 500 provides a 512KB secondmy cacbe and up to

1GB of memory The l/0

subsystem of the Model 500 has integral two-dimensional graphics, SCSJ, ISDN, and
six TURBOchannel e::r.pansion slots.

The DEC 3000 AXP system family consists of both

using a large nu mber of h igh-performance 110

workstations and servers that are based on Digi tal 's

devices. I ncreased latency can also res u l t from the

Alpha AXP archi tecture. 1 The family incl udes the

additional levels of buffer i ng and system bus load

desktop (DEC 3000 f\..'{ P Model 400) and desk-side

ing common to t raditional arch itectures. Many

and rack-mou n ted (DEC 3000 AXP Model 500) sys

system buses also exhibit m u ltiplexi ng between

tems. The avai lable operating systems are the DEC

address and data , leading ro fu rther perfo rmance

OSF/ 1 AXP and the Open VMS AXP systems. Al l sys

degradation .

tems use the DECchip 21064 microprocessor.2
Table 1 gives the specifications for the three DEC
3000 AXP systems.

To meet the goals of low memory l atency, high
memory bandwidth, and m i n i m a l CPU-I/O memory
contention in

a cost -competitive m a n n e r,

the

The DEC 3000 AXP systems are designed to be sig

designers i mplemented the DEC 3000 AXP system

nificantly faster than al l p revious D igital work

architectu re in an unusual way. They chose to build

stations and to offer performance competitive with

the system i nterconnect from i n expensive applica

that of other reduced i nstruction set computer

tion-specific integrated circ u i ts (ASICs), as shown

(RJSC) workstations curre n t ly available. I n genera l ,

i n Figure 1. The ASICs act as a crossbar between the

RJSC systems have l a rger code sizes and conse

CPU, memory, and 110 buses. Addresses and data are

quently require more instruction-stream band

switched i n dependently by the crossbar.

than complex i nstruction set computer

The system block diagram in Figu re 2 shows the

(CISC) systems. Further, 64- bit machines require

system architecture of the DEC 3000 AXP systems.

more data-stream bandwidth than 32-bit machines.

The system crossbar i n the center of the d iagram is

To complement the power of the DECchip 21064

composed of six AS!Cs, consisting of the ADDR ASIC,

width

microprocessor,

the systems need

a

bala nced

the TURBOchannel (TC) ASIC, and fou r SLICE AS!Cs.

system architecture, including a hi gh- bandwidth ,

The

low- latency memory system and a n efficient, h igh

the CPU, the memory, and the TC ASIC. The fo ur

ADDR

ASIC

switches

addresses

between

performance l/0 subsystem.

SLICE ASICs switch data between the CPU, the mem

Tradi t i o n a l workstation designs that use a com

ory, a n d the TC ASIC. The TC ASIC switches 1!0

mon system bus exhibit i ncreased memory latency

addresses and data between the A D D R and SLICE

and reduced memory bandwidth due to system bus

ASICs and the TURHOchan nel bus. Connected to the

contention. This is a special concern for designs

TURBOchan nel bus are the various l/0 con trol lers,

66

Vol. 4 No. 4

Special lssul! 1992

Digital Tecbnical journal

The Design of the DEC 3000 AXP Systems, Two High-performance Workstations

Table 1

DEC 3000 AXP Fa m i l y Specifications
Desk-side

Rack-mount

Desktop

Specifications

Model 500

Model 500

Model 400

Height, inches

24.7

Width, inches

1 2 .75

1 7 .5

Depth, inches

29.7

27

20
1 6 .75
295

480

480

Max i m u m DC power

5

1 5 .75

output, watts
Memory
32

32

32

1 024

1 024

51 2

Standard, M B

1 050

1 050

426

Maximum, M B

4200

4200

21 00

2

2

Standard, MB
Max i m u m , MB
I nternal hard d isk

Serial ports

2

ISDN port

1

SCSI ports*

2

2

2

Ethernet portst

2

2

2

TURBOchannel slots

6

6

3

Removable media*

2

2

I ntegral graphics accelerator

Yes

Yes

No

Audio

Yes

Yes

Yes

1

Notes:
•

One internal and one external.

t AUI (thick wire) and 1 0Base-T (twisted pair).
• 5.25-inch half-height slots.

secondary
CPU

M E MORY

control

logic,

TURBOchannel

sional graphics s u bsystem. It has connectors for the

I

110 module, fou r memory mother boards, a l ights
and switches modu le (LSM), three TURBOchannel

SYSTEM
'-CROSSBAR

CACHE

cache,

inte rface and, in t he Model 500, the two - d i men

options, and the power supply. Figure 3 shows the
110

layout of the module.

CPU
Figure

1

Simple Crossbar

The DECchip 21064 microprocessor is the CPU of
the DEC 3000 AXP systems. On the Model 500, the
CPU runs at 150 megahertz (MHz), and on the Model

i ncluding the d u a l sm a l l computer systems inter

400, it runs at 133 M H z . The processor is a super

face (SCSI) contro l ler ASIC, the general l/0 con

scalar, fu l ly pipel ined implementation of the AJ pha

trol ler ASIC, and the two-dimensional graphics

AXP architecture . 2 It conta ins two on-chip 8 - k i lo

accelerator ASIC (not present in DEC 3000 AXP

byte

Model 400 systems). In ad d it i on, six TURBOchannel

instruction cache, the other as a data cache. Both

option slots are available fo r expansion (three slots

the integer and floating-point units are contai ned

in DEC 3000 AXP Model 400 systems).

on-chip.

CPU Module

B-cache Subsystem

The DEC 3000 AXP systems are composed of two

The system employs a second-level cache (B- cache)

prim ary modu les, the CPU module and the 1/0 mod

to

u le.

misses and write throughs in the two relatively

The

CPU module contains the processor,

Digital Technical journal

Vol. 4 No. 4

Special Issue 1992

(KB) direct-mapped caches, one for use as an

help m i n i mize the performance penalty of

67

]

FOUR M E MO R Y MOTHER BOARDS
M E MO R Y
DATA
BUS

�6��
BUS

�- - - -

C P U A D D R E S S , TAG, A N D
CAC H E PROBE BUSES

�

""

�

""

{;'
"'

�
;;;
"
:::
"'
·

._

\o

I

DECCHIP
CPU

I
I
I

CACHE

2 1 064

CPU
DATA B U S

I

:
II

/

1

I
FO U R /
LONG WORDS I
I

RY
E SS

- - - - - - - - /

EIGHT LONGWORDS

J��
I
IL

ll
.

� � � ;., ��� _. DMA
"
ADDRESS
B U FFER ING

ADDR A S I C

.

Ir

��
-1 1
1 1 'II
ER I NG

I

ECC, PARITY
C H E C K AND
G E N E RATE
BUS

jJ

;::-

::.
..,
::.
'C'
:::
"!
::!

::.

TC A S I C

FOUR SLICE ASICS
SYSTEM CROSSBAR
L - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

tl
�
...

:;;!
..,

_.

1/0 DATA

'IS

�

I

I

C P U , 1/0, D M A

Figure 2

System Block Diagram

_ ._ _ _ - - - - - -

:�

1/0 ADDR ESS BUS

��;�

.c:: :::::

- - - - - - - - - - - - - - - - 1

_.:: : : : : : : : : :

-L - - - - - - - - - - ·
,

�
�

II � g;
CD

TCDS A S I C

t--

"T

SF B ASIC
( M O D E L 500
ONLY)

I

1I

I
I

�

' '
,
,
"
'

TC
OPTIONS

SCSI

I

I
I

SCSI

G R A PH I C S

ONE LONGWORD

I LJ

--yl

IOCTL ASIC

I

I
I

ETHE R N ET
sERIAL LINES
TOY CLOCK

ISDN A N D A U D I O

The Design of the DEC 3000 AXP Systems, Two High-pe·Jformance Workstations

MEMORY
CONNECTORS

MEMORY
CONNECTORS

CLOCK
SUBSYSTEM

TC
CONNECTOR 0

1/0 MODULE
CONNECTOR

TC
CONN ECTOR 1

TC
CONNECTOR 2

Figure 3

CPU Module

sma l l 8KB primary caches of the DECchip 21064

The block size of the 8-cache i s 32 bytes, match

processor. The 8-cacl1e is a 512KB, d i rect-mapped,

ing the block size of the prim ary caches. The cache

write-back cache . A d i rect-mapped cache el i m i

block a l locati o n pol icy used is to a l locate on both

nates the logic needed to choose among the mu l ti

read miss and write miss. Hardware keeps the cache

ple sets of a set -associative cache, resu l t ing in a

coherent on direct memory access (DMA) trans

faster cache cycle time. A write-back protocol was

actions; DMA reads probe the cache and DMA writes

selected because i t reduces the amount of write

update the B-cache (and invalidate the primary data

traffic from the 8 -cacl1e to m a i n memory, leaving

cache).

more main memory bandwidth avail able for other
memory transactions.

D igital Teclmical]ountal

The DEC 3000 AXP systems are designed to be
u niprocessor systems, which s i mpl ifies the cache

Vol. 4 No. 4

Special Issue 1992

69

Alpha AXP Architecture and Systems

contro l ler design in a number of ways. For example,

block. The Model 500 has a m a x i m u m cache read

since n o other CPU 's cache can contain a copy of a

bandwidth of 480 megabytes p e r second (MB/s).

cache block , there is no need to i mp lement cache

The cache m ay be written by the CPU with a n i n i tial

coherency constructs such as a shared bit. Further,

tag probe latency of five CPU cycles fol lowed by up

by loading

the B - cache during the power-up

to two write cycles of five CPU cycles each. The

sequence and keeping it coherent during DMA by

Model 500 has a cache w r i te bandwidth of 320 M B/s.

using an a l ways-update protocol. cache blocks i n

When a CPU probe m isses in the B -cache, or

the B - cache are a lways guaranteed t o b e val i d . This

when the CPU accesses the exter n a l lock register,

method e l i m inates stale data problems without

control of the cache is turned over to the external

needing to use a va l id bit.

cache con trol ler. This logic controls fi l l ing the

In addition to the cache memory, the subsystem

cache with the requ i red data from m a i n memory,

consists of the cache controller, the m a i n memory

handing the data to the CPU du ring reads, merging

control ler, and the protocol control logic for mem

CPU write data into the cache o n writes, and main·

ory access arbitrat i o n . A block d iagram of the CPU

raining the con tents of the external cache tag ancl

and B-cache subsystem is shown in F igure 4.

tag control store. In a d d i t i o n , this logic m a i ntains

The B -cache is alternately controlled by the CPU

t he archi tectur a l l y defined lock flag and locked

and the external cache control ler. When control led
by the CPU , the cache m ay be read by the CPU in five

i m p lement software semaphores and other con·

physical address register, wh ich can be used to

CPU cycles. The cache data bus width is 16 bytes;

structs nor m a l ly requ i ring atomic read-modify·

therefo re two reads are necessary to fi l l a cache

write memory transactions.

CPU ADDRESS BUS

I

DMA CACHE I N D E X

I
'\_ V
--r
I
2 1 MU

CACHE DATA/ECC
STORE
DECC H I P
2 1 064
M ICROPROCESSOR

5 1 2KB
1 6K x 32-BYTE BLOCKS

CPU DATA B U S
C P U TAG BUS

CACHE TAG/PARITY
STORE

CACHE TAG CONTROU
PARITY STORE

1 6K X 1 1 -BIT TAGS

1 6K x 2-BIT CONTROL
TAGS

I

SYSTEM
CROSSBAR

C P U TAG CONTROL BUS

CPU/CACHE
CONTROL LOGIC
AND
S E QU E N C E R S

CPU STATU S S I G NALS
CPU CONTROL S I G NALS

~

_j

MEMORY CONTROL
S I G NALS

CROSSBAR STATUS S I GNALS
CROSSBAR CONTROL SIGNALS

CYCLE DECODER

~

MAIN SEQUENCER

Figure 4

70

1/0 CONTROLLER STATUS
SIGNALS
1/0 CONTROLLER
SIGNALS

CONTROL

CPU and B-cache Block Diagram

Vul. 4 No. 4

Special Issue

/'}')2

D igital Teclmicaljournal

The Design of the DEC 3000 AXP Systems, Two H(r;h-perjormcmce Workstations

The control logic for the B -cacl1e consists of two

example, during the " read cacheable memory with

interlocking state machines. These state machines

victim block" flow, the main sequencer reads the

control arbitration and decoding of processor and

victim block from the B-cache and stores it in rhe

110 subsystem requests. They also generate the con

SLICE AS!Cs i n parallel with reading the new block

trol signal s needed to execute these requests to the

from m a i n memory. The same flow without a v ic

CPU . B-cache, anc.l main memory.

tim block makes use of the m a i n memory access
arbitrate

t i me to u p date the tag store. The control flows for

requests from various sources, including the CPU,

writes to cacheable memory a lso take acJvantage of

the 1/0 subsystem, and the memory refresh logic.
Arbitration is uone accorcJ i ng to a fixed priority.

used when the cycle decoder determines that the

First priority goes to DMA requests from the I/0 sub

entire cache block will be wri tten; i n this case the

system. Second priority goes to memory refresh
requests. Lowest in priority are requests made by

therefore it is never fetched from memory.

The state

machines prioritize

ami

t h is paral lelism. A fu rther write optim ization is

data from memory is completely overwritten, and

the CPU. The one exception to this scheme occurs

DMA flows are entered upon request of the DMA

at the conclusion of a DM.A transaction. In this case,

controller in the 1/0 control section. DMA control

the first arbitration cycle fo l lowing the DMA

flows start by asserting a "hold request" to the CPU,

changes the priority to memory refresh first, CPU

causing the CPU to cease B-cache operations within

request second , and DMA last. This guarantees that

a specified time, after which i t asserts a "hold

requests for CPU and memory refreshes are granted

acknowledge" signal. It should be noted that the

dur i ng heavy DMA traffic.

CPU wil l continue to execute i nstructions inter

The larger state mach ine, or main sequencer,

nally until such time as it experiences a miss in one

examines the com mand generated by the smaller

of its i n ternal caches, or i t requires some other

state machine, or cycle decoder, and i nitiates the

external cycle.

control flow necessary to perform that com mand.

Each DMA write to memory results i n a probe of

Fifteen unique flows are i mplemented by the main

the B-cache for the DMA target block, with a hit
resulting in the B-cache block being updated i n par

sequencer. They are
•

Read cacheable memory with/without victim
block

•

Write cacheable memory with/without victim
b lock

•

•

al lel with main memory and the corresponding pri
mary data cache block being inval idated . DMA reads
cause main memory to be read in paral lel with
probes and reads of the B-cache. I f a cache probe

Write noncacheable memory (diagnostic use

h its, the B -cache data is used to fill the DMA read
bu ffer in the SLICE ASICs; otherwise the main mem

only)

ory data is used. In this manner, cache coherence is

Full block write cacheable memory w ith/with
out victim block

•

Tag space write (diagnostic use only)

•

Programmed l/0 reacJ/write

maintained.

Memory System and System Crossbar
The DEC 3000 A.,\:P Model 400 and Model 500 archi
tecture supplants the traditional system bus with a
system crossbar constructed from ASICs. Tight ly

•

Load lock h i t

•

Store conditional h i t

types of ASICs-SLICE, ADDR, and TC- form the

•

Memory refresh

crossbar. SLICE and ADDR are d iscussed next and TC

•

DiVlA read/write

coupled to the crossbar is the system memory. Three

is d iscussed in the I/0 Subsystem Interface section.

When a cache miss occurs and the new cache

SLICE AS/Cs

block replaces a cache block that has been modi

The fou r SLICE AS!Cs are used strictly for cJata path;

fied, as indicated by the " d irty" status bit, the dis

together they form a 32-byte bus to main memoq', a

placed data is referred to as a "victim block" or

16-byte bus to the CPU and cache, and a 4 -byte bus

"victim data."

to the TC ASIC. I t is helpful to think of the SLICE

The many variants of cacheable reads and writes

ASICs as a train station for data with the data buses

provide optimized flows that maxim ize the paral

as train tracks. Data can come and go on any track,

lelism of cache accesses and memory accesses. For

d ifferent tracks have d ifferent speeds and widths,

Digital Techllical journal

Vol.

4

No. 4

Special Issue

1992

71

Alpha AXP Architecture and Systems

and data can find temporary storage in the AS!Cs.

read , victim write, and DMA addresses to send to

The SLICE ASICs provide the systems with a location

memory. A counter that increments DM.A addresses

to bu ffer DMA, I/O read , 1/0 write, and victim data

on long Tl RROchannel DMAs also resides in A D D R .

while the data waits to travel the next leg of its jour

ADDR p rovides a home to the memory configura

ney. The use of the SLICE AS!Cs also e l i minates one

tion registers. At power-on t ime, the boot firmware

to two levels of buffering between the dynamic ran

writes and reacls memory space, determ ines the

dom-access memories (DRAMs) and the CPU, thus

memory configuration, and writes the configura

decreasing latency and improving bandwidth.

tion registers. At run time, each memory address

A key design decision was determ ining the width

maps into a unique bank, regardless of the type ancl

of the memory data bus. A conventional design

order of the single i n - l ine memory modu les (SIM NIS)

wou ld have m atched the width of the memory bus

instal led .

to the width of the cache bus ( 16 bytes). However,

ADDR a lso prov ides a home for m iscellaneous

to reduce the memory latency of the second half of

fu nctions such as tag parity checking, refresh

the cache b lock (cache l i ne size is 32 bytes), the

counter, ami the locked physica l address register. I t

system reads the entire cache block from memory

generates the cache probe index to check the cache

at once using a 32-byte memory bus. This technique

tags for a h i t or a miss on (),VIA probes.

e l i minates the additional latency from a second

Memory Mother Board and SIMMs

page-mode read.
The DEC 3000 AXP Model 500 returns the entire

The memory system is composed of memory

block to the cache and CPU with an average latency

mother boards (.\1NI Ih) that rise from the system

of only 180 nanoseconds (ns) from the CPU memory

card, and SIMMs. Th is arrangement is a good solu

request. In contrast, a less aggressive prelimina ry

tion to the p roblem of l i mited space on the system

design u s i ng a system bus and 16-byte-wide mem

module. I t a l l ows for a wide data bus and for good

ory bus yielded an average memory latency of 320

signa l i ntegr i t y fo r short propagation t imes on the

ns. The 32-byte memory bus costs l i t tle more than a

memory data bus.
As shown in Figure 'J , an :'11:'M3 modul.e supports

16-byre bus-two low-cost ASIC:s, resistor packs,

up to eight SIMMs at a time (four SIMMs in Model 400

and some address fan-out parts.

systems). A m i n i m u m of two S I M Ms is req u i red for

ADDR ASIC

each board . A system a lways contains four ,YJ MUs.

The ADDR ASIC is a crossbar for addresses. A D D R

The M i'vi Rs act as a carrier for the SIMMs and also con

sends addresses from t h e CPU to memory (Cl'U

tain d rivers for address and contro l signals.

reads and writes), from the CPU to 110 (110 reads

A total of H, LG, 24, or :)2 SIMMs (maximum of 16 in

and writes), and from the 1/0 to CPU and memory

Model 400 systems) can be plugged into the system .

(Dl'v!A reacls and wri tes). ADDR selects between C P I J

SIMMs may be single- or double-sided with LO DRAMs

�

CRAM
DRAM

SIMM

jY'

I
I

�

�

1 TO

CRAM
DRAM

I
I

SIMM

8

�

DRAMS I NSTALLED

CRAM
DRAM

I
I

DRAM

I

I

'I
)

I

S L I C E ASIC

Figure 5

Memm)'

CAC H E RAM

CACHE DATA BUS

-

and Cache Data

l�J/.

I
I

SIMM

SIMM

MEMORY MOTHER BOARD

MEMORY DATA BUS

72

CRAM

Nu. ')

.I

.I

CPU

I
I

Bus

.\jJeciu/ lssue

I'J'J.!

Digital TeciJnical journal

The Design of the DEC 3000 AXP Systems, Two High-peiformance Workstations

per side. Each side of a S!MM constitutes one-eighth

DMA reads) or empty (for D MA writes), the CPU is

of a bank. Eight SIMMs must be plugged i n to com

al lowed to use memory. When the 1/0 controller

plete a bank; hence the 320-bit-wide data bus (4 bits

detects that the buffer is too ful l o r too empty, it

per DRAJVI by 10 DRAMS per SIMM by 8 SIMMs). One

requests memory time to service the DMA buffer.

megabit (Mb), 4Mb, and 16Mb DRAMs are sup

At this time, further CPU requests are temporarily

ported , and users are al lowed to popu late banks i n

ignored. This technique prevents the CPU from

any order. I n this way, the DEC 3000 AXP Model 500

being locked out of main memory, even during long

can support from 8MB to 1 gigabyte (GB) of mem

DMA transactions and even though DMA has priority

ory, and the DEC 3000 AXP Model 400 can support

over CPU transactions.
The crossbar also p ermits simu ltaneous write

8MB to 512M B of memory.
Main memory is protected by a single-bit-correct,

transactions from the CPU to main memory and

double-bit -detect error-correcting code (ECC). I n

from the CPU to an I/0 device. SLICE and ADDR ASICs

addition, t h e arrangement o f data b i t s al lows the

can b uffer one I/0 write transaction of up to 32

detection of any number of errors restricted to a

bytes in size. Once the ASICs have accepted the data

single DRA.l'vl chip . ECC corrections for CPU trans

and address, the cache and crossbar are free to pro

actions are performed by the CPU, and corrections

cess other CPU transactions, which can include

for 1/0 transactions are done in the TC ASIC.

cache and m a in memory reads and writes. If the
CPU issues an l/0 write while a previous write
is s t i l l pending in the ASICs, the cache control ler

Memory Transactions
When data is stored in the B-cache by the CPU, it is
not im mediately sent to memory. Data is written to

simply stal ls.

is replaced . Data destined for the cache is read from

1/0 Subsystem Interface/
TURBOchannelASIC

main memory only on cache m isses. Reads to main

The I/O system is based on the TURBOchannel, a 32-

memory, whether from the CPU or from DMA,

bit high-performance, bid irectional, m u l tiplexed

always return 32 bytes. On CPU reads of main

address and data bus developed by Digital for work

memory, data is returned to the cache and CPU i n

stations -" The DEC 3000 AXP supports up to six

main memory only when a dirty block in the cache

two ha lves b y t h e SLICE ASICs. Likewise w h e n the

plug-in options, as wel l as the integral smart frame

B-cache control writes victim data to main mem

b uffer (SFB) graphics ASIC,

ory, two reads are made of the cache, but only one

(IOCTL) ASIC, and the TURBOchannel dual SCSI

write is made to main memory.

(TCDS) ASIC. The TURBOchannel bus is synchronous

On DMA writes, 4 bytes of data arrive from the
TURBOchannel i nterface ASIC each cycle and are

the 1/0 controller

and requires only five control signals in each direc
tion between the system and the option cards.

stored in the SLICE ASICs. The SLICE ASICS can b uffer

The system interfaces to the TURBOchannel bus

up to 128 bytes of data prior to writing the data to

by a data-path TC ASIC and control logic contained

main memory using page-mode writes, 32 bytes a t a

in a nu mber of program m able array logic devices

time. To maintain cache/memory coherence, data is

(PALs). The TC ASIC completes the system crossbar

also provided to the cache RA.i\1s so that i t may be

by passing addresses between the TURBOchannel
bus and the address ASIC, a nd passing data between

written i n the case of a cache hit. On DMA reads, up
to 128 bytes of data are read page mode out of main
memory and butfered i n the SLICE ASICs. Data flows

the

TURBOchannel

bus

and

the

SLICE

ASICs.

Furthermore, the TC ASIC checks and generates par

out to the TC ASIC and the TURBOchannel bus at the

ity on the TURBOchannel, and checks, corrects, and

rate of 4 bytes per cycle (lOOM B/s). In the event of a

generates ECC on the data bus to the SLICE ASICs.

cache h i t , data is taken preferentially from the

Parity checking of TURBOchannel data is optional

cache.

and is enabled on a per-option basis through a con

The crossbar employs a technique that permits

figuration register in the TC ASIC. Final ly, the TC

simu l taneous transactions from CPU to main mem

ASIC contains a number of counters for tracking

ory and DMA. The TURBOchannel bus supports DMA

DiVIA progress, as wel l as configuration and error

transactions of up to 512 bytes in length . Once the

registers. A.!! control logic was implemented in PALs

DMA starts, the system must be able to provide or

to minimize the impact to the project schedule of

receive data without any gaps. However, while the

any design changes. The TURBOchannel interface

DMA buffer i n the SLICE ASICs is sufficiently ful l (for

block d iagram in shown in Figure 6.

Digital Technical journal

Vol. 4 No. 4

Special Issue 1992

73

Alpha AXP Architecture and Systems

ADDR ASIC
lADDRESSI
LOGIC NG

1/0 ADDRESS

! NUMBER
PHYSICAL PAGE

I

�----r-�IISG RAMS
ENTRI ES) I
.--------+-.. I(32K
SLICE ASICS
VIADDRESS
RTUAL
r+-1 1/0 BUFFER I
1/0 DATA BUS
I DMA BUFFER I

rc ��
(]->-��=====T=U=R=B=O�C=HA=NN=E=L====�
y

/L_

�
1-------l

ERRORS

6

-�

COUNTERS 6{jl
CONTROL STATUS
I
REQUEST SFB
DMA
TCDS
I
ACKNOW
DGE
LE
RATI
N
T
O
ARBI
I
CORE
1
/
0
I
I
I
I
I
_
DM:.:.:. A:.::. R:. c.E=c-=Q..:.:U::.ES:.:.:. T :. _jl
::.
\..�
I
_c_oN_T_R_o_L-----1 A A )h--..§S:!T�ATQ;U!.§S�-r-----,�S.§IE�LE�c::r:T_..
I
b.__6 b.___c'> l CON TR OL .1 1/0 CONTRO L I READY
I
I
STATEDECODE
MACHI NLOGI
ES C
TCOPTIONS
AND

__
'---_L__
_L__
__
__

Figure 6

TURBOchannel Interface Block Diagram

There are two types of TURBOchannel opera

request to the system. The DEC 3000 AXP architec

tions: the system initiates l/0 reads and writes, and

ture employs an arbitration scheme using rotating

the options initiate DMA reads and writes. O n an

priority that prevents any option from being l ocked

1/0 operation , the system sends the l/0 address

out. After being granted the bus, the option sup

from the ADDH ASIC to the TC ASIC, and from there

plies a DlVIA address on the TURBOchanneJ bus. This

to the TURBOchannel. For 110 reads, the option

address routes through the TC ASIC and onto the

returns data on the TIJRBOchannel. This data passes

address ASIC. I n the case of a D1\1A. write, data im me

through the TC ASIC and over the bus to the SLICE

d iately fol lows the address on the TURBOchannel .

ASICs. The system includes some special hardware
for byte masking of 110 read data. This hardware is
used to provide support for VMEbus adapters.

This data passes through the TC ASIC and onto the

For 1/0 writes, the system sends data from

because the TURROchanneJ bus does not transmit

the SLICE AS!Cs across the data bus to the TC ASIC.

ahead of time the n umber of bytes of data to be read

clara bus to the SLICE buffers.

DMA reads are more compl icated than writes

The TC ASIC then sends i t to the option over the

from memory. Instead, it continues to assert its

TURBOchannel. The DEC 3000 AXP workstation

read request signal for as long as i t is requesting

supports a block write extension to the original

data. The SLI C E buffers begin t o fil l up with DMA

TURBOchannel protocol. In this mode, the system

data, and o nly when they can guarantee that there

suppl ies a single address fo llowed by multiple

wil l be no gaps in the DMA wil l the data transfer

consecut ive data transfers for improved 1/0 write

start. The TC ASIC receives the read data from the

performance. This extension is also configurabJe

SLICE ASTCs and sends it onto the TURBOchannel to

on a per-option basis through the TC configuration

the requesting option.

register.
The TURBOchannel protocol specifies that before

Virtual DiVIA al lows the system t o map non
contiguous regions of physical address space into

any option can use the bus for DlVIA, it must issue a

contiguous regions of virtual address space. This

74

Vol. 4 No. 4

Special Issue 1')92

D igital Teclmicaljournal

The Design of the DEC 3000 AXP Systems, Two High-performance Workstations

method al lows TURBOchannel options to transfer

i n terface

l arge blocks of DMA data without knowledge of how

Integrated Services D igital Network (ISDN), alter

(AUI)

Ethernet,

lOBase-T

Ethernet,

that data is mapped in the physical address space in

nate console/serial printer, mouse/keyboard, com

main memory. Virtual DMA enhances operating

m u n ications,

system performance because the memory mapping

TURBOchannel options, and audio module port.

is performed before the transfer of DMA data.

internal and external SCSI , three

The various 1!0

control lers

interface

to

the

The DEC 3000 AXP workstation supports virtual

TURBOchannel through one of three ASTCs. These

DMA through the use of a scatter/gather (SG) map,

ASICs are the smart frame buffer (SFB) on the CPU

which acts as a translation buffer. SG m apping is

module and the TURBOchannel dual SCSI (TCDS)

enabled on a per-option basis through the configura

ASIC and the I/0 controller (IOCTL) ASIC on the l/0

tion register in the TC ASIC. The SG map is organized

module.

as 32K 24 -bit entries. Each entry contains a 17-bit
physical page number (PPN), parity, and valid bit.
Software sets up the map through l/0 space reads

VIRTUAL DMA B Y T E A D D R ESS FROM T U R BOCHAN N E L

�v

and writes. DMA byte address bits [27: 13] index the
SG map, which produces a 17-bit PPN (bits [29: 13]) to

BYTE

o

append to the virtual DMA byte address bits [ 12 : 0] .
The resulting 30-bit physical DMA byte address can
then address a l l 1 GB of the possible system address
space. An SG map is shown in Figure 7.

29

BYTE

1/0 Subsystem

0

PHYSICAL DMA BYTE ADDRESS TO M E MORY SYSTEM

Most of the 110 subsystem is implemented on
its own module. This l/0 module, shown in Figure
8, contains the connectors for attachment u n i t

EXTERNAL SCSI

INTERNAL SCSI

TC
C O N N ECTOR

COM M U N ICATIONS

5

CPU MODULE
CONNECTOR

Vol. 4 No. 4

Special lssue

MOUSE/
KEYBOARD

TC
CONNECTOR

Figure 8
D igital Techtzicaljournal

Figure 7

1992

4

REAL-TIME
CLOCK

Scatter/Gather Mapping

ISDN

AUI

FLASH
M E MORY

TPIC
C O N N ECTOR

TC
CONNECTOR

AUDIO

3

I/0 Module

75

Alpha AXP Architec t u re and Systems

I/0 Module-IOCTL ASIC

signal-to-noise ratio ranged from 24 decibels with a

A key 1/0 subsystem design decision was to reduce

m i n i m a l signal i n p u t to 58 deci bels with a h igh

t ime-to-ma rket by e l i m inating u n necessary new

level signal i n p u t .

h a rdware and software development. To support
most of t h e 1/0 functional i t y, the designers chose
the I OCTL ASIC developed for the DECsta tion 5000
Model 240.
The IOCTL ASIC provides an i nterface to a !6-bit,
genera l - p u rpose 1!0 bus, w h i c h supports the fol
low i ng devices: t wo Zi log Z85C30 serial com m u n i
cations contro l lers (SCCs), an A.MD 7t.>90 local a rea
network controller fo r Ethernet

(L\NCE),

a Dal las

semicond uctor DS 1287 real-time clock. an A.'viD
79C30A

ISDN

data controller (I DC), a SCSI con

troller. and a n A..'viD 27C020 2'56KH erasable pro
gra m mable read-only memory (El'R0.\ 1 ) .
The sees i mplement t he keyboard. mouse, al ter
nate console/printer. and communications ports.
The mouse and keyboard do nor use D.'v!A. The a l ter
nate console/printer and the com m u n i cations port
do use D.'vlA.
The LANCE i m plemen t s the E thernet interface,
which connects to the local area network (L

)

t h rough either tbe AUI ( t h ickwire) or IOHas e-T
(twisted-pair interconnect [TPIC ] ) connectors. Soft
ware con trols which o n e of these i n t e rfaces i s
enabled .
The rea l - time clock provides time-ot�year (TOY)
reference and 50 bytes of nonvolatile RANI. A
l ithium battery supplies powe r in the event of
system power-off or fai l u re .
The I DC i mplements both a n ISDN interface a n d
telephone-qual ity audi o. The audio connects t o the
audio imerface mod u l e (AIM), which prov ides the
a u d io 1/0 in the Model 500. A u d i o 1/0 in the M o d e l
4 0 0 is on i t s 1/0 module.
The

AIM

on the Model 500 supports audio i np u t

through eithe r a Ys- inch m i n i jack for m icrophone

I/0 Module-TCDS ASIC
Al tho ugh the IOCTL

ASIC

contains a n i n terface

to a SCSI contro l ler, the DEC 3000 AXP systems
i mplemen t their SCSI i n terface using the

TCDS

ASIC. 'fhis design has several advantages. F i rst, the
TCDS ASIC su pports t wo SCSI ports rather than
the one supported by the lOCfl.
separate internal and external

ASIC,

SCSI

p e r m i t t i ng

chains. Secon d ,

t h is design e l i m i nates contention between the
Ethernet controlle r and the SCSI con trol ler fo r the
!OCTL bus. 'fh i rd , the TCDS

ASIC

supports m uch

longer TlJRBOchannel DM.A bursts (64-byte b u rsts
rather than 16 -byte bursts). Final l y, the resul ting
ASIC design is used to i mplement a d u a l SCSI

TURBOchannel option m o d u l e .
The TC:DS ASIC im plements t w o se parate SCSI
ports using two

NCR

53C94 advanced SCSI con

tro l lers (ASCs). The TCDS al lows both control lers to
have DM.A transfers in progress s i m u ltaneous ly.
TCDS

TlJRBOchannel

DMA

al igned 64-byte blocks. Starting

transactions
DMA

are

add resses that

are not al igned to these bounda r ie s begin \Vith a
smal ler DMA transact i o n . This techn ique a l igns t he
address so that succeed ing transactions are a l igned
64 -byte blocks. Large, a ligned transact i o ns i ncrease
both TlJRBOchannel and memory access efficiency.
The TCDS ASIC and the

ASCs

provide odd parity

protection on major data paths. This protec t i o n
includes 8 - b i t parity on the 1 6 -bit b u s between t h e
TCDS a n d the ASCs, 32 -bit parity on TC DS

DMA

buffer

e ntries, and 32-bit parity on TURBOchannel t rans
actions, both I/0 and DMA .

input, a 4-pin modu lar jack (MJ) connector fo r use

Graphics

of a telephone handset, or an RCA- style phon ograph

The graphics su bsystem on the Model 500 sys

jack used as a l ine-in i n p u t . O u t p u t is provided by

tem card prov ides integral 8-pl.ane graphics with

the MJ con nector as well as by a ��-i n c h stereo

hardware en hancements for improved frame b u f

p h o n ic jack. The stereophon i c jack accepts o n l y a

fer p e rformance. These enhancements increase

stereopbon ic plug. If mo nopho nic headphones are

the perf(>r m a nce of stip ple, l in e d rawi ng, and copy

used, a mono-to-stereophonic adapter is requ i re d .

operations . The graphics system consists of a n

O n t h e Model 400, a u d i o i n p u t a n d outpu t is i m ple

ASIC, 2 M B video RAM, and the Brooktree Bt459

men ted using a 4 -pin ii'!J connector.
Ana lysis of the complete audio system in a Model

SFB

RAM DAC: cbip fo r sourcing the 8-plane RGB data.
The user can select either a 66 -Hz o r a 72-1-Iz moni

500 shows a frequency response of 145 H z to 3, 500

tor refresh rate th rough a switch o n the back of the

Hz, with typical d istortion i n the 0.8 percent to 1 .9

workstation . The graphics su bsystem can d raw

percent range for the m i c rophone and 0.4 percen t

61 5K two-dimensional vectors p e r second and can

to 1 . 5 percent for t h e telephone handset. The

perform copy operations at 3 1 BM B/s.

76

I (J!. ··I No. ..f

SjJccial lssl/e 1')92

Digital Technical journal

The Design of the DEC 3000 AXP Systems, Two High-performance Workstations

The graphics subsystem is available separately as

margin. The PECL clocks are converted to transistor

the TIJRBOchannel HX graphics op tion card . In addi

transistor logic (TTL) in the last stage of the clock

tion, high-performance two-dimensional and three

fan-out tree.
Two stages of system clock fan-out are used as

d i mensional grap hics accelerators are available

shown in Figure 9. Two MC lOOE l l l ECL cl ock bu ffe r

through the TIJRBOchannel bus for all systems.

chips (PECL input and output) provide 18 low

Clock System

skew d i fferential copies of the clock. Seventeen

The input clock circuitry to the DECchip 21064 CPU

MC100H641 ECL-to-TTL converters (PECL input, TTL

contains a differential 300-MH z oscillator (266 MHz

outpu t) are d istributed throughout the system and

for the Model 400), which drives an alternating cur

1/0 boards to provide more than 100 clock l i nes. All

rent (AC) decoupl ing circ u i t and t h e CPU chip. The

clock l ines are length matched to reduce skew, and

CPU chip d ivides down the input clock frequency

PECL wires are separated from TTL Wo rst-case

by a factor of two and operates i n ternally at 150

SPlCE simulation in dicates a skew between typ ical

MHZ. The DEC 3000 A.XP Model 500 is capable of sup

components such as PAls to be 1 .5 ns. Actual skews

porting a 200-MHz CPU with a 400-MHz oscil lator.

mea5urecl in the lab are approximately 0.5 ns.

The ent ire system, with the excep tion of some

To give designers maximum flex ibili ty, four

flO devices, runs synchronously. The master system

phases of the system clock are generated, one every

clock is generated by the CPU chip at a frequency of

10 ns. Delay lines are used to generate an offset of 10

25 MHz (22 MHz for the Model 400), resul ting in

ns. By swapping the h igh and low differential inputs

system clock cycles of 40-ns duratio n . This master

to selected MC 100H641 converters, the 20- and 30-

system clock is duplicated and distribu ted with

ns delayed clocks are generated. The master system

differential pseudo-em i t ter coupled logic (PECI.)

clock is delayed using delay lines so that the even

to maintain minimum skew and to improve noise

tual system clock is synchronous with the CPU chip.

3.3-V

CRYSTAL

ID

.-----. CMOS
CPU
LEVELS
25 M H Z

SYSCLK

TTL
DELAY

LEVELS

LINES

300 MHZ

PECL

LEVELS

1 0 -NS

DELAY
LINES

Figure 9

D igital Technical ]OUt"11al

Vol. 4 No. 4

Clock Distribution

Special Issue 1992

77

Alpha A.XP Architecture and Systems

Technology

i m plemented. TPD is defined as the total d iameter

The goal i n choosing semiconductor devices was to

of permissible movement from a theoretical exact

select mature sil icon technologies and then push

locati o n around the true position of the pads. This

those technologies to the l im i t . Module- and chip

TPD requirement ensures proper positio nal accu

level signal i n tegr ity was verified by correlating

racy between the solder paste stencil apertures and

silicon bench characterization data to device simu

the surface-mou nt features. In add ition, solder

lation modu les. CAD tools were used to perform

mask between pads on t h e fine-pitch components

worst-case module timing and signal i ntegrity sim

is used to reduce manufacturing defects.
To reduce power and cost, the slower DEC 3000

ulation. This methodology minimized device costs,
reduced risks, and shortened time-to-market.
The nine AS!Cs i n a DEC 3000 AXP workstation
use six u nique 1 .0-m icrometer complementary

AXP Model 400 design substitutes CMOS technology
for the BiCMOS cache SRAMs and for many of the
bipolar PALs.

metal-oxide semiconductor (CMOS) designs. (See
Ta ble 2.) Plastic quad flat packs (PQFP) are used as
the packaging technology to l im i t device cost.
Because the ASICs are 110 l i m i ted and the PQFPs do
not have ground planes, the effects of simultaneous
switching outputs (SSOs) were a concern. The
potential effects of ssos in CMOS output buffers
i ncl ude corrupted

data and

undesirable oscil

Pawer and Packaging
The fol lowing fixed disk drive options are currently
available.
•

RZ25 3.5-inch half-height 426MB disk drive

•

RZ26 3.5 -inch half-height 1050MB disk drive

lations. Sim ulation and bench characterization
were used to quant ify the SSO effects, and i n some
cases SSOs were reduced by staggering output
driver timing.
Although AS!Cs were chosen for the data path,
PALs were used for control logic due to their greater
flexibility and faster turnaround time. A total of 63

The following removable media options are a lso
available.
•

RRD42 5.25 -inch h a l f-height 600MB CD-ROM drive

•

RX26 3.5-inch half-height 2.8MB floppy disk drive

•

TZKlO 5.25 -inch half-height 525MB QIC tape
drive

20X:X (5 ns) and 22Vl0 (10 ns) PALs with 57 different
codes was used. Exhaustive system-level simu la
tion and bench characterizations were pe rformed
to u nderstand device behavior in the many d iffer

•

TLZ06 5.25-inch half-height 4000MB OAT drive
The Model 500 has a 480-watt output, off-line,

swi tching regulated power supply, w hich includes

ent load ing scenarios.
The CPU board technology proved moderately

a capacitor-inpu t, automatic voltage-selecting cir

difficult for system-level assembly due to the l arge

cuit to permit worldwide operation withou t a vol t

distance between the fine-pitch (25 mil) compo

age-select jumper for 120 or 240 volt (V) input. The

nents. There are 19 fine-pitch components on the

power supply provides five ou tputs to the load :

14- by 16 -inch CPU board, with a maximum distance

+3.3 V, +5.1 V-CPU, +5.1 V- turbo, + 12.1 V, and - 12.1 V

of 14 inches between any two devices. With t h is

The power supply also provides power fo r three

large distance, an aggressive, true positional diam

external fans. Temperature-sensing fan speed con

eter (TPD) tolerance requirement of 6 mils was

trol is provided to reduce system noise. The power

Ta ble 2

AS ICs Used on t h e DEC

3000 AXP Workstations

Total Number

Number of

Number of

Used

Ava i lable

of Pins

Pins Used

Signal Pins

Gates

Gates

1 84

1 84

1 50

21 .6K

54K

TC

1 84

1 82

1 44

1 2.1 K

44K

SLICE

1 84

1 84

1 53

1 1 . 2K

44K

ADDR

1 84

1 83

1 48

5.7K

44K

TCDS

1 20

1 20

94

26.5K

68K

IOCTL

1 60

1 60

1 26

1 1 .2K

44K

Chip

SFB

78

Vol.

4 No. 4

Special issue 1992

Digital Technical jounral

The Design of the DEC 3000 AXP Systems, Two High-pe1fonnance Workstations

supply senses tachometer outputs from the fans,

loaded into the i nstruction cache. These programs

and when a fan fa ils, it shuts down and i l l u minates

include power-up code for loading the real console,

an indicator.

a m i n iconsole, and five d i agnostic programs fo r
testing memory and the graphics subsystem . Other

Manufacturability/Testability
The designers prov ided several debugging features,
including test points on the module, tristate out
puts on ASICs and PA Ls, an on-board diagnostic
ROM, and program m able console ROM . Since the
mod u le is composed almost exclusively of surface
mou nt devices, the designers specified as many vias
as possible for use as test points. Consequently, all
wires on the board have test points, which allows
for 100 percent short -circ u it coverage and 94 per
cent open-circuit coverage.
The DEC 3000 AXP worksta t ion takes ful l advan
tage of the serial ROM port on the DECchip 21064

tests are available by replacing the EPROM. These
programs are of great value i n the m a n u facturing
debug environment.
Two flash EPROMs contain the console code fo r
the system . On power-up, code in the serial ROM
loads the console code into memory and begins
executing i t . Users can easily update the console
ROMs (for example, to provide PAL code en hance
ments) through a special util ity booted off a CD
ROM connected to the syste m . Field service can
update the console code in the system remotely
through the Ethernet.

CPU. This port al lows code to be direc t ly loaded

Conclusions

into the instruction cache. Du ring prototype devel

The primary goal of this project was to design a bal

opment, designers loaded special debug programs

anced system that exh ibited low memory latency,

into the CPU through this port. However, the real

high memory bandwidt h , and m in i m a l CPU-I/O

innovation is in a l so wiring this port to the output

mem ory contention in a cost- effective manner.

of a 64K by 8 EPROM on the module to provide 8

Table 3 gives the measured peformance numbers

programs that are i n d ividually selectable by moving

for these characteristics. Except where noted, a l l

a jumper on the mod u l e . On system reset, serial

numbers are for sustained performance. Of particu

program data from the selected EPROM outp u t is

l ar note are the numbers showing that the CPU

Ta ble

3

System Performance
DEC 3000 AXP
Model 500

DEC 3000 AXP
Model 400

CPU speed
B-cache size
B-cache read bandwidth
B-cache write bandwidth

1 50 MHz
51 2KB
480M B/s
320M B/s

1 33 MHz
51 2KB
426M B/s
284M B/s

Maximum main memory
CPU memory latency (average)
CPU memory read bandwith
CPU read with victim write
memory bandwidth

1 GB
32 bytes/1 80 ns
1 1 4MB/s
1 60MB/s

51 2MB
32 bytes/203 ns
1 01 M B/s
1 41 M B/s

TURBOchannel peak bandwidth
1/0 read bandwidth 8 bytes
1/0 write bandwidth 8 bytes
Block 1/0 write bandwidth 32 bytes
Block 1/0 write bandwidth 32 bytes with CPU
read and victim write memory bandwidth

1 00 M B/s
1 3MB/s
33M B/s
67MB/s
I/0=53M B/s
M EM=1 07MB/s

89M B/s
1 2MB/s
29M B/s
59M B/s
1/0=47M B/s
M EM=95M B/s

DMA read bandwidth 51 2 bytes
64 bytes
DMA write bandwidth 51 2 bytes
64 bytes
64-byte DMA write bandwith with
CPU reads from memory

91 M B/s
57M B/s
93MB/s
59M B/s
DMA=59M B/s
CPU=30M B/s

81 MB/s
51 MB/s
82MB/s
52M B/s
DMA=52M B/s
CPU=27MB/s

Digital Teclmicaljournal

Vol. 4 No. 4

.Sjwcial lssue 1992

79

Alpha AXP Arc hitecture and Systems

receives significant mem o ry bandwidth even i n the

those who cont ribu ted to the design of original

presence of heavy block l/0 and DMA traffic.

hardware: D ave Archer, Mark Baxter, Joh n D e Rosa,

Another goal of the p roject was to offer per

Chris Gi anos,

Leon

Hesch, Dave Laurel lo, Bob

fo rmance that is competitive with RISC worksta

McNamara,

tions avai l a ble from other ve ndors. The be nchmark

Senerc h i a , Petr Sp acek, Bob Stewart, Ned Utzig,

Dick

Mil ler,

Rick

Rudman ,

Dave

perfo rm ance of any system derives from the i nter

Debbie Vogt, and John Zuraws k i . The tight sched u le

dependent perform ance of the hardware, the oper

cou l d not have been met without the special efforts

ating system , and the compilers that generate the

of the Power and Packaging, Console, Qualifi

application code. The bench mark performance

ca t i o n , Proto Management, a nd Technology and

4

Operating Systems Groups. The design team for the

AXP sys

DEC 3000 AXP Model 400 project is also recognized:

tems o n a selected set of benchma rks as of the

John Day, Jamie Pierce, Dennis Rainvil le, a n d Ken

annou nce ment elates of these produ cts. Table 5

Wa rcl. The thorough device eva l.uations by Rob

compares the perfo rmance of the DEC 3000

A..,'CP

Zahora contribu ted significantly to the success of

Model 500 to the p u b l i shed performance of several

the projects. We would also l i ke ro acknowledge

should improve as each element matures. Table
shows the p e rfo rmance of the DEC 3000

currently available competitive systems 4

the contributions by FXO personnel. The Electronic
Sto rage Development G roup was responsible fo r

Acknowledgments

the design of the DEC 3000 AXP Model 500 memory

The DEC 3000 AXP Model 500 design was a team

m o d u le. Sign ificant efforts by the Maynard TrvL E,

effo rt - m o re peop.le were involved than can be

AJbuquerque, and Ayr Manufacturing Plants should

acknowledged in this space. Recogni t i o n is due to

be recognized

Table

4

for del ivering q u a l i t y hardware

Ben c h ma r k Performance
DEC 3000 AXP

DEC 3000 AXP
Modei SOO

Model 400
Clock (M Hz)

1 33

1 50

SPECmark89

1 08.1

1 21 .5

Dhrystones
V1 .1 (Dh rystones per second)
V2.1 (Dhrystones per second)

228.3K
249.6K

257.7K
281 .2K

26.4
70.8

30.2
79.9

564.0K
27.4M

636.0K
31 .0M

U N PACK 64- bit double precision
1 00 X 1 00 (MFLOPS)*
1 000 X 1 000 (M FLOPS)
X1 1 PERF
Two-dimensional vectors per second
Two-dime nsional pixels per second
Note: " M i llion floating-point operations per second

Table 5

Competitive Comparison
DEC 3000
Model SOO

86.6

257.7K
281 .2K

n/a
n/a

1 33.7K
1 22.3K

26.4
79.9

38.1
84.0

23.7
n/a

1 21 .5

Dhrystones
V1 .1 (Dhrystones per second)
V2.1 (Dh rystones per second)

80

H P9000
Model 750

1 26.2

SPECmark89

U N PACK 64-bit double precision
1 00 X 1 00 (M FLOPS)
1 000 X 1 000 (MFLOPS)

IBM RS6000
Model 580

Vol. 4 No. 4

Special Issue 1992

Dtgttal Technical journal

The Design of the DEC 3000 AXP S)•stems, Two High-petformance Workstations

du ring the deve lopment and production phases; a

1992) : 1555 -1567 and Digital Technicaljournal,

special thanks to J i m Ersfeld fo r his significant

vol.

4, no. 4 (1992, this issue): 35-50.

efforts i n this rega rd .

3. T t : RB O ch a nneJ Specifications, Version 2C (Palo

References

Al tO,

S i tes, ed . , Alpha A rchitectut'e Reference
Ma nual (Burl i ngtOn, MA: Digital Press, Order

1 . R.

No. EY-L520E-DP, 1992)

issue CMOS Microprocessor," IEEE

journal of

Solid-State Ci rcu its vol . 2 7, no. 1 1 (November
,

Vol. 4 No. 4

D igital

Equ ipment

Corpora t i o n ,

September 1991 )

4. Alpha AXP Workstation Family Performance

2. D. Dobberp uhl er a l . , "A 200-MHz 64-bit Dual

Digital Teclmicaljounutl

CA:

·nu;ADD Progra m , Order N o . EK-TCDEV-DK-004,

Spi'cial Issue 1992

Brief-O penVMS,
D igital

Second

Equ ipment

Edition

Cor poration,

(Maynard :
Order

No.

ER-N0102-51 , November 20, 1992).

81

Barry A. Maskas
Stephen F. Shin·on
Nicholas A. Warchol

Design and Performance ofthe
DEC 4000 AXP Departmental
Server Computing Systems
DEC 4000 A)(P systems demonstrate the highest performance and functionality
for Digital 's 4000 series of departmental server systems. DEC 4000 AXP systems
are based on Digital's Alpha AXP architecture and the IEEE's Futurebus+ profile B
standm·d. They provide symmetric multiprocessing performancefor Open V;I!JS AXP
and DEC OSF/1 AXP operating systems in em office environment. The DEC 4000
AXP systems were designed to optimize tbe cost-performance ratio and to include
upgradability and expandability Tbe systems combine the DECchip 21064 micro
processor; submicron CMOS sea-ofgates technolOg)J, CMOS memor:y and I/0 periph
erals technolog)J, a high-performance multiprocessing backplane interconnect, and
modular system design to supply the most advancedfunctionalityfor performance
driven applications.

The goal of the departmental server project was to

SJ'Stem Overview

establish Digital's 4000 family as the industry's most

The DEC 4000 AXP system provides supercomputer

cost -effective and

class performance at office system cost. 2 This com

highest -performance depart

mental server computing systems. To achieve this

bi nation was achieved through arch itecture and

goa l , two design objectives were proposed for the

technology

DEC 4000 AXP se rver. First, migration was necessary

uniprocessor performance, low additional cost

from the VA}( arch itecture, which is based on a com

symmetric m u lt iprocessing (SMP), and balanced

selections

that

provide

opti mized

plex instruction set computer (CISC), to the AJpha

I/0 throughp u t . High 1!0 throughput was accom

AXP architecture, which is based on a reduced

plished through a com b ination of integrated con

instruction set computer (RJSC). Second, for expan

trol lers and a bridge to Futurebus+ expansion 1/0.

sion 110 in an upgradable office environment enclo

The system uses a modular, expandable, and

sure, migration was necessary from the Q-bus

portable enclosure, as shown in Figure 1. With

to the Futurebus+ l/0 bus. ' In addition, the new

current technologies, the system supports up to

system had to provide balance between processor

2 giga bytes (GB) of dynamic random -access mem

performa nce and 110 performance. Main taining

ory (DRAM), 24GB of fixed mass storage, and 16GB

customer investments in VAX and MIPS applications

of removable mass storage. The DEC 4000 A}\P

through support of OpenVMS AXP and DEC OSF/ 1

system is partitioned i nto the fo l lowing m odular

AXP operating systems was impl icit in the archi·

subsystems:

tecture m igration objective. Migration, porting,
and upgrade paths of various appl ications were
defined.
This paper focuses on the design of the DEC 4000
AXP hardware and firmware. It begins with

a

d iscus

sion of the system architecture and the selection of
the system techno logy. The paper then details the
CPU, l/0, memory and power subsystems. It con
cludes with a performance summary.

82

•

Enclosure (BA640 box)

•

CPU module (DECchip 21064 processor)

•

1/0 module

•

Memory modu les

•

Mass storage compartments and storage device
assembly (brick)

Vol. 4

No. 4

Special issue 1992

D igital Tech11ical ]ozw11af

Design and Performance of the DEC 4000 AXP Departmental Seruer Computing Systems

increased

p rocessi ng

power

provided

by

the

D E C chip 21064 CPU. Although processing power
was t a k i ng a revol. u t i onary j u m p in perfo rma nce
with no cost i ncrease, d isk and main memory tech
nology were sti l l on a n evo l u t io nary cost and per
formance cur ve . The metrics that had been used
for VAX systems were difficu l t, if not impo ssible, to

�

meet through l i near sc a l i ng within a fixed cost
bracket. These metrics were based on VAX-1 1/780
u n i ts of perfo rmance (Vl / Ps); they give m a i n mem

---�

ory capac i t y in megabytes (MB)/VUP , disk-queued

110 (QIO) completions in Q[O/s(VU P, and disk data
rate in M B/sf\'1.1 1'. As an exam p l e , Table 1 gives
the metrics fo r a VAX 4000 Model 300 scaled l in 
early to 1 2 5 VU I's and then nonl inearly scaled
fo r the DEC 4000 �'\ P system i m plementat i o n .
Performance mode l i ng o f the DECchip 2 1064

CPU

suggested that 125 Yl. l l's was a reasonable go a l fo r

1 ------:

the DEC 4000 AXP.
Without an Alpha AXP arc h i tectu re customer
base, we did not know if these metrics would scale
l i nearly with

the processor perfo rmance.

The

DEC ch i p 2 1 064 processor technology has the poten
tiaL fo r attract ing new classes of c o m p u te- i n tensive
a p p l i cations that may make these metrics obsolete.

Figure 1
•

Futurebus+

DEC 4000 AXP System Enclosure
Expansion

1/0,

F u t u rebus+

con

troller module (FBE)
•

We therefore chose a non I in ear ex trapolation of the
metrics for o u r i n i tial i m p lementat i o n . By trading
o ff disk and memory capacity fo r l/0 t h rough p u t
p e rformance, w e k e p t within establ ished c o s t a n d
p e rformance goals. T h e i mplementation metrics

Power supply modu les - un iversal l i ne fro n t - encl

were not l i m ited by the architecture: further scal

unit (FEU)

i n g u p of metrics was plan ned . Of the fou r metrics,

-

Power system con trol ler (PSC)

the d isk capac i t y metric has the most growth

-

DC-DC converter u n i t 5.0 volt (V) (DC5)

potential.

-

DC-DC converter u n it 2.1 V, 3 3 \\ 12.0 V (DC3)

•

Coo l i ng subsystem

•

Centerplane module

•

Operator contro l panel (OCP)

•

Dig ital sto rage systems i n terface (DSSl) and sm a l l

To ensure c o m pl iance with both the Alpha �'\ !'

architecture and the Futurebus+ spec ifications, the
system was partit ioned as shown i n Figure 2 . The
bri dge

between

the

CPU subsystem a nd the

F u t u rebus+ subsystem afforded maxi m u m design
flex i b i l i t y to accom modate spec ification changes,

computer systems i nter face (SCSI) term i nation
voltage converter (VTERM)
Figure 2 shows these subsystems in a fu nctional
d iagram. The su bsystems are in terco n nected by a
serial control bus, wh ich is based on Signetic 's FC

modu lari ty, ancl u pgradabi l i ty. The 1/0 module was
organized to balance the req u i rements between

CPU pe rforma nce and l/0 t h rough p u t rates. The
DEC 4000 AXI' system implemen tation is based o n
open standards, w i t h a six-slot Fu turebus+ serving
as the expansion I/O bus a nd the system bus serv i ng
to i n terconnect memory, crus, ancl the 110 m o d u le .

bus .-I

T h e modu l a rity o f the system enables mod u le swap

System Architecture

such that p e rformance and fu nctional ity may be

upgrades and configurabi l i ty of the l/0 subsystem

From the begi n n i n g of the project, i t was appare nt

tailored to user req u i rements. The modu larity

that the 1/0 subsystem had to be equal to the

aspects of the system design extend into the sto rage

Digital Techuical]ournal

Vul. 4 Nu. 4

Special Issue 1992

8:)

Alpha AXP Architecture and Systems

CONNECTI O N
MODULE
I

II

ASYNCHRONOUS SERIAL LINE
(AUXILIARY WITH MODEM CONTROL) I MODEM I
ASYNCHRONOUS SERI A L LINE
(CONSOLE LI N E)
CONSOLE
TERMINAL

OPERATOR
CONTROL
PANEL

CPU SUBSYSTEM

I
I

I

I

I
II

I
I

I
I
I
I

I
I

I
FUTUREBUS+
_I
I -��� E��s��
I MASSSTORAGE COMPARTMENT - I
I
DSSI/SCSI 0
lft..l-1

SERIA L CONTROL BUS

_

_

_

_

_

_
---"

MEMORY
MODULE 0

1/0
MODULE

DSSI/SCSI 1
DSSI/SCSI 2

I

SYSTEM BUS
128-BIT AND LONGWORD PARITY

II

DSSI/SCSI

TO STORAGE
EXPANSION
DEVICES

3

I
I

I
I
I

I
II
I
I
L

_

_

_

_

_

CABLE

j

I

POWER S UB SYSTEM

D DDD
rigure 2

: CO@)S@EM

l___
I

- - - - - - - _I

KEY:
0' EXTERNAL PORT CONNECTI O N

84

I
1<:

ETHERNET PORT
ETHERNET PORT

1

0

_
_
_ _ _ _ _ _ _ '--'
_
r - - - - - - - l
r - - - - - - - l

_

01

D>--AC_P_O_W_E_R_

=
)(]
=
::: ===:::::===
<::=::::=:::

)(]

TO ETHERNET

(§) (§) I
I - - - - - - - _j
I

DEC 4000 AXP System

Fu nctional Partition

Vol. 4 No. 4

:,pecial Issue 1992

D igital Technical journal

Design and Performance of the DEC 4000 AXP Depa1·tmental Server Computing Systems

Ta ble 1

Extrapo lated VAX Metrics
VAX 4000

Model 300
Metrics
60

Memory capacity

M B/VUP

1 .65 GB/VUP

Disk capacity

49

Disk QIO rate

1 .4

1/0 data transfer rate

Scaled
Linearly
to 1 25 VUPs
7.5 GB
206

GB

Scaled
N o n l i n early
for DEC 4000 AXP
2 GB
1 00 GB

QIO/s/VUP

6,1 25

QIO/s

>4,000 QIO/s

M B/s/VUP

1 75

M B/s

21 0 MB/s

compartment where each brick has a dedicated

4. Provide scalable memory bandwidth, based on

controller and power converter. Support for DSSI,

protocol t i m i ng of 25 nanoseconds (ns) per

SCSI, and h igh-speed lOMB/s SCSI provides m axi

cycle, which scales with improvements in DRAM

mum flexibility in the storage compartment. The

and static memory (SRAJ\11) access times.

modu lar m ass storage compartments enable user
optimization for bu l k storage, fast access, or both .
The cost of SMP was a key issue ini tiall y, s i nce
Digital's SMP systems were considered high-end sys
tems. Pull ing h igh-end fu nctionality i nto lower
cost systems through arch i tecture and technology
selection was managed by eval uation of perfor
mance and cost through trial designs and software
breadboard ing. Several designs of a CPU module
were proposed, i ncluding various organizations of
one or two DECchip 21064 CPUs per m o d u l e inter
faced to 1/0 and memory subsystems. Optimization
of complexity, parts cost, perform ance, and power
density resulted in a CPU module with one proces
sor that could operate in either of two CPU slots on
the centerplane. Consequently, a system bus had to
be developed that could be interfaced by proces
sors, memory, ancl 110 subsystems in support of the
shared-memory architecture.
As development of the DECchip 21064 processor
progressed, hardware engineers and chip designers
establ ished a prioritized J ist of design goals for the
system bus as fol lows:
1. Provide a low- l atency response to the CPU's
second- level cache-miss transactions and 110
module

read

transactions

without

pending

transactions.
2. Provide a low-cost shared-memory bus, based
on the cache coherence protocol, t ha t wou ld
facilitate upgrades to faster CPU modu les. This
provision impl ied a simple protocol, synchro
nous timing , and the use of transistor-transistor
logic CfTL) levels rather than special e lectrical
interfaces.

5. Use modu le and connector technology consis
tent with Futurebus+ sp ecifications.
The cache coherence protocol of the system bus
is designed to support the Alpha A.,'\P architecture
and provide each CPU and the 1/0 bus with a consis
tent view of shared memory. To satisfy the band
width and latency requirements of the processor's
instruction issue rate, the processor's second-level
cache size, 128-bit access widt h , and 32-byte block
size were optimized to avoid bandwidth l imits to
performance. The block size and access widt h were
made consistent with the system bus, wh ich satis
fied the 110 throughp u t metrics. Consideration was
given to support of a 64-byte block on the 128-bit
wide bus. Such support would have resul ted i n a 17
p ercent larger miss penalty and higher average
memory access t i me for the CPU and 1/0, more stor
age and control complexity, and hence h igher cost.
Simpl icity of the bus protocol was achieved by
l im iting the number and variations of transactions
to four types-read, write, exchange, and null. The
exchange transacti on enables the second-level
cache of the CPU to exchange data, that is, to per
for m a victim write to memory a t the same time as
the replacement read transaction. T h is avoided the
coherence complexity associated with a l i ngering
victim block after the replacement read transaction
completed.
To address the issue of bandwidth requirements
over ti me as faster processors become available, an
estimate of 40 percent bus util ization for each pro
cessor with a 1 M B second- level cache was obtained
from trace-based perform a nce models. The u t i l i za
tion was shown to be reduced by using a 4MB sec

3. P rov ide 110 bandwidt h enabl i ng local 1!0 to

ond-level cache or by using larger caches on the

operate at 25 megabytes per second (M B/s) and

DECchip 2 1064 chip. This approach was reserved as

the Futurebus+ to operate at lOOM B/s.

a means to support future CPU upgrades.

Digital Teclmicaljournal

Vol. 4 No. 4

Special Issue 1992

85

Alpha A.XP Architecture and Systems

Figure 3 is a block diagram of the length- l i mited

storage devices had to be protected. The DECcbip

seven-slot synchronous system bus. To achieve

21064 CPU's data bus and second-level cache are

tight modu le-to-module clock skew control for this

longword error detection and correction (EDC) pro

single-phase clock scheme, clocks are radial l y dis

tected. The system bus is longword parity pro

tribu ted from the CPU 1 module to the seven slots.

tected. The memory subsystem has 2 80-bit-wide

This avoided the added cost of a separate module

EDC-protected memory arrays. The Futurebus+ is

ded icated for rad ial clock d istribution, and enabled

l ongword parity protected.

the bus arbitration circu itry to be integrated onto
the CPU 1 mod u l e .

System Bus Clocking

mod ule for the system bus is central ized on the CPU

To establ ish the 25 -ns bus cycle time, analog models

Arbitration o f t h e two CPU modu les a n d t h e I/O

1 module. To satisfy the I/O module 's latency
requirements, the arbi tration priority al.lows the

l/0 m o d u le to i nterleave with each CPU module. In
the absence of other requests, a module may uti lize
the system bus continuously. Shared-memory state
eva l uations from the bus addresses during continu
ous bus utilization causes CPU " starvat ion" from
the second-level cache. To avoid CPU starvation
from the second-level cache, the arbitration coo
trol ler creates one free cycle after three consecu
tive bus transactions.

of the interconnect were developed and a nalyzed
for 5.0-V CMOS transceivers. Assuming an edge- to
edge data transfer scheme, the modelers evaluated
the timing from a driver transition to its settled sig
nal, including clock i nput to driver delay, receiver
setup time, and module-to-module clock skew. The
cycle time and the data transfer width were com
bined to deter m i ne compliance with l ow latency
and bandwidth. Further analysis revealed that the
second-level cache access timing was critical for
performing shared-memory state lookups from the
bus. One solu tion to this problem was to store
duplicate tag values of the second- level cache. This

Technology Selection

was evaluated and found to be too expensive to

The primary force behind technology selection was

implement. However, the study d id show that a

to realize the ful l performance potential of the

duplicate tag store of the CPU 's primary data cache

DECchip 21064 microprocessor with a balanced I/O

had a performance advantage and was affordable if

subsystem, weighted by cost minimization, sched
ule goals, and operation in an office environment.

implemented in the CPU module's bus interface unit

(BIU) chips.

SPICE analysis was used to evaluate various module

To evaluate second-level cache access t iming,

and semiconductor technologies. A technology

a survey of SRAM access times, density, availabil

demonstration module was designed and fabri

ity, and cost was taken. Results showed that a

cated to correlate the SPICE models and to validate

cache using 12-ns access time SRAMs was optimal.

possible technology. Based on demonstrations, the

With a 12-ns access time SRAI\1 , the critical timing

I MB

project proceeded with analytical data supported

could be managed through the design of the

by empirical data.

chips. The SRA!vl survey also showed that a 4 M B

The 25-watt DECchip 21064 CPU was designed in

BIU

second- level cache could be planned a s a fol low-on

a 3 . 3 -\� 0.75 -micrometer complementary metal

boost to performance, as SRAM prices decl ined .

oxide semiconductor (CMOS) technology and was
packaged i n a 431-pin pin grid array (PGA). The CPU

Trace-based performance simu lations proved that

was the only given technology i n the system. The

VUPs. This clock rate requ ired a bus stall mecha

power supply, air coo l i ng , and logical and electrical

these cache sizes satisfied performance goals of 125
nism to accom modate current DRAI\1 access times

CPU chip interfacing aspects of the CPU module and

in the memory subsystem, which will enable future

system bus designs evolved from the DECchip 21064

enhancements as access times are red uced .

specifications. System design attention focused on

The system bus clocks are d istribu ted as posit ive

powering and cool ing the CPU chip. Compliance

emitter-coupled level (PECL) d ifferential signals;

with power and cool ing specifications was deter

four single-phase clocks are available to each slot.

m ined to be achievable through conventional volt

Each module receives, terminates, and capacit ively

age regu lation and decoupli ng technology and

couples the clock signals i n to noninverting and

conventional fan technology.

inverting PECL-to-CMOS level converters to provide
rel iability

fou r edges per 25-ns clock cycle. System bus hand

requirements, all data transfer interconnects and

shake and data transfers occur from clock edge to

86

Vol. 4 No. 4

To

address

system

i n tegrity

and

Special Issue 1992

Digital Tecbnical Journal

1/0

1'.1

MODULE

I

"

�f
l
·
� I I
I

�

"'"'

50'"""'

TRANSCEIVER

I � ---1

1- I
l ���g�E 1- I
ETHERNET

I

32

f.l

-�

�

I

I
B UF F ER

M A I LBOX

II
II
BIU

CPU 1 M O D U L E

CPU 2 MODULE

�� ��
8

T SRAM

''c

"

���

'""

SOLE

���

�

OM

TO Y CLOC K

FUTUR EB US+
BRIDGE

I
BUFFER

MAILBOX

�
I

I
I

I
I
I

I

NVRAM

MICROCONTROLLER

32KB
S E RIAL
PROM

32KB
SERIAL
PROM

1

DECCH I P

1 M B OR 4 M B
BACKUP
CACHE

I

1

MEMORY
MODULE 2

M E M O RY
M O DUL E 3

DRAMS

DRAMS

DRAMS

M E MORY
M O DUL E 4

I

NVRAM

M I C R OCONTROLLER

2 1 064 CPU

MEMORY
MODULE 1

DEC C H I P
21 064 C P U

1 M B OR 4 M B
BACKUP
CACHE

DRAMS

I
280

280

280

280

DRAM
CONTROL

DRAM
CONTROL

DRAM

DRAM

CONTROL

CONTROL

BIU

BIU

BIU

BIU

1 46
1 46

IB u s

I

I

BIU

I

I

BIU

CLOCKS

I

��--------4-0_M_M--------����-----4-0_M_M-----����----2-0_M_M----����---2-0_M_M---���L----2--0 M-M--���
Figure 3

DEC 4000 AXP System Bus

20 MM

�
...J
ifJ

Alpha AXP Architecture and Systems

clock edge and u t i l ize o ne of two system bus

After exa m i n a t i o n of several I/0 buses that sa tis

clocks. A custom clock c h ip was im plemented to

fied these c r i teria, the Futurebus+ was selec ted . At

prov ide p rocess, voltage, temperature, and load

the

(PYTL)

Futurebus+ specification was in developm ent by

regulation to the pair of appl icat ion- specific

i ntegrated ci rcu i t (ASJC) chips that comp ose each

time

of

our

invest igation,

however,

the

the IEEE and a wide range of i n terest was evident

Blli . The clock chip achieves m o d u le- to-m o d u l e

throughout the indust ry. By p roviding t he right sup

skews of less t h a n 1 n s .

p o r t to the F u t urebus+ com mit tee, Digital was in a

O u r search fo r a c l o c k repeater chip t h a t c o u l d
m inim ize

modu le-to-mod u l e s k e w a n d c h ip - to

p os i t i o n to h e l p stab i l i ze and bring the spec i fica
tion to com plction.

c h ip s kew on a module, and yet d i rec t l y drive high

A D igital team represented the proj ect's i nterests

fan - o u t ASIC chips w i th Ci\'lOS- level clocks, led us

o n the IEEE PH96.2 Sp ec ification C o m m i t tee and

to Digital's Semiconducto r Operations <_ ; ro u p . Such
a chip was i n design ; however, it was tailored

proposed standards as the DEC 4000 AXP system

design evolved. This team ach ieved its goa l by help

for use at the DEC 6000 system bus frequency

i ng

The Semiconductor Operations Group agreed to

enabled th, Futurebus+ to operate as

change the ch ip to acco m m odate the DEC 4000 AXP

mance I/0 exp a n s i o n bus. To m i tigate sched u le

system bus frequency

the

! EE L C o m m ittee

define

a

profile
a

that

high-pe rfor

i mpact due to instab i l i ty of the Fu turebus+ spec ifi
cat ions, t he I/O mo d u l e ·s F u t u rebus+ i n t e rface was
arc h i t c t e d to accom mod ate changes tl1rough a

1/0 Bus TeclJnology
Because of tech nology

ob s o lesc en c e

,

l/0 b uses

have a 2 1 -year l i fe cycle divided into 3 phases.
D u ri ng t he first 7 years of acceptance, p e ripherals
and appl ications are deve loped a nd supported.
Sustained acceptance takes hold i n the next 7 years
as peripherals and a p p l ications are enhanced . I n

t h e l as t 7 years, a phase o u t o r migration of p e riph
erals and appl ications occurs. For the DEC 4000 AXP

more d iscrete,

rather t h an

a h i g h l y i n tegrated

im plemen t a t i o n . Comp l i ance with the F u t u rebus+
specificati ons i nf l u enced most mechanical aspects
of the m o d u le compartment design, as is evident

from t h e centerplane, card cage, m o d u l e construc

tion and size, and po\vtr supply vol tage specifica
t i o ns and i mplementations.

sys tems, our first priority was se lection of a n open

Module Tecbnology

expansion 1/0 bus in the fi rst t h i rd of i t s l i fe cycle.

Mod u l e techno logy was selected to maximize sig

I n a d d i t i o n , we wanted to select an open I EEE stan

nal density w i t h i n the fewes t l ayers with m i n i m a l

dard bus that wou ld a t t ract t h i rd-party deve lop e rs

crossta l k and to prov i d e a u niform signal distribu

to prov ide 1/0 solu tions to customers. The fol low

t i o n i mp edanct: for any m o d u l e layer. Phys ical-to

ing priorit ized criteria were established fo r the

elec t rical model i ng tools were used to create S PICE

selection of a new I/0 bus:

models

of

p l an�.:s,

s ig11 a l

I. Open bus that is an accep ted i ncJu ' try stand ard
i n the beginning third of its l i fe cycle

2 . Compat ibil i t y with Alpha AXP architecture

3.

through arch i tecture (e . g . ,
through

technology

of

chip

packages,

va rious

power

lengths

and

i mp e d a nces (based on the module construction
technology), ancl m u l t i p le s ig n a l I ines. Because t h e

p l a c e m e n t of comp onents a ffects signal p e r for
ma nce and quality and system performance (e . g . , in
p lans and t r i a l layou ts \verc completed .

4. Sc a l ab l e feature s that are p e r form ance-e. ten
sible

l ines

the second-len·' processor cache), m o d u l e floor

Min i m u m data rate of l00Ml3/s

and/or

connectors,

bus w i d t h) ,

A

module

l ayout tool was used to ensu re prod ucibil i ty com

p l iance w i t h manufac t u ring stand ards as wel l as sig

i m p rovements

nal rou t i ng constraints. The m o d u le l ayou t process

(e.g . , semico nductor device p e rfor m ance and

was iterative . As sections of the m od u le rou t i ng

integrati on)

·were completed. SPICE moclels of t h e e t c h were
extractecl. These

5. M i n i m u m 64-bit data path

interoperab i l i t y

t racted models were c o nnected

was completed a n d req u i red cha nges were imple

6. Support of b r idges to other 1/0 buses

7. M i n i m a l

e

to SPICE models of ch ip d rivers and r u n . A na ly s is

problems

devices from d i ffe rent vendors

betwe e n

mented :md a n a lyzed aga i n . The process c o n t i nued

u n t i l the o p t i m a l specifi c a t i o n c o n fo r mance was
achieved fo r a l l signals.

Vr!l. .:j So. 4

.��)(!Cia/ Issue /'}'}2

Digital Technical journal

Design and Pe1jonnance of the DEC 4000 AXP Departmental Seruer Compu ting Systems

Module size was estimated based on system fu nc

submicro n CMOS or BiCMOS technol ogy. Al l t he 1/0

tio n a l i t y req u i rements and a study of the size and

and power subsystem contro l ler ch ips such as the

power requirements of that fu nctiona l ity. To si mp! i

SCSI and DSSI contro l lers. E t hernet control lers,

fy the enclosure design , module size specifications

serial l i ne interfaces, and ana log- to-d igital convert

are consistent \Vith the Futurebus+ module specifi

ers were i m plemented in CMOS technology.

cations. li.> ach ieve lower system costs, the proces

Speed or h igh drive is critical in radial clock d is

sor, memory, and 110 modu les arc based on the

tribution, Futurebus+ interfacing, or memory mod

same ten-layer control led i m pedance construction.

u le address and control signal fa n-out. In these

Chip engineers avoided the specifica tion of fine
p itch surface-mount c h ips when possible. Com po

special cases, lOOK ECL operated i n positive mode

( PECL) or BIPOLAR technology was employed.

nent choices and modu l e layou ts were completed
with a view toward m a n u facturabi l ity. Cost ana lysis
showed that m ixed, double-sided su rface-mount
components and t h rough-hole components had
ins ignificant added cost when fused tin-lead mod
u le technology ami wet - fi l m solder-mask technol
ogy were used . The req u i red layer construction and
im peda nces of 45, 70, and 100 ohms could easi l y be
achieved within cost goa l s through this technology.
Solder-mask over bare copper techno logy was a l s o
eva l uated to dete rmine if fi ne-pitch su rface-mount
components achieved h igher yield t h rough the sol
der reflow process. This eva luation showed fused
tin- lead techno logy was better su ited , based on
defect densit ies, fo r the m a n u facturing process.
Conseq uent ly. a l l DEC 4000 fu'< P mod uks are i m ple
mented with fused t i n - lead m o d u le tech nology and
we t - fi lm solder-mask tech nology.

System Bus Protocol and Technology
The cache coherence protocol fo r the shared-mem
ory system bus is based on a scheme in which each
cache that has a copy of the data from memory a l so
has a copy of the i n formation about i t . A l l cache
contro l lers monitor or snoop on the bus to deter
mine whether or not they have a copy of the shared
block. Hence the system bus protocol is referred to
as a snooping protocol, and the system bus is
referred to as a snoop ing bus:i
The 128-bit -wide synchronous system bus pro
vides a write u pdate 5 - state snooping protocol fo r
write-back cache-coherent 32-byte block read a n d
write transactions t o system memory address space.
Each module uses a 192-pin signal connector-the
same connector used by Fu turebus+ modu les. Each
modu le interfaces between the system bus and its
back port with two 299-pin PGA packages contain

Semiconductor Technology

i ng CMOS ASIC ch ips, wh ich implement the bus pro

As a res u l t of a perfo r m ance, cost, power, and mod

tocol. A total of 157 signals a n d 35 reference

ule rea l estate study, CMOS technology was used

connections i m plement the system bus in the 192-

extens ively. The custom-designed PVTL clock chips

pin connector (6 interrupt and error, 8 clock and

were developed in 1 .0 - micrometer CMOS tech nol

i n i t ia l izatio n , 128 command and address o r data, 4

ogy to supply C\!JOS-level signa l s for driving d i rectly

parity,

into the

BI U chips. Each module's Bill used the same

0.8-mi crometer ASIC technology and die size to

II

protocol). Al l control/status registers

(CSRs) are visible from the bus to s i m p l ify the data
paths as wel l as to support SMP.

closely ma nage clock skews. Each system bus mod

To s i mp l ify the snooping protocol, only fu l l

u l e 's B i l l is i m p lemented by two identical chips

block transac tions are su pported ; m as k i ng o r sub

Bl li .

operated i n an even and a n odd s l ice mode. C h i p

block transac ti ons occur in each m o d u le's

designers i nvented a met hod fo r a c c e p t i n g 5.0-V

Transactions are described from t h e p erspect ives

sign a l s to be driven i nt o their 3.3-V biased DECchip

of a com m ander, a responder, and a bystander. The

2 1064 C:Pl l . Consequently, the selection and i mple

address space is part i t ioned i nto CSR space that can

mentation of 5.0-V ASIC: technology were easier.

not be cached , memory space that can be cached ,

ASIC vendor s e l ection was based on (I ) p e rfo r

and secondary l/0 space for the Futurebus+ and 1/0

mance of tria l designs and t i ming ana lysis of parity
and EDC trees, (2) SPICE anal ysis of 1/0 d rivers with

mod u l e devices. Secondary 1!0 space is accessible
through a n l/0 mod u le m a i l box transaction, which

d i rect-d rive input clock cel ls, and (3) a layout a b i l

pends or retries the system bus when access to very

i t y to s u p port wide clock trunks a nd d istribu ted

slow 1/0 contro l ler registers con fl icts with d i rect

c l ock buffering to effect low skews.

memory

access

(DMA)

t raffic.

This

software

All memory chips on the CPU m o d u l e . memory

assisted procedure also provides masked byte read

module, and 1/0 module were i m ple mented in

and write access to 1/0 devices as wel l as a standard

Digita/ 1echn ical journal

Vol.

Nu.

•1

Special Issue 1992

89

Alpha A_,"XJ> Arc hitecture and Systems

software i nterface. The use of 32-bit peripheral
D iVI.A devices avo ided the need to impl ement hard
ware address translators. The software d rivers pro
vide physical addresses; hence mapping registers
a re not necessary.
The l/0 module drives t wo device-related in ter
rupt signals that are received by both CPl · modu les
(lue to SM!' req u i rements. One i nterrupt is associ
ated with the Futurebus+, and the other is associated
with a l l the device control. lers local to the l/0 mocl
u le . The J/0 m o d u l e provides a silo register of
Futu rebus+ i nterrupt p o i n ters and a device request
register of local device i nterrupt requests. CPU 1 o r
CPU 2 is the designated i nterru p t d ispatcher mod
u le . Privi leged arch itecture l i brary software sub
rou ti nes, known as l'A Lcode, run on the primary
CPU m o d u le and read the device interrupt register
o r F u t urebus+ i n terrupt register to dete r m i n e
wh ich l o c a l d ev ices or wh ich Futurebus+ device
hand lers are to be d ispatche d .
T h e e nclosu re, power, and cool ing subsystems
are capable of i n terrupting both processors when
i m mediate attention i s requ ired. A CPl J can obtai n
information from subsystems shown i n Figure 2
through the seria l control bus. The serial con trol
bus enables highly rel iable com m u n i cations
between field replaceable subsystems. D u ri ng
power-up, i t is used to obtai n configu ration i n for
mation. It is a lso used as an error-logging cha n n el
and as a means to c o m m u n icate between the CPU
subsystem , power subsystem , and the OCP. The
nonvolatile RAM (NVRAM) chip i m plemen ted on
each module a l lowed the firmware to use software
swi tches to configu re the syste m . The software
swi tches avo ided the need fo r hardware switches
a n d jumpers, fie l d replaceable u n i t identification
tags, and handwritten error logs. As a resu lt, the
hardware system is fu l ly configured through
fi rmware , ami fau l t info r m a t ion travels with the
field replaceable unit.
The five-state cache coherence protocol assu mes
that t he processor's prim ary write-through cache is
m a i n t a i ned as a subset of the second- level write
back cache. The 1m : on the CPU module e n forces
this subset p o licy to s i m p l ify the s i m u lation verifi

cipates in the coherency pol icy by signa l i ng shared
statu s to a CPU read of a block it has buffered . The
five stares of the cache coherence protocol are
given in Table 2 .
T h e cache coherence protocol ensures that o n l y
one CPU module can ret urn a d i rty response. The
d ir t y res p o nse obl igates the responding CPU mod
ule to supply t he rea(] data to the bus, s i nce the
memory copy is stale and the memory control ler
aborts t he return of the read data . Bus wri tes always
clear t h e dirty b i t of the referenced cache block i n
both t he commander module ami the m o d u l e that
takes the u p date.
A CPU has two op tions when a bus transaction is
a write and the block i s fou n d to be val id in its
cache. A CPU either i nvalidates the block or accepts
the block and updates its copy, kee p i ng the block
valicl . Th is decision is based on the state of the pri
mary cache's d u p licate tag store and t he state of the
second-level cache tag store. Accep tance of the
transaction i n to the second- l evel cache on a tag

Ta ble 2
State

R e m a rks

NOT VAL I D

Block is inva l i d .

2

VALID
NOT SHARED
NOT D I RTY

Valid f o r read o r write, this
cached block contains the only
copy of the block; the copy is
identical to the memory copy.

3

VALID
NOT SHARED
D I RTY

Val i d for read or write, this
cached block contains the
only cached copy of the block.
The cached copy has been
modified more recently than
the memory copy.

4

VALI D
SHARED
NOT D I RTY

Block is val id for read or write,
but a write must b roadcast to
the bus. This block may be i n
another cache, b u t t h e memory
copy is identical.

5

VALID
SHARED
D I RTY

Block is val id for read or write,
but a write must broadcast to
the bus. This block may be i n
another cache, b u t the contents
have been modified more
recently than the memory copy.
This is a transitional state that
occ u rs when arbitrati ng for the
bus to broadcast a write or
when an unshared d i rty block is
retu rned to a bus read
transaction.

cation p rocess. W i thout it, the nu mber of verifica
tion cases wou kl have been excessive, d iffi c u l t
to express, and d i ffic u l t to s i m u late and check for
correctness. The 1/0 m o d u l e implements an i nva l i
date-on-write pol icy, such t ha t a block it has read
from memory w i l l be inva l idated and then re-read
if a CPU wri tes to the block . The l/0 module parti-

90

F ive States of t h e Cache
Coherence Protocol

V(J/. 4 No. 4

.\jJecial lssue

/')')2

D igital Tec!Jnical journal

Design and Perfonncmce of the DEC 4000 AXP Departmental Server Computing Systems

match is called conditional update. When the com

caches to a commander module. The control ler

mander is the 1/0 module, the write is accepted by a

then signals the start of the add ress and command

CPU only if the block is val id . Depending on the

cycle 0 (CA). The commander drives a val id address,

state of the prim ary data cache dupl icate tag store,

command , and parity (CA D) in cycle l. A comman

two types of hit responses can be sent to a n 1!0

der m ay sta l l in cycle 2 before supplying write data

com mander- I/O u p date always and l/0 conditiona l

(WD) in cycles 2 and 3.
Read data (RD) is received in cycles 5 and 6. The

update. In the case of either l/0 or CPU com mander
writes, if the val id block is in the primary data

addressed responder confirms the data cycles by

cache, the block is invalidated. The two acceptance

asserting the acknowledge signal two cycles later.

modes of I/O writes by a CPU are program m able

The commander checks for the acknowledgment

because accepting writes uses approximately 50

and, regardless of the presence or absence, com

percent more second-level cache bandwid t h than

pletes the nu mber of cycles specified for the trans

inval idating writes.

action.

Snooping

protocol

resu lts

are

made

To implement the cache coherence protoco l , the

avai l able ha l f way through cycle 3. As shown in

CPU m odu le's second- level cache stores informa

Figure 5, the protocol timing from val id address to

tion as shown i n Figure 4 for each 32-byte cache

response of two cyc les is critical. A resp onder or

block.

bystander may stall any transaction in cycle 4 by

Figure 5 shows the cycle t im ing and transaction

asserting a stall signal i n cycle 3. The bus stal ls as

sequences of the system bus. Write transactions

long as the sta l l signal is asserted. Arbitration is

occur in six clock cycles. Read , nu l l , and exchange

overlapped with the last cycle of a transaction, such

transactions occur in seven clock cycles. A nu l l

that tristate confl ict i s avoided.

transaction enables a commander to nu l l ify the

A 29-bit lock add ress register provides a lock

active transaction request or to acquire the bus and

mechanism p e r cache block to assist with software

avoid

without mod ifying

synchronization operations. The lock address regis

memory. The arbitration cont roller monitors the

resource contenti o n ,

ter is managed by each CPU as it executes load from

bus transac tion type and fo llows the transactions,

memory to register locked longword or quadworcl

cycle by cycle, to know when to rearbitrate and sig

(LOx_L) and store register to memory conditional

nal a new address and command cycle. Addit ional

longworcl or quadword (STx_C) instructions." The

cycles can be added by stal ling in cycle 2 or cycle 4.

lock address register holds an address and a valid

Transactions begin when the arbitration controller

bit, wh ich are compared with a l l bus transaction

grants the use of the CPU modu le's second-level

addresses. The val id bit is cleared by bus writes to a

•

•

•

•

•

•

•

•

TAG consists of physical address bits with a second-level cache, or 1 1 physical
address bits with a second-level cache.
PARITY (TP) bit i n dicates even parity
VALID (V) bil indicates whether or not this block can be considered for a response to the
snoop transaction.
SHARED (S) bit indicates whether or not this block may also be resident in another
module's cache.
DIRTY (D) bit indicates whether or not this block has been modified by this processor.
CONTROL PARI T Y (CP) bit i n di c ates even pari t y.
DATA (LW) bits organized as two 128-bi t-wide half blocks; each 128-bit block is composed
of four longwords.
CHECK (CKO through CK7) bi t s detect errors for each longword.
9

4MB

1 MB

TAG

Figure 4

Digital Technical journal

Vol.

'i

No. 4

Second-level Cache Structure

SjH!ciul /ssue }')')2

91

Alpha AXP Architecture and Systems

WRI T E
CYCLE
ARBITRATE
GRANT
COMMAND
CA
ADDRESS
CAD
ACKNOWLEDGE
SHARED
DATA
6

1

0

KEY:
CA
CAD
WD
RD

3

4

5

0

GRANT
CAD
WD1

READ, NULL,
EXCHANGE CYCLE
ARBITRATE
GRANT
COMMAND
CA
ADDRESS
CAD
ACKNOWLEDGE
SHARED/DIRTY
DATA
5

2

1

0

CA WD1
CAD
WD2

2

3

CA

WD2

5

4

6

0

GRANT
CAD

CA
CAD
WD2

WD1

WD1

1

CA

WD2
RD1 RD2

COMMAND
ADDRESS
WRITE DATA
READ DATA
Figure 5

System Bus Transaction Sequences

matching address or by CPU execution of STx_C
instructions. The register is loaded and validated by
a CPU 's LDx_L instruction. This hardware and soft

1 . DECcbip 21064 processor

2. 1 MB or 4MB physical ly addressed wri te-back
second-level cache

ware construct, as a means of memory synchroniza
tion, statistica lly avoids the known problems wi th

3. B i l l chips containing write merge b u ffers, a

exclusio nary locking schemes. Exclusionary lock

duplicate tag store of t he processor's 8 - k i l obyte

ing schemes create resource dead locks, transaction

(KB) data cache for inva lidate filtering and write

ordering issues, and p erformance degradation as
side effects of the exclusion. This construct al lows

u pdate p o licy decisions, an arb itration con
tro l ler, a system bus interface, an address Jock

a processor to continue

register, and CSRs

program execution

wh ile

hardware provides the branch condi tions. The lock
fa ils only when it loses the race on a writt col l i sion

4. System

to the locked block.

prim ary an d

second- level

caches.

The

shared

'5

N U LL

transaction is issued when a ST _c write is
-

aborted clu e to the fai lure of the lock to avoid
system memory modification.

CPU Module Subsystems

processor

clock

genera

System bus reset control

6. 8 KB serial RO M for power-up software loading

of the processor

response forces writes to the block to be broadcast,
ami ST:x_c instru ctions to fu nction correctly. The

and

d istri butors

A bus transaction address that hits on a valid lock

address register must return a snooping protocol
shared response. even if the block is not val id in the

bus

tors, clock and voltage detectors, and clock

7

Microcontroller (MC) with serial system bus
interface and serial line u n i t for com munication
with the processor's serial line interface

8. NVRAM chip on the serial control bus
Since a CPU module bas tO operate i n either CPU 1

Each CPU module consists of a number o f su bsys

or CPU 2 mode, the CPU 2 con nector was designed

tems as shown in Figure 3. The CPU module's sub

to provide an identification code that enables or d is

systems are

ables

92

Vu!. 4 No. 4

the clock drivers and configures the CSRs'

Special Issue 7.992

Digital Technical journal

Design and Pelfornumce of the DF:(. ·1000 AXP Dejxtrlmenta/ Sert ,er Comjm ting .�)'stems

address space a n d CPC identification code. As a

or write accesses to complete in four i nternal clock

resu l t , arbitration and other slot-dependent lim c

cycles, cal led the four-tick loop t i m i ng of the sec

tions are e nabled or d isabled when power is appl ied .

ond- leve l cache. To rea l ize both optimizations, the

A rel iabi l ity study of a parity-protected second

CPU's synchronous i n terface is s u pported by an

level cache showed that the S!ZAMs contribu ted 44.7

asynchronous i n terface in the BllJ . Va rious t i m i ng

percent of the failu re rate. By i mplemen t i ng ElK on

relationsh ips

the data SRAM portion o f the seconcl- level cache, a

system bus are control led by programmable timing

between

the

processor and

the

tenfold improvement in per processor mean time to

controls in the Bi l l chips.

fai l u re was achieved. Consequen t l y, s i x SRAM chips

To achieve the tight, fo u r-t ick timing of the sec

per processor were i mplemented to e n s u re h igh

o nd- level cache, double-sided surface-m o u n t tech
no logy was used to place the SRAM chips physical ly

rei iabil ity.
The mu ltiplexed interface to the second- level

close together. This m i n imized address wire length

cache of the CPU module a l l ows the processor chip

and the number of mo d u le vias: hence the d river

a n d the system bus equal and shared access to t he

was loaded effect ively. This careful p l acement was

second-level cache. To achieve low-latency memory

combined with the design of a custom CMOS

access, both the m icroprocessor and the system

add ress fan - o u t bu ffer and m ul tiplex e r chip (CAB)

bus operate the second-level cache as fast as pos

to achieve fast propaga t i o n delays. The CAB chip

sible based on their clocks. Hence the second

was implemen ted in the same CMOS process as the

level cache is m u l t iplexed , and owners hip defa u l t s

DECchip 2 1064 CPU to obtain the desired through

to

the

m icroprocessor. When the system

bus

put delay. Combined with 12-ns SRAM chips, the CAB

requires access, ownership is transferred quickly

chip enabled optimization of the CPU's second- level

with data SRANl para l l e l i s m w h i le the tag S lZAMs are

cache timing as we l l as the system bus s nooping

monitored.

protocol response timing.

Many of the CPU modu le subsystems are fou n d i n
these chips wo rking i n tandem impl ement the Bt L;

1/0 Module, Mass Storage, and
Expansion 1/0 Subsystems

and the second- level cache contro ll er. \Vrite merge

The l/0 mod u le consists of a local 1/0 su bsystem

bu ffers combine masked write data from the micro

that i n terfaces to the common 1/0 core and a bridge

the interface gate array ca lled the 0 c h i p . Two of

processor with the cache block as part of an a l l o

to the Fu turebus+ for l/0 options. By i ncorporati ng

cate- o n -write pol i cy. S ince the micro processor has

modu larity i n to the design , a broad range of appl i

write bu ffers that perform packing, fu ll block write

cations co u l d be su pported . To satisfy the disk per

around the second- level cache was imp l e me n ted as

fo rma nce and b u l k storage metrics given i n Table 1 ,

an excep tion to the a l locate-on-wr ite pol icy. To

mass storage was configured based o n appl ications

meet sched u le a n d cost goa l s with few perso n n e l ,

requirements. Fast access ti mes of 3 . 5 - i nch disks

o n e comp lex gate array w a s designed rather than

a n d m u ltiple spind les were se lected for appli ca

severa l lower-com p lexity gate arrays. Hence the

tions with resu l t s i n Q I O/s. The density of 5.25-i nch

data p a t h and t he control limctions were parti

disks was selected fo r ap plications requ iring more

tioned such that the m icroprocessor could operate

storage space. As ind icated in Ta ble I , tbe metrics of

as an even or odd member of a pair on the CPU I or

greater than 4,000 QlO/s determined the perfor

the CPU 2 mod u le .

mance requ irements of the storage compartment.

The system b u s c l o c k design i s somewhat in de

Each of the fo ur disk storage compartments in the

pendent of the processor c lock, but the ra nge is

system e nclosure can hold a h1 l l - s ize 5.25 -inch 'l isk

restricted due to the i mplementation of the snoop

i f cos t - e ffective b u l k storage is neede d . I f the need

i ng protocol t i m i ng , t h e m u lt i plexed usage of the

is for the maximum n u m ber of l/Os per secon d ,

second - l evel cach e , ancl the CPU inte rface ha nd

each compartme n t c a n hold up t o four 3.5-inch

shake and data t i m i ng. Therefore, the system bus

disks in a mini array.

cyc l e t ime is optimized to provide the maximum

Configurations of 3:5 - i nch disks i n a brick en able

performa nce regard less of the processor speed.

optimization of through put t h rough paral lel i s m

Likewise, the processor's cycle time is optimized to

tech n iques s u c h a s stripe s e t s a n d redundant array

provide maximum performance regard less of the

of i nexpensive d is k s (li.AlD) sets. The brick con

bus speed . Considerable effort resulted in a second

figura t i o n also e nables fau l t tolerance, at the

level cache access time that en abled the CPU's read

expense of throughput, by using shadow sets. With

D igital Technicaljou r11 a l

Vol. 4 No. 4

Special Issue 1992

9.3

Alpha AXP Architecture and Systems

this techn ique, each storage compartment is i n ter
faced to the system through a separate bu ilt -in con
trol ler. The control ler is capable of running i n

5.

Console serial line u n i t (SUJ) i nterface

6.

Aux i l iary SLU i nterface with modem con t rol
support

either DSSI mode for h igh availability sto rage i n
cluster connections w i t h other OpenVMS AX P or
VMS systems, or in SCSI mode for local d isk storage
available from many d ifferent vendors. For appl ica

7.

Time-of-year (TOY) clock, with battery backup

8.

8KB of e lectrically erasable memory (EEROM)
for console firmware support

tions in which a disk volume is striped across multi
ple drives that are in differen t storage cavities, t b e
benefit from t h e paral lel s e e k operations of t he
drives combines with the parallel data transfers
provided by the mul tiple bus interfaces. The main
memory capacity of the system al lows for disk
caching or RAM d isks to be created, and the process
ing power of the system can be applied to managing
the m u ltiple disk drives as a RAID array. With cur

9.

Serial control bus control ler and 2 kilobits of
NVRA1vl

10.

64-bit-wide Futurebus+ bridge

11.

BIU, containing fou r hexwords of cache block
buffering, two m a i lbox registers, and the
system bus i nterface

rent technology, maximum fixed storage is 8GB

The instabi l i t y of the Futurebus+ specifications

with 5.25- inch disks and 24GB with 3.5 -inch disks. I f

and the use of n ew, poorly specified controller

the built-in storage system is i n adequate, connec

chips presented a high design risk for a highly inte

tion to an external solution can occur through the

grated im plementation. Therefore the Futurebus+

Futurebu s+.

bridge and local I/0 control logic were i mple

The Bru is i mplemented by two 299-p i n ASIC

mented in

program mable logic

to isolate the

chips. The bridge to the Futu rebus+ and the inter

high risk design areas from the ASIC development

face to the local I/0 devices are provided with sepa

process.

rate interfaces to the system bus. Each interface
contains two bu ffers that can each contain a hex
word of data. This al lows for double buffering of 1/0
writes to memory for both interfaces and for the
prefetching of read data by which the bridge
improves throughput. These bu ffers also serve to
merge byte and longword write transaction data
into a fu l l block fo r transfer over the system bus. In
this case, the write to main memory is preceded by
a read operation to merge modified and unmodi
fied bytes within the block.
The Ethernet controllers and SCSI and DSST
control lers can hand l e block transfers for most
operations, thus avoiding unnecessary merge trans
actions. As shown i n Figure 3, the I/0 modu le i nte
grates the fol lowing:
1.

Four storage control lers that support SCSI,
high-speed SCSI, or DSSI for fi.xed disk drives
and one SCSI control ler fo r removable meclia
drives

2.

128KB o f SRAIV1 for d isk-control ler-loadable
Two Ethernet con trollers and their station
address

ROMs,

with

switch-selectable

Thin\Vire or thick-wire i n terfaces
4.

512KB

flash

erase

programmable

(F EPROM) for console firmware

94

As shown in Figure 3, up to fou r memory m odules
can reside on the system bus. This modul arity of
the memory subsystem enabled maximum configu
ration flexibility. Based on the metrics l isted in
Table 1, 2GB of memory were expected to satisfy
most applications requirements. Given this 2GB
design goal, the available DRAM technology, and the
module size, the total memory size was configured
for various applications.
The memory connectors provide a u n ique slot
iden tification code to each BIU, which is used to
configure t he CSRs' address space based on the slot
positio n . Memory modu les are synchronous to the
system bus and provide high-bandwidth,

low

l atency dynamic storage. Each memory module
uses 4-bit-wide, 1- and 4-megabit- deep DRAI\1 tech
no logy in various configurations to provide 64MB,
128M B, 256M B , or 512MB of storage on each module.

microcode scripts
3.

Memory Subsystem

To satisfy memory performance goal s , each
memory mod ule is capable of operating alone or in
one of numerous cache block i n terleav i ng configu
rations with other memory modu les with a read
stream capabil ity. A performance study of stream
bu ffers revealed an increase in perform ance from

ROM

memory- resident read-stream buffers. The stream
buffers a l low each memory module to reduce the

Vol. 4 No. 4

Special Issue 1992

Digital Tecbnical journal

Design and Performance of tbe DEC 4000 AXP Departmental Server Computing 5)'stems

average read latency of a Cl'l or 1/0 module. Thus

The DEC 4000 AXP system is a portable u n i t that

more bandwidth is usable o n a congested bus

provides rear access and s i mplified instal lation and

because the ant icipated react data i n a detected

m a i ntenance. The system is mou nted on casters

access sequence is prefetched . The stream buffer

and fits easi ly i n to an open office env ironment.

prefetch activity is statist ica l l y determined by bus

Mod u l a r design a l lowed compliance with stan

activity.

dards, ease of m a n u factur i ng, and easy field servic

Overa l l memory bandwidth is also i m p roved

i ng . Constru c ted of m olded pl astics, the chassis

through exchange transactions, which use victim

is sectioned i n to a card cage, a storage compart

writes with replacement read paral lel ism . lntel-

ment, a base contain ing four 6 -i nch vari able-speed

1 igent me mory refresh is scheduled based on bus

DC fans and casters, a n air p lenu m and baffle assem

activity and a nticir ated opportu n i t ies. Write tra ns

bly, fron t and rear doors, ancl s ide panels. The

actions are bu ffered from the bus before being writ

mass storage compartment supports up to

ten into the DRA.Ms to avoid stall ing the bus.

fixed-storage devices and 4 removable storage

16

Data i n tegr i t y, memory rel iabil i ty, and system

devices. Expansion to storage enclosu res is sup

availabi l i t y are enhanced by the EDC circ u i t ry. Each

ported for appl ications that requ i re special ized

memory mod u le consists of 2 or 4 banks with 70

storage subsystems.

DR.ANI chips each . This enables 256 data b i t s and 24

Feedback from field service engi neers prompted

E lK bits to be accessed at o nce to provide low

us to o m i t useless ligh t - e mi tt i ng devices (LEDs) in

latency for the system bus. A cos t - benefit a n a l y s i s

each subsystem, s i nce access to most electron ics is

showed a savi ngs of DRAM chips when E D C is i m ple

from the rear. As a resu lt, the OCP was made com

mented on each memory mod u le . The processor's

mon to a l l subsystems through the serial con trol

32-bit EDC requ ires 7 check bits as opposed to the

bus and made visible i ns i de the front door of the

128-bit EDC, which requ i res 12 check bits and uses

enclosure. I t provides DC on/off, halt, and restart

fewer c h ips per bank. The selected EDC code also

swi tches, and eight L E Os, which i n d i cate fau l ts of

prov ides better error detection capability of 4-bit

CPU, 1/0, memory, a n d Fu turebus+ modu les. The

wide chips t h a n the processor's 32-bit EDC.

fault l ights are con trolled either by a microcon

To i mprove p e rformance, separate EDC logic

is i m p lemented on t he write path and read path

trol ler on either CPU module or by a n in terface o n
the 1/0 modu le.

of each memory modu le's BIU. The E D C logic

Fu turebus+ slot spacing was provided by the IEEE

performs detect i o n and correction of a l l si ngle

specificat i o n . The system bus slot spacing for each

b i t errors and most 2 - b i t , 3-bit, and 4 - b i t errors i n

modu le was determi ned by functional requ i re

the D RANI array. The EDC's generate function can

ments. For example, the CPU m o d u le requ ires 300

detect certain types of a d d ressing fai l ures associ

l inear feet of air flow across the DECc h i p 2 1 064

ated with the DRAM row and col u m n a d d ress b i ts,

microprocessor's 3 - i nch square heat sink, as seen in

along with the bank's select address b i ts. Fai l u res

F igure 1 , to ensu re the 25 -wat t chip could be

associated with

these addressing fields can be

cooled rel iably. Since VAX 4000 systems provide this

detected, thus i mprovi ng data i n tegrit y. Software

same air flow across modu les, cool i ng was not a

errors can be scru bbed from memory by the CPU

major design obstacle. The modu le compartment's

when requested through use of PALcocle subrou

Futurebus+, system bus, and power subsystems can

t i nes, which use the LDx_l.. and STx_C synchron iza

be seen i n the enclosure back view of Figu re 6.

tion construct w i t hou t havi ng to suspend system

Al l electro n i cs i n the enclosu re, as shown in

operations.

Figure 7, are a i r cooled by fou r 6 -i nc h fans i n the

Enclosure and Power Subsystems

front, gu ided along a plenu m and baffle assembly

The DEC 4000 AXI' enclosure seen i n Figure 1 is

a n d down t h rough the module compartment and

base. Air is drawn i nto the enclosure gri l l at the top

cal led the BA640 box and is 88.0 centimeters (em)

power su pply compartment to the base. Air i s also

high, 50.6 em wide, and 76.2 em deep. It weighs 1 18

drawn through front door louvers and across the

to 125 ki lograms fu l l y configured. The enclosu re is

storage compartments a nd down to the base.

designed to operate in an office env i ro nment from

Electron ics connected to the power subsystem

lO to 35 degrees Celsius. The power cord can con

m o n i tor

nect to a conventional wa ll ou tlet which suppl ies

exhaust temperatures. Thus the fa n speed can be

u p to 20 amperes at either 120 v AC or 240 v AC .

regu l ated based on temperat u re measurements,

Digital Techuical journal

1'<>1. 4 No. 4

Special issue I'J'J2

am bient

and

module

compartment

95

Alpha AXP Architecture and Systems

FUTUREBUS+

SYSTEM BUS

are f()r fixed storage bricks. A storage brick consists
of a base plate and mounting hardware, d isk drives,
local d isk converter (LDC), fro nt bezel assembly,
and wiring harnesses. The LDC converts a dis
tribu ted 48.0 V to 1 2 .0-V and 5.0-V supplies and a
5.0-V termination reference fo r the brick to ens ure
compl iance with vo l tage regu lation specifications
and termination vol tage levels of cu rrent and fu ture
disks.
The 20-ampere power subsystem can del iver

I ,400 watts of DC power d ivided across 2 . 1 V, 3.3 V,
5.0 V, 12.0 v: and 48.0 V The enclosure can cool
1 , 500 watrs of power and can be configured as a

master or a slave of AC power ap p l i cation. Use of a
universal F E U eliminates the need for selecting
operat i ng vol tages of 120 V o r 240 V AC. The F Ll l
converts the i n p u t AC i nto 385 V DC which i s dis
t r i b u ted to provide 48 V DC to two step-down DC
to-DC conveners, which work i n para l le l to share
the load curre nt. The combi ned 48 V DC o u t r u t
from these converters i s del ivered w the rest o f the
system.
Control of d istri b u ted power electronics is d i ffi
c u l t and expensive with ded icated electronics. A
cost-effective alternative was use of a one-chip
CMOS m icrocontroller, surrounded with an array of

sensor i n p u ts t h rough CMOS analog- to -d igital con

POWER

verters, to prov ide PSC i n t e l ligence. Decision-mak
i ng

abi l i ty

in

the

power su bsystem

enabled

compl iance with voltage-sequencing specifications

Figure 6

DEC 4000 AXP Enclosure Rear View

and fai l-safe operation of the syste m. The micro
contro l le r can cont rol each LDC and commun icate
with the CPU and ocr over the serial control bus. It

reducing acoustic no ise in an air-conditioned office
environment.
The centerplane assembly consists of a storage
backplane, a modu l e backplane, and an electromag
netic shield. This implem e n tation avoids depen
dence on cable assembl ies, which are u nreli a b le
and difficu l t to insta l l and repair. Defined connec

monitors ove r and u n d e r voltage, temperature, and
energy sto rage conditions in the mod u le and stor
age compartments. lt also reports status and fail ure
information either to the CPU or to a d isplay on the
PSC: module, which is v isible i nside the enclos ure

back door.

tors a nd mod u l e s i zes a l l owed the enclosure devel

Firmware

o pment to proceed unencu mbered by m o d u le

The primary goal of the console interface is to

specificati o n changes. The shie lded modu le com

bootstrap the operati ng system th rough a process

partment prov ides effective attenua t i o n of s igna ls

cal led boot-block booting. The console in ter

up to 5 gigahertz. There are six Futu rebus+ s lots,

face runs a minimal l/0 device hand ler rou tine

fou r memory slots, two CPU slots, one 1/0 slot, and

(boot p r i m i t ive) to read a boot block from a device

fou r central power module slots, which i nclude the

that has descriptors. The descriptors point to the

FEU, PSC, DC5, and DC3 u n i ts.

The sto rage compartment contains six cavi ties,

logical block numbers where the pri mary boot
strap p rogram can be found, and the console

as seen in the enclosure front view of Figu re 8.

i nterface loads it i n to system memo ry. To accom

Two cav i t ies are for removable media, and fou r

pl ish this task, the firmware m ust configure and

96

Vol. 4 No. 4

Special Issue 1992

Digital Technical jour11al

Design and Performance of the DEC 4000 AXP Departmental Server Comp u ting Systems

OCP

VTERM

STORAGE B R I C K

DC5

DC3

PSC

MEMORY

STORAGE B R I C K

C E N T E R PLANE

CPU

1/0

Figure 7

FBE

DEC 4000 AXP Modular Electronics

test the whole system to ensure the boot process

console m e m ory, and then transferring control to

can complete without fa i l u res. To m i n i m ize t he

the console code.

bootstrap time, a fast memory test execu tes i n the

The FEPROM firmware consists of halt dispatch,

time necessary t o test the largest memory m od u l e ,

entry/ex it, diagnostics, system restart, system boot

regardless of t h e n u m ber of memory modu les. I f

strap, and console services fu nctional blocks.

fa i l u res are detected after configu ration i s com

PALcode subrou tines prov i d e a l ayer of software

pleted, the firmware must p rovide a means for d iag

with com m o n i nterfaces to upper levels of sofware.

nosis, error isolation, and error logging to faci l i tate

PALcode serves as a bridge between the hardware

the rep a i r process. The DEC 4000 AXP system pro

behavior and service requ irements and the requi re

vi des a new console command inte rface as we l l as

ments of the operating syste m . The system takes

in tegrated d iagnostic exercisers in the loadable

advantage of PA Lcode fo r harcJware-level i n terrupt
han d l ing and return, securi ty, i m plementat ion of

firmware.
The firmware resides on two separate enti ties, a

special operating system kernel procedures such as

block of serial ROM on the CPU m odule and a block

queue m anagement, dispatching to the operating

110 module. The serial ROM con

system's special cal ls, exception hand ling, DECchip

of F EPROM o n the

tains software that is autom atica l ly loaded into the

21064

processor on power- u p or reset. This software is

v irtual memory management, and secondary 1/0

virtua l

instruction

cache

m a nagement,

respo nsible for initial configu ra tion of the CPU

operations. Through a combina tion of hardware

module, testing m i n i mal module fu nctional i t y, ini 

and

tializing enough memory for the console, copying

OpenVMS AXP, DEC OSF/1 AXP, and future operating

the contents of the FEPROM into t h is initial ized

systems can execute on t h is hardware architecture.

Digital Technical journal

Vol. 4 No. 4

Special Issue 1992

software- dependent

PALc ocJe

subrout i nes,

97

Alpha AXP Architecture and Systems

Acknowledgments
Development of a new system requires c o ntribu
tions from ind ivid u a l s t h roughout the corporation.
The a u thors wish to acknowledge those who con
tributed to t he key aspects of the DEC 4000 AXP
system . Centerp lanes: Henry Enman, Jim Padgett;

CPU: N i t i n Godiwala, George H a rris, Jeff Met zger,
Eugene Smith, Ku r t Tha l l er; Firmware: Dave Baird ,
Harold Buckingham, Marco C i affi, joh n DeNisco,
Char l ie Deva n e , P a u l LaRochelle, Keven Peterson ;
Futurebus Exerciser: Ph il ippe Kle i n , Kev i n Lud la m ,
Dave

M a ruska;

Ernie

Crocker,

Futurebus+ :

Barbara Archi nger,

Jim

Sam

Duval,

D u nc a n ,

Bi l l

Samaras; 1/0: Randy Hinr ichs, To m H u n t , Sub Pal,
Prasad Paranjape, Chet Pawlows k i , P a u l Rotker,
Russ We ave r ; Man agement: Jesse Lipcon, Gary P
L i d i ngton ; M a n u facturing: Mary Doddy, A l Lewis,
Al la n

Lya l l ,

Cher

Nich o l as ;

Marketing:

Kami

Ajgaon kar, Charles M o n k , Pam Rei d ; Mechanical:
Jeff Lewis, Dave Moore, Bryan Porter, Dave Simms;
Memory:
Tatosian;
Systems:

Paul

G oodwin,

Don

Smelser,

Operations: Jeff Kerrigan ;

Dave

Operating

A] Beave rson, Peter S m i t h ; Power : John

Ard u nio ,

Robert

White;

Simulation:

Paul

K i nzel m a n ; Systems: Vince Asbridge, M i ke Col l ins,
Dave Con roy, AJ De luca, Roger Gagne, Tom Orr,

Figure 8

E r ic Piip; The r m a l : Steve C ieluch, Sharad Shah.

DEC 4000 AXP System
Enclosure Front View

References and Note
Perfo rmance Summary
The

1 . IEEE Standard for Futurebus+-Physical Layer

DEC 4000 AXP Model 610 system's performance

nu mbers as of November 10, 1992 are given i n Ta ble

3. Its perform ance w i l l continue to improve.

1991 (New Yo r k : The I nstitute of E l ectrical and
E lectronics Engi neers, Apri l 24, 1992).

2. Supercompu ter performan ce as defi ned by the

Summary
DEC 4000 AXP systems demonst rate the highest
performa nce and functi o n a l ity fo r D igita l 's 4000
series of departmental server systems. Based on
Digital's Alpha AXP architecture and the IEEE's
F u turebus+ profile B standard, the systems provide
symmetri c

and Profile Specification IEEE Standard P896 2-

mu lt iprocessing

performa nce

for

Open VMS AXP and DEC OSF/ 1 AXP operating systems
in an office environment. The DEC 4000 AXP systems

composite theoretical performance

(CTP) rating

of 397, w i th the DECchip 2 1064 operated at 6 25
ns, as establ ished by the U . S. export regu lations.

Circuit Serial Bus Spe ciji'
cation (PC Bus Specification), (S u n nyvale, CA:

3. inter-in tegrated

Sign etics Company, 1988).

4. J.

were designed to optim ize the cost-perfor m ance

Hennessy and D. Pat terso n , Comp u ter
Architecture: A Quan tita tive Approach (San

ratio a n d to i nc l u d e upgradabi l ity a n d expandabil

Mateo, CA: Morgan Kaufmann P u b l ishers, I nc . ,

ity The systems combine Digi t a J 's GviOS technol

1990): 467-474.

ogy, I/O peripheral s teclmology, a h igh-performance
m u l tiprocessing bac kplane i n terco nnect, and mod

5. R.

Si tes,

ed . ,

Alpha

Ve rsion

AXP

5.0

System Reference
( M aynard:

u l a r system design to supply the most advanced

Manual,

fu nctiona l it y for performanc e-driven appl ica t i o ns .

Equ ipment Corporation, 1992).

98

Vol. 4 No. 4

Special Jssut' I'J'J2

Digita l

D igital Tecbnical journal

Design cmd Pe!formcmce of the DEC 4000 AXP Departmental Seruer Computing Systems

Ta ble

3

CPU Performance Summary for the DEC

4000 AXP System

Futu rebus+ Performance

Peak
Read
Write

Latency

Bandwidth

1 6 bytes/1 00 ns
1 6 bytes/1 82 ns
1 6 bytes/1 33 ns

1 60MB/s
88M B/s
1 20MB/s

Latency

Bandwidth

4 bytes/80 ns
4 bytes/1 60 ns
4 bytes/1 60 ns

50M B/s
25M B/s
25M B/s

Local Bus Performance

Peak
Read
Write
System Bus Performance

Peak
Read
Write
Exchange

Latency

Bandwid t h

1 6 bytes/25 ns
32 bytes/1 75 ns
32 bytes/1 50 ns
64 bytes/1 75 ns

640MB/s
1 82MB/s
21 3MB/s
365MB/s

I nternal Cach e Miss, Second-level Cache H it (Four-tick) Performance

Read
Write

Latency

Bandwid th

1 6 bytes/25 ns
1 6 bytes/25 ns

640MB/s
640MB/s

Latency

Bandwi d t h

32 bytes/275 ns
32 bytes/200 ns
64 bytes/275 ns

1 1 6M B/s
1 60MB/s
232MB/s

CPU Seco nd-level Cache M iss Performance

Read
Write
Exchange

D E C 4000 Model 6 1 0 SPEC m a r k89 and SPECthruput89* Estimated C P U Performance Summary
I nteger (INT) Benchma rks

Ratio

GCC
ESPRESSO

61 .58
82.91
93.05
1 03.46

u

EQNTOTT

Ratio

Ratio

1 @ 54.80
1 @ 81 .76
1 @ 92.1 9
1 @ 1 00.76

2@
2@
2@
2@

50.78
78.33
92. 1 8
97.94

1@
1@
1@
1@
1@
1@

2@
2@
2@
2@
2@
2@

64.95
1 08.95
1 97.80
948.66
1 75.83
1 05.90

Float i n g-point (FP) Benchma rks

SPIC E2G6
DODUC
NASA?
MATRIX300
FPPPP
TOM CATV
SPECmark
SPECint
SPECfp

72.58
1 1 3.81
229.27
1 01 9. 1 7
1 80.32
1 28.70
>

>

>

1 36.23
83.73
1 88.45

SPECthruput >
SPECintth ruput >
SPECfpthruput >

68. 1 9
1 1 3.53
221 .56
963.81
1 77.89
1 23.25

1 @ 1 31 .1 8
1 @ 80.32
1 @ 1 81 .92

2@ 1 24.40
2@ 77.41
2@ 1 70.68

UNPACK - double precision 1 00 x 1 00
36.8 M FLOPS
UNPACK - double precision 1 000 X 1 000 78.4 MFLOPS
1 65.0 Ml PS
Dhrysto ne
Note:

•version 1 .0 OpenVMS A X P operating system, 1 60-MHz clocked DECch i p 2 1 064 microprocessor, 1 M B second-level cache. Notice the 1 . 9
scaling of the second CPU.

D igital Technical journal

Vol. 4 Nu. 4

Special Iss11e Il. 4 No. 4

Special Issue 1992

Digital Tecbnical journal

Nancy P. Kronenberg
Thomas R. Benson

Wayne M. Cardoza

Ravindran]agannathan
BenjaminJ. Thomas III

Porting OpenVMS
from utX to Alpha AXP
The Open ViliS operating system, developed IYy Digital for the VAXfamily of comput
ers,

was recentzy movedfrom the VAX to the Alpha AXP architecture. The Alpha AXP

architecture is a new RISC architecture introduced IYy Digital in 1992. This paper
describes solutions to several problems in porting the operating system, in addition
to petformance benefits measured on one of the systetns that implements this new
architecture.

The VAX architecture is an example of complex

priority levels. The Alpha AXP architecture also

i nstruction set computing (CISC), whereas the

defines a privileged architecture li brary (PAL) envi

Alpha AXP architecture is based on reduced instruc

ronment, which r u ns with interrupts d isabled and

tion set computing (RISC). The two architectures

i n the most privileged of the four modes (kernel).

are very d ifferen t. 1 CISC arch i tectures have perfor

PALcode is a set of Alpha AXP instructions that exe

mance d isadvantages as compared to ruse archi tec

cu tes in the PAL environment, i m plement ing such

tures 2 Digital ported the OpenVMS system to the

basic system software fu nctions as translation

Alpha fu'
2.0

R E LATIVE C P U SPEED

Notes:

1.
2.
3.

The relative CPU speed equals the CPU time on a VAX system
divided by the CPU time on an Alpha AXP system.

A relative CPU speed greater th a n

system is fas te r .

The total number of tests is

Figure 2

2 contains the results for a representative subset of

1 .0 i m pl ie s

that the Alpha AXP

1 98.

Distribution of Relative CPU Speed
for OpenVMS Services

the measured Open VMS services.

their time performing appl ication-specific work

Application Performance

system services. For these applications, p erfor

and a small fraction of their time using operating

Applications vary in their use of operating system

mance depends mainly on the performance of

services. Most appl ications spend the majority of

hardware, compilers, and run- time libraries. We

Table 1

Config u ration Deta i l s for OpenVMS Services Test Environment

VAX System

Alpha AXP System

Model number
C lock rate

VAX 7000 Model 61 0

DEC 7000 Model 61 0

91 M Hz

1 82 MHz

Memory size

64M B

64M B

On-chip cache size

1 K B virtual l-cache
8KB physical I- and
D-caches

8 K B physical 1-cache
8KB physical D-cache
4MB 1 - and D-caches

Backup cache size

4MB 1- and D-caches

Translation buffer

96 entries

1 2 ITB entries
32 DTB entries

Page size

51 2 bytes

8KB

Number of reg isters

1 6 32-bit G PRs

32 64-bit i n teger
32 64-bit floati ng-point

OpenVMS version

Pre-release V5.5-2

Pre-release V1 .0

Key:
I

I n struction

D

Data

ITB

I n struction translation buffer

DTB

Data translation buffer

GPR

General-pu rpose register

1 18

Vol. 4

No.

4

SjJecial lssue 1992

Digital Techuical journal

Porting OpenVMSfrom VA X to Alpha AXP

Table 2

Relat ive CPU Speed for a Subset
of OpenVMS System Se rvices
and Pri m i t i ves

OpenVMS System Service

Relative

or Pri m i tive

CPU Speed

deferred from the first version of the Open VMS AXP
system. Beyond this, we anticipate taking signifi
cant steps to better exploit the h a rdware architec
ture, including evolving to a true 64-bit operating
system in a staged fashion. Also, detai led analysis of
performance results shows the need to alter inter

Memory Manage ment Services
Create virtual address space
Delete virtual address space
Expand address region
Page fault without 1/0
(soft page fault)

n a l designs to better match RISC archi tecture.

1 .03
1 .44
1 .58

Fina l ly, a gradu a l replacement of VAX MACR0-32

1 .05

tant element fo r i n c reasing performance.

Log ical Name Services
Translate a log ical name

1 .75

Event Flag Services
Set an event flag
Clear an eve nt flag

1 .45
1 .35

Process Control Services
Create a process and
activate an image

1 .1 7

source with a h igh-level l a nguage is essential to sup
port a 64-bit virtual address space and is an im por
The OpenVMS A X P system clearly demonstrates
the viabi li ty of making dramatic cha nges in the
fu ndamental assumptions of a mature o perat
ing

system

w h i le

preserving

the

i nvestment

in software l ayered o n the syste m. The future
chal lenge is to continue operating system evolu
tion in order to provide more capab i l ities to ap p l i
cations while maintaining that essentia l level of

F i le System Services
(File on a RAM Disk)
F i le op en
File close
F i le create
F i le delete

compatibil ity.

1 .34
1 .21
1 .24
1 .31

Record Manage ment System (RMS)
Services ( F i le on a RAM Disk)
Get record from a sequential file
Put record i nto a sequential file

0.98
0.96

system divided by the CPU t i m e on an Alpha AXP system. A

1 .0 implies

The work described i n this paper was done by
mem bers of the OpenVMS A X P operating system

Note that the relative CPU speed equals t h e CPU time on a VAX
relative CPU speed greater than

Acknawledgments

that the Alpha A X P

group. This work wou ld have been impossible with
out the help of many software and hardware engi
neering groups at

Digital.

Thanks to Brad ley

\Vaters, who measu red OpenVMS performance, and
to John Shakshober a n d Sandeep Desh m u k h , who
obtai ned the SPEC Release 1 benchm ark res u l ts. We

system is faster.

a l so thank Barbara A . Heath and Kathleen D. Morse
for their comments, which helped in preparing this
paper.
used the SPEC Release 1 benchm arks as representa
tive of s u ch appl ications. Ta ble � shows the details
of the VA X and Al pha AXP systems on wh ich the
SPEC Release 1 s u i te was run, ancl Ta ble 4 contains
the res u l ts. The SP ECmark89 comparison shows
that the OpenWviS AXP system outperforms the
Open VM S VAX system by a factor of 3.59.
The performance of OpenVMS services and the
SPECmark results are consistent with other stud ies
of how operating system primi tives and S P ECmark
res u l ts scale between CJSC a nd RISC _r. Overa l l , the
resu l ts are very encouraging for a first-version
prod uct in which redesigns were pu rposely l i mited
to meet an aggressive sched u le.

nical journal, vol. 4, no. 4 ( 1992, this issue):
19 3 4 .
-

2. D. Bhandarkar and D. Clark, " Performance from
Arc h i tecture : Comparing a !USC and a CJSC with
Similar Hardware Orga nization," Proceedings nf

the Fourth In te-rnational Conference on Archi
tecture Support for Prog-ramming Languages
and Opemting Systems (ASPLOS-!V) (New York,
1 991 ) : 310-3 19.

Some OpenVMS VA X featu res such as symmetric

Digital Technical journal

1 . R . Sites, "Al pha A X P Arch itecture," Digital Tech

NY: The Association for Com puting Machinery,

Conclusions
m u l tiprocessing and

References

VJV!Scl uster support were

Vol. 4

No

4

.SiJecial lssue 1992

3. T Leonard , e el . , VA X Architecture Refe-rence

Manual (Bedford , MA: D igital Press, 1987).

1 19

Alpha AXP Architecture and Systems

3

Table

Configuration Details for the SPEC Release 1 Benchmark Test Environment
VAX System

Alpha AXP System

DEC 7000 Model 61 0

Hardware
Model number

VAX 7000 Model 61 0

Clock rate

91 MHz

1 82 MHz

Backup cache size

4MB 1- and D-caches

4MB 1- and D-caches

Memory size

1 28MB

256MB

Operating system and version

OpenVMS V5.5-2 F i eld Test

OpenVMS V1 .0

Compi lers and version

VAX C V3.2
VAX FORTRAN V5.7
with H PO V1 .3
(h igh- performance option)

Pre-release C compiler
Pre-release FORTRAN compi ler

Other software

KAP V1 .0 for VAX C
and FORTRAN

KAPF/KAPC V1 .49 native
KAP fo r Alpha AXP syste ms

Software

Key:
I

I nstruction

D

Data

Note that DECram, a memory-resident d is k device, was used to create and manage memory-resident disks.

Table

4

SPEC Release 1 Benchma rk Results
VAX 7000

DEC 7000

Model 610
SPECratio

Model 61 0

Relative

SPECratio

Performance

001 .gcc
008.espresso
01 3.spice 2g6
01 5.dod uc
020.nasa7
022.1i
023.eqntott
030.matrix300
042.fpppp
047.tomcatv

34.9
28.8
30.9
42.1
67.2
34.7
38.4
1 38.8
48.8
61 .6

67.5
94.7
87.7
1 26.3
293.0
1 00.2
1 27.6
1 21 9.7
1 93.8
276.5

1 .93
3.29
2.84
3.00
4.36
2.89
3.32
8.79
3.97
4.49

SPECint89
SPECfp89
SPECmark89

34.0
57.6
46.6

95.1
244.2
1 67.4

2.80
4.24
3.59

SPEC Benchmark
Name and Nu mber

Note that relative performance represents the ratio of DEC

4. Open VlHS

7000

Calling Standard (Maynard,

Model 6 1 0 performance to VAX 7000 Model

MA:

Digital. Equ ipment Corporatio n , OctOber 1992).
5. Spec Newsletter, vol. 4, no. 1 (March 1992).

6. T.

Anderson,

H.

Levy,

B.

Bershad,

and

E.

Lazowska, "The I n teraction of Architecture and
Operating System Design," Proceedings of the
Fourth International Conference on Architec
ture Supportfor Programming Languages and
Operating Systems (ASPLOS-IV) (New York, NY :
The Association
1991 ): 108-120.

1 20

for Computing

Mach inery,

610

performance.

General References
R. Goldenberg and S. Saravanan, V1HSfor Alpha Plat
forms Internals and Data Structures, Preliminary

edition of vols. 1 a nd 2 (Maynard, MA: D igital Press,
1993, forthcoming).
]. Hennessy and D. Patterson, Computer Architec

ture, A Quantitative Approach (San Mateo, CA:
Morgan Kaufmann Publ ishers, I n c . , 1990).
R. Sites, ed . , Alpha Architecture Reference Ma nual

(Bu rl ington, MA: Digital Press. 1992).

Vol. 4 No. 4

Special Jssue

1992

D igital Technical]ourlutl

David S. Blickstein
Peter W. Craig
Caroline S. Davidson
R. Neil Faiman,]r.
Kent D. Glossop
Richard B. Grove
Steven 0. Hobbs
William B. Noyce

The GEM optimizing
Compiler System

The G'Eiii compiler system is the technology Digital is using to build state-of the-art
compiler products for a variety of languages and hardware/software platforms.
Portable, modular sojtware components with careful�)' specified interfaces simplify
the engineering of diverse compilers. A single optimize1; independent of the lan
guage and the target platjonn, transforms the intermediate language generated by
the front end into a semantical�v equivalentform that executes faster on the target
machine. The G'EM system supports a range of languages and has been successjul�Ji
retargeted and rebosted for the Alpha AXP and i\lllPS architectures andfor several
operating environments.

In the past, Digital has made m aj o r investments

diverse compilers, GE!'vl compiler products share a

in optimizing compi lers that were specifically

basic architecture. The compiler is d ivided into sev

directed at one hardware platform , namely VAX

eral major components, in effect, the fu ndamental

compu ters. When Digital began broadening its

build ing blocks from wh ich a compiler is con

hardware offerings to include reduced i nstruction

structed. The i nterfaces among these components

set computer (JUSC) architectures, it became clear

are carefu l ly specified. The m aj or components of a

that n ew optimization technology was needed, as

GEM compiler are the front end, the optimizer, the

wel l as a new strategy for leveraging investments in

code generator, and the compiler shell. The logical

compiler technology across an increasing n u mber

division of GEM components and the range of GEM

of hardware platforms.

support is shown i n Figure l . Note that the bast is

This paper presents a tech nical description of

the computer on which the compiler runs, a nd the

the G EM compiler technology that Digital uses to

target is the compu ter o n which the generated

generate compiler products for a wide range of

object runs.

hardware and software combinations. We begin

The fro nt end performs lexical ana lysis and pars

with an explanation of the GE!YI strategy of leverag

ing of the source program . The primary outpu ts are

ing investments by using portable, modu lar soft

in termediate language (I L) graphs and sym bol

ware components to build compiler products. The

tables, which are both standardized. I n an IL graph,

bulk of the paper describes the GEM optim izer and

each node, referred to as a tuple, represents an

code generator technologies, with a focus on how

operation. Fron t ends fo r all source languages

t hey address challenges posed by the Alpha AXP
architecture.1 We then move to a discussion of com

translate to the single sta ndard IL. All l anguage-spe

p i ler engineering and conclude with an overview

knowledge of the source la nguage is communi

of some planned enhancements to the software.

cated in the IL or through call backs to the front end .
Knowledge of the target hardware is represented in

GEM Compiler Architecture

cific code is encapsu lated in the front end . All

tables and in a minimal amount of conditional code.

Because of the m any hardware platforms available ,

The optimizer transforms the

!L

generated by the

often with m u ltiple operating systems and a variety

front end into a semantical ly equ ivalent form that

of languages offeree! on those platform s, bui lding a
compiler from scratch for each combination is no

wil l execute faster on the target machine. A signifi
cant tech nical ach ievement is that a single opti

longer feasible. To simpl ify the engineering of

m izer is used for a l l languages and target platforms.

Digital Tee/m ica/ journal

Vol. 4 No. 4

Special Issue 19')2

121

Alpha AXP Architecture and Systems

FRONT E N D

SHELL
HOST
OPERATING SYSTEM

LANGUAGES

Open VMS
OSF/1
ULTRIX
Windows NT

Ada
BLISS

c

C++
COBOL
Fortran
Pascal
PU1
Opal

CODE G E N E RATOR

HOST C P U

Alpha AXP
MIPS
VAX

TARGET
OPERATING SYSTEM

TARGET CPU

OpenVMS
OSF/1
ULTRIX
Windows NT

Alpha A X P

MIPS
Others

OPTIMIZER

Figure 1

GEil!f Components and Supported CPUs, Operating Systems, and Languages

The code generator translates t he J L into a l ist of
code cells, each of wlli c h represents one m achine

o f a program , certain information about other rele
vant parts of the source program can be usefu l .

instruction for the target hardware. Virtu a l l y all the

Figure 2 i l l ustrates t he overa l l process o f compil

target machine instruction-specific code is encap

i ng a progra m . Since G E.vl compi lers include i nter

su l a ted in the code generator.

procedural optim izations, as much of the program

The shell is a collection of common com pil er

as possible should be presented to the optim izer at

fu nctions such as l isting generators, object fi le

t he same t i me. For this reason, GE.vl compi lers

emitters, and command l ine processors. Basically,

a l low the user to process m u l t iple sou rce files in

the shell is a portable in terface to the exte rn a l envi

s i ngle com p i la t i o n . The fro nt end parses these

a

ronment in w h i ch the com p i ler is used . This in ter

source files and constructs the symbol table and a

face a l lows the

compact fo rm of I L i n memory before i nvok ing the

other components to

rema i n

independent of the operati ng syste m .
There are nu merous benefits t o t h i s modular
approach:
•

Addi n g a new feature to a c o m m o n component

Source language com patibi l ity is ensured a m o ng
a l l com p i lers that use the same front end .

•

phase a na lyzes the rou t i nes with in a c o m p i lation
u n i t to develop a call gra p h that shows which
rou tines

might

call

w h ich

other

rou t i nes.

lnterprocedural optimizations are appl ied to the
rou ti nes as a gro u p .
Next, the global o p t i m izer a n d the c o d e genera

new front end to b u i ld a compiler for a new lan

tor process each rou t i ne in a bottom-up order,

guage, or a new s h e l l to a l low the comp i le r to

resul ting in a translation of the program to code
cel ls that represent operations at machine l e ve l .

When a new language is added, it can be offered
quickly on many platforms.

•

phase is the first to operate on the program . This

Standard ized interfaces enable us to plug in a

run on a new host.
•

thus compi led is cal led a compilation u n i t .
The G EM back-end in terprocedu ral optim ization

enhances many products.
•

G E.vl back end. The portion of the user's program

When a new target CP
supported,

o r operating system is

many l anguages are im med iately

avai l able to that target.

Order ofProcessing
When compi ling a program, the overa l l order of pro

This bottom-up order is conven ient fo r certa in opti
m izations, as discussed in the Optimization section.
The first action of the gl oba l optimizer is to trans
late the rou t i n e 's II. from the compact form pro
vided by the front end to an expanded form used by
the o p t i m izer and the code generato r. Since only
o n e rou tine at a t i me is stored in expanded fo rm, a
m u c h larger data structu re can be used to store the
resu l ts of the o p t i mizer analysis. The expansion
from compact fo rm also expands cert a i n shorthand

cessing must be carefu l ly arranged so that each com

forms, which are conven ient for a fro nt end, into

ponent of t he compiler can see a large portion of the

exp l i c i t operations in the expanded II., much l i ke a

program at one time. When processing one portion

macro expansion fac i l i t y in a source language.

122

ViJI. 4 No. -1

.\jJecial lssue 19')1

D igital Technical jo urnal

The GEM Optimizing Compiler System

S O U R C E PROGRAM

FRONT E N D

•

1

I N T E R PROCEDURAL
OPTIMIZATION

GLOBAL
OPTIMIZATION

COMPILER S H E L L
A N D UTILITIES

SCAN N E R

1

PARS E R

S E M A N T I C PROCESSING

FILE 1/0 SUPPORT

SYMBOL TABLE
COMPACT INTERM EDIATE LANGUAGE

MESSAG I N G

CO M P I L E R D E B U G G I N G TOOLS
LOCATOR PACKAGE

COMMAND PROC E S S I N G

INLINING

L I S T I N G GENERATION

COMPI LATION O R D E RING

MEMORY MANAGEMENT

SYMBOL TABLE
COMPACT INTERM EDIATE LANGUAGE
I N T E R M E DIATE LANGUAGE EXPANSION
FLOW GRAPH R E DUCTION
LOOP U N ROLLING

COMMON S U B E XP R ESSION
CODE MOTION

VALUE AND CONSTANT PROPAGATION

STRENGTH R EDUCTION

TEST REPLACEMENT

!
CODE
G E N E R ATION

SPLIT LIFETIME ANALYSIS

SYMBOL TABLE
EXPANDED I N T E RM E �ATE LANGUAGE
CODE SELECTION

I NTERMEDIATE LANGUAGE SCHEDULING
REG ISTER HISTORY

REGISTER ALLOCATION

I NSTRUCTION
PROC E S S I N G

OBJECT MODULE
CONSTRUCTION

!

CODE E M I SS I O N

STORAGE ALLOCATION
SYMBOL TABLE
CODE CELLS
P E E PHOLI N G

!

C O D E SCHEDULING

BRANCH/JUMP R E SOLUTION

SYMBOL TABLE
CODE C E LLS

�

OBJECT MODULE

Figure 2

GEM Compiler Order ofProcessing

Once a l l the routines h ave been p rocessed by

m i zations and instruction sched u l ing, are per

the global opti mizer and the code generator, a

formed on this program descript i o n . Final ly, the

complete descript i o n of the program is available a t

optimized machine instructions are converted to

t h e machine instruction level. Certain machine

the appropriate object l anguage for the target oper

specific optimizations, such as peephole opti-

ating system .

D igital Technical jounwl

Vol. 4 No. 4

Special Issue 1992

1 23

Alpha AXP Architecture and Systems

Optimization

Out of concern for t he t i me required to compile

The GEM compiler system 's optimizer is state-of

large programs, GEM also establ ished the design

the-art and independent of the language and the tar

principle that the order of complexity as a function

get platform. The input to the optim izer is the I l

of the number of IL operations should be as close to

and symbol table for m u l t iple routi nes; the output

linear as possible.

is the semantical ly equivaJent Il and sym bol table,
both modified to ru n faster on the target platform.
GEM optimizations include i nterprocedural opti
mi zations, modern optimizations for superscalar
!USC architectu res such as the Alpha A.XP archi
tecture, plus a robust implementation of the classi
cal global optimizations. In addition , GEM's code
generator includes a nu mber of optimization fea
tures that help it produce extremely high local code
quality.

to a common I L and symbol table format, the
seman tics of these languages must be specified
precisely. Many optimizations require an exact
understanding of which symbols are being written
or read by operations in the IL, and wh ich opera
tions might affect the resu lts compu ted by other
The GEM team developed a detailed specification

Certain general design approaches or principles
appl ied

Since GEM compilers translate a l l source langu ages

operations.

Design Principles
were

Data Access Model and
Side Effects Interface

throughout

the

optim izer.

known as the data access model, which defines

For

those operations that can write to memory and

instance, choices had to be made in the design of

those that can read from memory. Each of these

the TL; the fron t end cou ld either provide a higher

memory-accessing operations can exp l icitly desig

level descrip t i o n of program features or rely on the

nate the symbol being accessed when it is known.

back end to derive the h igher-level description

The model a lso requ ires the fron t end to specify

from an analysis of a lower-level description. In

when symbols may be a liased with parameters and

cases where accurate, wel l-definecl algorithms for

when they may be pointer aliased. A poin ter

deriving those higher-level features exist, GEM

al iased sym bol may be accessed through p o inters

chooses to derive the descrip tions.

or other operations that do not specify the symbol

Describing source code loops is a key example of

that they access.

the implemen tation of this design principle. Most

The model can ind icate that the p o i n ter-al iased

source languages have expl icit syntax for wri t i ng

property is derivable, i . e . , a symbol is pointer

loops, and the front end could translate these lan

aliased only if an op eration that stores its address is

guages into a higher-level l l that designates those

present in the IL. A special !L operator marks such

loops. Instead, GEM uses a lower-level lL with primi

operations. When the derivation of this property is

tives su ch as condi tional branch and label opera

deferred , the optim izer can avoi d marking symbols

tors. The advantage of this approach is that C�EM

pointer a liased.

recognizes all loops, even those constructed with
GOTO statements.

The data access model provides a standard way
for a fron t end to indicate how ! L operations affect

A general design approach that emerged from

or depend upon symbols. However, some front

experience gained during the GEM project is the

ends can provide addit ional language-sp ecific d is

use of enabl ing o r expanding transformations to

crimination of operations that cannot be allowed to

suppon fundamental optimizations. Often, repre

interfere with one another. For example, a strongly

senting operations in the IL in a way that h ides cer
tain impl icit operations is a compact and efficient

typed language like Pascal m ay stipulate that an
assignment t o a floating-point target must refer to

approach. However at t imes, m aking these implici t

different storage than an integer read, even when

operations expl icit al lows a particular optim ization

the assignment target is accessed indirectly through

routine to operate on them . A good solution to this

a pointer.

problem is to i n itial l y represent the operat ions in

To represent language-specific rules while adher

the TL in the compact form. Then, before applying

ing to the philosophy that the back end should have

optim izations that could benefit from seeing the

no knowledge of the source language, GEM compil

implicit operations, apply expanding transforma

ers employ a unique interface with the fron t end,

tions to convert the !L into a longer form in which
all operations are explicit.

vides a set of procedures that GEM can cal l during

1 24

Vol. 4 No. 4

cal led the side effects in terface. The front end pro

Special Issue 19')2

Digital Technical journal

The GEM Optimizing Compiler System

optimization to a s k which IL operations have side

passed as argu ments, and the corresponding for

effects and which IL operations depend upon those

mals are described as not al iased with one another,
el i m i na t i ng the fo rmal parameters through inl ining

side effects.

d iscards valuable al ias information 2 '
Also. the order i n w hich inl i n i ng decisions are

Jnterprocedural Optimization
GEM's interprocedural optimization phase starts
by wal k i ng over the IL fo r all rou t ines to build
the call graph. The ca l l graph is a directed m u l ti
graph in which the nodes are rout ines, and the
edges are c a l l s from one rout i ne to another. The
graph is not a tree because recursion is allowed .
A

special

virtual

routine

node

represents

all

un known rout i nes that m ight c a l l o r b e cal led by
a rou tine in this compil ation.
GEM wa l ks the graph t o deter mine which local
symbols that are potent i a l targets of up- level access
are actua l ly referenced in a c a l led rout i n e . When
u p - level references do occur, GEM can also deter
mine the most efficient way to pass that context
from the rou tine that declares the variable to the
rou tine that references it.
On the same wa l k , GEM analyzes the use of sym
bols whose pointer-a l iased property i s derivable. If
operations that store the address of such a symbol
are present, then the symbol is m a rked as pointer
a l i ased . The fro nt end's ind icat i o n is also retained
so that this analysis can be repeated after address
storing operations are e l i minated.
The most significant i n terprocedural optim iza
tion that GEM performs is procedu re i n l i n i ng.
I n l i n i ng is a we l l - known method for reducing
procedure call overhead and for increasing the
effectiveness of global opti mizations by en larging
the scope of the operati ons seen at one time.
I n l ining has add i tional benefits o n superscalar
RISC architectures, l ike the Alpha AXP system,
because the optimization al lows the compiler to
schedule the instru ct ions of the two rout i nes
together.
G E M 's inl iner reviews a l l ca l ls in the cal l graph
and uses heuristic algorithms to dete rmine which
cal ls should be in l ined for maximum speed withou t
unreasonable increases in code size or compilation

made can be i mportant. In a chain of calls in which
A calls B and B calls C, the call from A to B m ight be
the most desirable i n l i n i ng candidate. However, if
the call from B to C is i n l ined first, the size of B may
increase, m a king it a less a t t ractive cand idate for
inl i n ing i n to A . Consequent ly, G EM uses its heuris
tics to preevaluate all cal ls and then orders the call s
by desirabi l ity. GEM i n l ines the most desirable can
d i date first, and then reeva luates the cal ler's prop
erties, possibly adj usting its position in the ordered
l ist.
I n many C programs, the address of a variable
(especially a struct) i s passed to a cal led rou tin e
that refers to the variable through a poi nter for
m a l parameter. After i n l i n ing, a symbo l 's address
i s stored in a pointer and ind irect references are
made through the pointer. Later, while optimizing
the rou t i ne, GEM's value propagation often e li m i
nates the pointer variable. Final ly, when one or
more poin ter-storing operations have been el i m i11a ted , G E M reeva l u a tes the pointer- a liased prop
erty of derivable local symbols, and the variable that
was once passed by address is n o lo nger p o i nter
al iased.
After i n terproced ural analysis, the rou t ines of the
user's program pass through the optimizer and
code generator one at a time. G EM 's i n terproced ural
phase chooses a bot tom-up rou ti ne order i n the cal l
graph. Except for recursive cycles, this order causes
GEM to generate the code for a cal led rout ine before

generating the cal ler's code. GEM takes advan tage of
this property by recording the scratch registers that
were actual ly used i n a called rou tine and ad j usting
register usage at its cal l sites.� GEM also determines
whether or not the cal led rout i n e requires a n argu
ment cou nt.

Jnte,rmediate Language Peepholes

time. The h e u ristics consider the nu mber and k i n d

GEM uses a peephole optim izer to im prove the I L In

o f IL operations, the number of symbols referenced,

addition to perform i ng the many obvious simplifi

and the kinds of optimization that wou ld l i kely be

cations such as m u l t i plyi ng by one or add i ng zero,

enabled or d isabled by in lining.

the

optimizer performs

other

tra n s formations.

When cal lers pass constants as actual parame

I n teger d ivision by a constant i s expanded i nto a

ters, better optim ization i s l i kely to resu l t from

mu ltiply by a reciprocal opera t i o n , which can be

i n l i n ing because the corresponding formal parame

efficiently implemented with a UMULH i nstruction.

ter w i l l have a known constant value. On the other

String operations o n short fi.:xed-length strings are

hand, when two sections of the same array are

converted i n to integer operations, to benefit from

Digital Technical journal

Vol. 4 No. 4

Special Issue 1992

1 25

Alpha AXP Architecture and Systems

various optimiza t ions performed only on scalars.

Base Binding

Also, i nteger m u ltiply operations by a constant are

On RlSC macl1incs, a variable in memory is refer

co nverted i nto a n equ ivalent set of shift and add or
subtract operations.

IL peepholes sometimes expose new opti miza
tion opportu n ities by expanding complex opera
t i o ns i n to more expl icit components. Also, other
optimizations such as value propagation may create
new opportu n i ties to apply peepholes. To take
advantage of these opportun ities, GEM compi lers
apply these IL peepholes m ultiple t imes du ring the
optimization of a rou tine.

analysis was l i mited largely to the e l i mination of
common subexpressions (CSEs), value propaga
tions, and code motions. We generalized the data
flow analysis technique to pe rform a wider variety
of optim izations includ ing field merging, i nduction
variable detection, dead store e limination, base
binding, and strength redu ction.
The process of detecting CSEs is d i vided i nto the
tasks of
Knowing when two expressions would com
pute the same results given i dentical inputs.
Within GEM compilers, such expressions are said
to be formally equivalent.

are

always

i d entical.

Such

expressions are said to be value equivalent. This
verification is accomplished by using the side
effects mechan ism .
•

Determining when an expression domi nates a
value equivalent expression.5 This information
guarantees that GEM will have comp u ted the
dominating expression whenever the dominated
expression is needed .

finding those places in the flow graph to which an
expression could be legal ly moved such that

•

address expressions are for m a l ly equivalent and

Induction Variables
Some of GEM 's most valuable optim izations require
the identification of i n d u ctive expressions and
induction variables, which is done during data-flow
analysis. An expressi o n i n a loop is indu ctive iJ its
value on a particular iteration is a linear function of
the trip count. The si mplest forms of indu ct ive
expressions are the cont rol variables of counted
loops. Expressions that are l i near functions of
induction variables are also inductive.
G E M 's implementation of data-flow analysis uses
a technique for determi n i ng what variables are
mod ified between basic blocks in the flow graph 6 7
The variables mod ified between a basic block ami
IDEF set. The mapping from variables to set ele

ments is clone using the side effects i n terface.
The algorithm for detecting i nduction variables
starts by presuming that a l l variables m o d ified i n
the loop are induction variable cancliclates. I t then
d isqualifies variables not redefined as a l i near func
t i o n of themselves with a coefficient equal to one.
The loops that GEM chooses to a nalyze have a loop
top that dom i nates a ll nodes within the loop. The
IDEF set fo r a loop top is exactly those variables that
are mod ified withi n the loop and thus se rves as the

Code motions introd uce tbe add itiona.l task of

•

the range of the hardware instruction offset field.
The CSE detection algorithm determi nes which

i ts domi nator are represented as a set cal led the

Verifying that the inpu ts to for mally equivalent
subexpressions

ters. GEM considers two add ress expressions for
mally equivalent if they d iffe r by an amount l ess than

algori thm moves the base register loads out of loops.

In previous Digital compilers, the use of d ata-flow

•

ister. To reduce the number of address loads, sets of
variables that are closely a l located share base regis

thus can share a base register, and the code motion

Dataflow Analysis

•

enced by loading the address into a base register and
then using indirect addressing through the base reg

The moved express i o n would be value equiva

starting value for the induction variable candidate
set, aga in using the side effects map p i ng of vari
ables to set elements. During the wal k of the loop,
whenever a d isqual ifying store is encountered, the
contents of the candid ate set are updated. Thus, at

lent to the original expressio n , and

the encl of the wal k, the remaining variables in the

The moved expression would execute less often

set are known to be true induction variabJes.

than the original expression.

Strength Reduction ofInduction Variables
GEM

Strength reduction is the process of replacing an

detects base- bin d i ng and strength- red uction candi

expensive operation with a less expensive opera

The

fol lowing

sections

describe

how

dates by subs titut ing sl ightly different equ ivalence

tion. The most basic example of strength reduction

functions.

o n i nduction is as follows:

1 26

Vol. 4 No. 4

Special issue 1992

Digital Tecl:micaljounwl

The GEM Optimizing Compiler System

•

If the original source program was
DO

20

I

PRINT

20

=

1 , 1 0

able V The a l l ocator can thus pack registers and

I *4

strength reduction would reduce the m u l t iply to an
acid as fol lows:
I

=

'

DO

•

=

=

I '
I '

scheduled after the redefinition of V i n I ine 3.

1 , 1 0
20

+

•

4

Note that the most com mon array references are
of the form A(I), which impl ies a m u l tipl ication of
yields a significant performance improvement i n

•

•

When a l ifetime of an induction variable con
t a i ns an equal number of stores and fetches, the
variable is used only to compute itsel f. Thus, the

To detect strength-reduction cand idates, we

whole l ifetime can be eliminated. This is cal led

redefine formal and value equivalence as fol l ows:

i n duction variable e limi nation .

Two inductive expressions are formal ly equiva
lent i f, given identical inputs, they d iffer o n ly by

•

GEM uses spl i t l ifet i me information to optimize
the flushing and reloading of register variables

a constant.

around rou tine cal ls.

Two forma l ly equivalent i ndu ctive expressions
are va lue equ ivalent if their inputs are value

•

GEM uses split l ifet i me information to determine
what variables are potential ly refe renced by

equivalent or are direct references to induction

exception hand lers.

variables.
Thus,

Any l ifetime with only stores is effectively
"dead ," and thus, the stores can be eliminated .

array-intensive compu tations.

•

A l ifetime that begins with a fetch is an uninitial
ized variable. GEM issues a diagnostic in such cases.

I by the stride of the array. Thus, strength reduction

•

V' and V' ' can be scheduled independently. For

example, the compu tation of Z in l ine 2 could be
I

PRINT
I '

memory more tightly.

4

20

V' and V ' ' can be assigned to different registers,

each with shorter l ifetimes than the original vari

strength-reduction

candidates

appear

•

Lifeti mes often need to be extended around loop

loop i nvariant, and two expressi o ns that are value

tops and loop bottoms. Split lifetime analysis has

equ iva lent can share a single strength reduction .

fu l l information in many cases in which the code

Code motion yields the ini tial value of the strength

generator's l ifetime computation must make

reduction.

pessimistic assu mptions. Thus, analyzed vari
ables are al located more efficien t l y inside loops.

Split Lifetime A nalysis
The GEM optimizer analyzes the usage o f certain
variables to determine if the stores and fetches of a
variable can be partitioned, i . e . , spli t , into disjoint
variables or lifetimes.
For example, consider the following program
segment:
1 :

v

X

*

y

2 :

z

z

*

v

The technique GEM uses for spli t l ifetime analysis
is based on the VAX Fortran SPLIT p hase 8 The tech
nique includes several extensions in t he areas of
induction variables, unselected variables (the origi
nal algorit h m analyzed only a fixed nu mber of vari
ables), and exception hand ling.

Code Generation
The GEM code generator matches code templates to

3 :

v

R

+

S

sections of I L trees.9 The code generator has a set of

4 :

T

T

+

V

approximately 600 code patterns and uses dynamic

The references to V can be d iv ided into two d is
j o int l ifetimes V' and V" without changing the
semantics of the program as in:
1 :

V '

X

*

y

2 :

z

Z

*

V '

3 :

V"

R

4 :

T

T

+
+

S
V"

programming to guide the selection of a least-cost
covering for each statement tree i n the IL graph pro
duced by the global optimizer.
Each code pattern specifies a set of i nterpretive
code-generation actions to be appl ied if the tem
plate is selected . The code-generation actions cre
ate temporaries, determine their l ifetimes, a l locate
registers and stack locations, and actually emit

V ' and V" can be treated as two completely

sequences

of i nstructions.

These actions

are

independent variables. T h is has several usefu l

appl ied during the fol lowing fou r separate code

applications.

generation passes over the IL graph for a procedure:

Digital Technicaljoumal

Vol. 4 No. 4

Special Issue 1992

1 27

Alpha AXP Arc hitecture and Systems

•

Contex t . Dur i ng t he con text pass, t h e code gen

of a va l u e c o m p u ted b y the template's generated

tempor ary variable. The i n fo r m a t i o n co m p u t ed

code.

i n c l udes t h e l i fe time, usage cou n ts, a mi a weight

An i n teger that represe n t s tbe cost of the code
generated by t his template.

d o m i n a to r- o rder

The resu l t modes are a n e n u m e r a t i o n of the dif

wa l k of the f low graph to i d e n t ify pote n t i a l

fe rent ways the com p i ler can represe n t a va l u e i n

code

gen erator

does

a

red u nd a n t loads of val ues t h a t cou ld b e ava i l able

t he m a c h i n e . 1 1 GEM c o m p il e r s use the fo l lowi ng

in registers.

res u l t modes:

Te m p n a m e . D u r i n g the temp name pass. the
code

ge nerato r

perfo r m s

re gister

pu ted d u ring the con text pass. Tile code genera
tor

also

uses

register

h i story

•

to

a l locate

t e m poraries t h a t hold tht· same va l u e in the same
register. I f su ccessfu l , t h i s action e l i m in a tes load
and m ove i n s t r u c t i o n s .

•

Boolea n , h>r low-bit, high-bit, a n d nonzero values

•

Fl ow, for a B o o l e a n re pres e nted as c o n t ro l flow

•

Re su l t modes fo r d i fferent sizes of i n teger l i terals

•

emits i n s t r u c t ions a n d code labels. The res u l t i n g

Res u l t modes for delaye(i ge n e r a ti o n of add ress
ing calculations

Co d e . D ur i ng the c o d e p a s s , t h e c o d e generator
code cel l s a re an i n ternal represe n t a t i o n at the

Sca l a r, for a value, negated va l u e . a nd c o m p l e
me nted v a l u e

a l location

u s i n g t h e l i fet i m e a n d w e i g h t i n fo r m a t i o n com

•

•

Register h i s tory. D u r i n g the register h istory pass,
the

•

A resu l t mode t h a t e n codes t h e representat i o n

erator creates data stru c t ures that describe each

sca led by loop d e p t h .
•

•

•

Re s u l t m o d e s i n d i c a t i ng t h a t o n l y a p a r t of a
va lue h a s been m a teria.l i zed, i . e . , t he low byt e , or

assembly code leve l . Each code ce l l c o n t ains a

that the m a t e r i a l ized v a l u e has used a lower-cost

s i n gle target m a c h i n e i ns t r u c t i o n . The code c e l l s

s o l u t i on

have s r e c i f i c registers a nd b o u n d offsets from
base re gist ers. References to labels in the code

As t e m p l a tes a re m a t c h e d to p o r t i o n s of t h e

s t re a m are in a symbo l i c fo r m , p e n d i n g fur t her

t r e e , e a c h n o d e is l a beled with a vector o f possible

IL

o p t i m i z a t i o n and f i n a l offs et ass i g n m e n t after

s o l u t i o n s . The vector i s i ndexed by resu l t mode,

i n s t r u c t i o n peephole o p t i m i zat i o n and in s t r u c

a n d the lowe s t - cost s o l u t i o n for e a c h resu l t m ode i s

t i o n sche(l u l i ng.

reconled o n the fo rward bo t t o m - u p w a l k . W h e n a
root node is encou ntere d , t h e lowes t - cost template

Template Matching and Result Modes

in i t s vector of s o l u t i o n s is chos e n . This choice t h e n

Code tem p l a t e e n u m e r a t i o n a n d selec t i o n o c c u rs

determi n e s the req u i red resu l t m ode a n d s o l u t i o n

d u ring t h e con text pass

for e a c h leaf of the p a t t e r n , re c u r s ively.

The e n u m e r a t i o n phase

scans IL nodes i n exe c u t io n o rder (bot to m - u p) and
l a b e l s each

n od e

with a lt e rn a tive

p:Hterns a n d

GEM Code Generator Action Language

costs. W h e n a root n o de s u c h as a store o r b ra n c h

The <; E.VJ code ge nerator uses a n d ex tends methods

t u p l e is reach e d , t h e lowest- cost t e m p late fo r t h a t

developed i n the BUSS c o m p i lers, the Carnegie

n ode i s se lected . The selec t i o n process i s t h e n

Mellon

a p p l ied re c ur sively to the leaves fo r the e n t i re

Co m p i ler

Proj e c t ,

t ree . 1 0

c o m p i ler. 1 !

1'

T h e lL t ree p a t tern of a code-generation template
consi s ts of t n_k i n d = = Q ) {
r -> n_f l a g s
I = MARK;
r -> n_f l a g s & = -L E F T ;
p t r- > x l_c d r ;

}

sented as an IL operator. The u nderlying problem is

The unopti mized code wou ld contain a load and

that the redu ndant loads and stores are not visible

an extract for each reference to n_kind or n_flags,

in this represenration. The first part of the solu tion

plus an insert and a store fo r the l a t ter two

involves expanding the field fetch or store into

references. The optimizer has el iminated two of the

1 $:

F ETC H X ( R E C O R D ,

[QJ,

[1 ] )

Fetch the #1
f r om memo r y

( L ow- o r d e r )

2$ :

FETCHX ( RECORD,

[ 1 J ,

[ 1 ] )

Fetch

the

#2

bi t

Fetch

the

L ongword

f rom

b i t

memo ry

(a) Pre-field merging JL
1 $ :

F ETCH( RECORD)

2$ :

E X TV ( 1 $ ,

[OJ,

3$ :

FETCH( RECDRD)

4$ :

EXTV ( 1 $,

[ 1 ],

[ 1 J ) ;

Extract

the

#1

f r om

the

Longword

[ 1 J ) ;

Fetch the longword
E x t r a c t t h e #2 f r om

the

Longword

(b) Post-field merging I L

Figure 3

132

Field Merging Example

Vol. 4 No. 4

Specia/ Jssue 1992

Digital Technical journal

The GEM Optimizing Compiler System

demo : :
BEQ
NOP
L$7 :
LDL
AND
BNE
MOV
BIS
MOV
AND
STL
L$9 :
LDL
BNE
L$5 :
RET

ptr,

L$5

RO, C R1 6 )
RO, 2 5 5 , R1
R1 , L$9
256, R 1 7
RO, R 1 7, R1 7
-51 3, R1
R17, R1 , R17
R17, C R16)
ptr,
ptr,

Branch Optimization Examples
Branch instructions can hurt the performance
of high-performance systems in several ways. In
addition to consuming space and causing time to be
expended while issuing the instruction, branches
can disrupt the hardware pipel ine. Also, branches
can inhibit optimizations such as code schedu l ing.
compiler system uses several

strategies to avoid branches in the IL and generated
code or to e1 i minate some bad effects of branch
instructions.
Some branches appear as part of a wel l-defined
pattern that need not inhibit opt i mizations.

G EM

uses special operators for these cases. A simple
example is the MAX fu nction. For Alpha

tems, MAX can be implemented using the

AXP

sys

CMOVx.x

instructions, avoid ing branch instructions entirely.
For other architectures, the m ain benefit is that the
branch does not appear in the
example

involves

IL.

the

A more compl i

so-cal led

" flow

Boolean" operators. Consider the C code example,
x

( p

=

&&

*p)

?

*y

:

*z;

which generates the fol lowing G EM
1 $
2$
3$
4$
5 $
6$
7$
8$
9$

:
:
:
:
:
:
:
:
:

LEFT
ba c k

place)

C i n

place )

1
1
1
1
1

0$
1 $
2$
3$
4$

:
:
:
:
:

SELELSEC9$)
FETCHC Z )
FETCH C 1 1 $)
S E L C C 7$ , 1 0$ ,
STORE C X , 1 3$ )

The

ANOSKIP

and

1 2$ )

LANDC

tuples implement the

conditional-AND operator. I f tuple 2 $ is false, tuples
4$ and 5$ are skipped, and the resu lt of the

is false. Otherwise , the

LANDC

LANDC

uses the resu lt of

tuple 5 $ .
Similarly, the

SELTH E N , SELELSE,

and

SELC

tuples

implement the select operator. If tup.le 6$ is true,
then tuples 8$ and 9 $ compute the result, and
tuples 1 1 $ and 12$ are skipped. I f tuple 6$ is fa lse,
then tuples 8$ and 9$ are skipped, and tuples 1 1 $
and 1 2 $ compute the result.
These operators al low programs to represent
branching code within the standard basic-block
framework but require branches in the generated
code, to avoid undesired side effects of the skipped
tuples. In some cases, though ,

G EM

can determine

that the skipped tuples have no side effects and then
converts the operators to an unconditional form,
a l lowing the generated code to be free of branches.
GEM

performs other transformations on the IL to

eliminate branches and thus enable further opti
J L:

FETCH CP)
NONZER0 ( 1 $ )
ANDSKI PC2$)
F ETCH C 1 $ )
NONZ ERO C4$)
LAND C C 3$, 5 $ )
S E LTH E N C 6 $ )
FETC H ( Y )
F ET C H C 8$ )

Digital Technical journal

C lear
Store

C i n

Machine Code with Field Merging

three loads, two of the three extracts, both inserts,

cated

MARK

8CR16)
L$7

and one of the two stores.

GEM

Set

n_f l a g s

R26

Figure 4

Therefore, the

Load n k i nd and
E x t r a ct n_k i n d

mizations. For example,
i f

Cexpr)

var

=

GEM

1 ;

transforms

e l se

va r

=

0;

into
var

=

Alpha

C C expr )
AXP

! =

0)

implementations typica lly incl ude a

branch prediction mechanism. Correctly predicted

Vol. 4 No. 4

Special issue 1992

1 33

Alpha AXP Architecture and Systems

branches take seve r a l cycles less t i m e than mispre

do

d ictecl branches. The fastest cond i t i o n a l branch is
one that i s correctly predicted not to be taken.

GEM

uses several strategies to arrange branches for best
perform ance .

G E M se lects an order fo r the basic blocks of a pro
gram that may d i ffer from the order in the sou rce

}

program. For each basic block that ends with an
u n cond itional branch,

G EM pl aces the target block

f (a[
[ i J =
f (a[
[ i -1 ]
f ( a [
[ i -2 ]
f ( a [
[ i -3J
le (i

i J
! =
0;
i-1 ]
=
0;
i -2]
=
0;
i -3]
= 0;
-= 4

b[ i J )

goto

Labe l ;

!=

b[i-1 ] )

goto

Labe l ;

1=

b[ i -2] )

goto

labe l ;

! =

b [ i -3 J )

goto

labe l ;

) ;

a n d one taken branch, whereas the origin a l code

S i m i l a rly, if a basic block within a loop ends with an

executed fou r fa l l- th rough branches and fou r taken

u n cond itional branch, a target block w i t h i n that

branches.

loop is placed next, if possi ble. For example,

Certain code patterns generate code that is l i ke l y
not to be execu ted. F o r example, when t h e com

return

piler bel ieves that a 1 6 - b i t value i n memory is apr ro

a[i J-b[ i J;

be naturally a l igned, but may be u n a l igned, i t gen

}

e rates the i nstructions shown i n Figure 5 to load

To e l i m i nate the u nconditional branch when the
loop i terates,

i
a
i
a
i
a
i
a
whi

T h is code executes four fa l l - t h rough branches

next, u n l ess that block has a l ready been placed.

w h i L e ( -- i > 0 ) {
i f ( a[ i J ! = b[i J )
a[i J = 0;

{

the v a l u e , given the a d d ress i n rO. The code r u n s

GEM transforms the pretested loop

q u i ckly fo r the a l igned c a s e , b e c a u s e the branch i s

i nto a posttested loop. Since the return statement i s

correctly pred icted to fal l through , b u r gets the cor
rect value fo r u n a l ignecl data , as wel l. A s i m i l a r code

outside the loop, t h e generated c o d e looks l i ke
i f

( -- i > 0 )
do {
i f (a[i J ! = b[i J )
a [ i J = 0;
} w h i l e ( -- i > 0 ) ;

l a be l :

return

pattern hand les stores.
goto

Compiler Engineering

labe l ;

E ngineering compilers for a large combination of
l a nguages and platforms requ ired a considerable
nu mber of i n n ovations i n the area of project engi

a[i J-b[i J ;

nee ring. I n this sectio n we describe some of the
project methods and tools

GEM can a lso u n ro l l l o op s ancl thus red uce the
n u m be r of times rhe branch back must be exe
c u ted . More i mportant,

GEM uses.

Opal Intermediate Language Compiler

G EM often a l lows opera

G E M compiler is to translate a pro

tions from different iterations to be scheduled

The task of a

together. Unrol l i ng by four transforms the above

gram presented by the fro nt end i n the for m of a n

loop i n to a cleanup loop and the main loop into

IL graph a n d symbol table i nto machine code. I n

code rhar resembles

t h e early stages of

3-i nst ruc t i on

i n l i ne
r1 ,
r1 ,
rO,

L d q_u
extwl
b lbs

sequence

i f

G E M deve lopment, no fro nt

a l i gned

( r0)
rO, r1
1 0$

20$ :
out-of - l i n e
1 0$ :

L d q_u
extwh
or
br

Figure 5

1 :)4

sequence
r
r
r
r

to

load

and

me r g e

28, 1 ( r0 )
28, rO, r28
1 , r28, r1
31 , 20$

Potential�y Unaligned Load Code

Vol. 4 No. 4

5jJecial lssue 1992

Digital Tech11icaljourual

Tbe GEM Optilnizing Cmnpiler System

ends existed to generate I L graphs ami symbol

but has a fron t end that comp i l es o n ly one program.

tables. To fi l l this requ irement, a syntactic speci

The KFOLD bu i lder scans the GEM operator signa

fic;J t i o n of t he IL and sym bol table was des igned

ture table and constructs a procedure that contains

and a n IL assembler c a l led Opal was b u i l t to com

a m an y-way conditional branch to select a case

p i l e this syntax. Opal uses GEM components such

based o n t h e IL operator specified i n the argu ment

as the shel l and thus supports a robust set of fea

l i s t . Each case fetches operand values from the

tures i nc l u d i ng

argument l ist, a p p l ies the operator, a nd returns the

l isting generation,

object

fi les,

include files, debug support, a nd language e d i tor

resul t . S ince most G EM I L tuples o p e rate o n seve r a l

d iagnostics.

data types, a d d i t i o n a l subcases m a y be based on the

Even with the ava i l ab i l ity of front ends, O p a l

operator type o r resu l t type. We have a l ready recov

remains a v i t a l project t o o l : i t a l lows G EM devel op

ered the investment in deve loping t he automatic

ers to exercise new fea t u res before fro n t - end sup

KFOLD b u i l d e r, a nd i t significa n t l y eases the task of

p o rt is ava i l able; fro n t - e n d devel o p e rs use O p a l to

retargeting G E M .

experiment with d ifferent IL alternatives; and the
Opa l syntax serves as the o u t p u t fo rmat of the JL
d u m per.

Conclusion
This p ap e r describes the current G EM compiler
system. However, a portable, o p t i m i zing compi ler

A ttribute and Operator Signature Tables

prov ides many opportu n i ties that we have not yet

G E M tables give a complete descrip t i o n of a l l GEM

explo i t e d . Some e n h ancements planned for fu ture

data structures, i nc l u d ing I L operators and symbol

versions are:

table nod es. The operator signature table contains
the operator type, resu lt type, nu mber of operands,
and

lega l operand

types fo r I L operators.

•

attribute tables describe each component in a node
includ ing locat i o n , abstract GEM data type, legal val

•

G EM

•

t a b l es and a u tomat i ca l ly the Opal c o m p i le r under

•

Loop transformations, to improve the use of the
memory hierarchy

u t i l i t y is a b l e to d u m p the a t t r i b u t e , and the G EM
i n tegr i t y checker is able to verify the stru cture.

Dependence a n a lysis, to enable some of the
fol lowing enhancements

specification, the attribute is described once in the
stands the syntax and semantics, the GEM d u m p

S u p p o rt fo r a d d i t io n a l architecture and operat
i ng system combinations

ues, node type fo r p o i n ters, and sp e c ia l p r i n t for
mats. When a new attribute is added to the

Addit ional I L operators and d a t a types, to sup
port more languages

The

•

Software pipel i n i ng, to i ncrease para l le l ism in
vectorizable loops

Automatic KFOLD Builder
The

G EM compiler needs to eval u a te constant

•

instru ction sched u l ing

expressions at comp i le t i me , wh ich is referred to as
constant fo l d i ng. G E M 's i ntermediate l a nguage has

•

the co m p i le-time and ru n - t i m e res u l t s must be
identical.
After writing our first, i ncomplete, handcrafted

The sched u l i ng of instru ctions into d ifferent
basic blocks

m any I L operators and data types. A constant folder
is thus a c o m p l icated routine w i t h m a ny cases, and

Better reordering of memory references d u ri ng

•

The relaxing of the l i near restriction on the
l i fetime model, i . e . , a l lowing ho les in register
l ifet i mes

constant fo lder, we searched for a method to au to

The GEM compiler syste m h a s met demand i ng

mate the process. No source language supported a l l

techn ical and time- to-ma rket goa ls. The system has

the operators and data types o f the GEM !L. The key

been success fu l ly retargeted and rehosted for the

insight was that there is one l a nguage in which I L

Alpha A X P and MIPS architectures and several oper

programs c a n be writ ten precisely a n d ters e l y: the

ating enviro n ments. GEM supports a wide r ange of

c; EM IL i t s e l f. S i n ce GEM a l ready embodies knowl

l anguages and prov ides h igh levels of optimization

JL

for each. The cu rrent version of G EM generates effi

The a u to m a t i c KFOLD bu i lder i s a special i zed

mentation is ro bust and flexible enough to support

edge of the code sequences to evaluate every
operator, no other enco d i ng is needed.

cient code for Alpha A X P systems, and t h e imple

G E.vl com p i ler that uses the standard GEM back end

Digital Technical journal

Vol. 4 No. 4

S[Jecial lssue

1992

future improvements.

1 35

Alpha AXP Architecture and Systems

Acknowledgments

12.

The authors wish to acknowledge the contribu

Publishing Co. , 1975).

tions of the fol lowing individuals to the design and
implementation

of

the

G EM

compilers:

Brender,

Griffin ,

Lucy

Hamnett,

Patsy

Koblenz, Dennis M u rphy,

Bob

Ron
Brian

Peterson,

13.

B . Leverett et a l . , "An Overview of the Pro
duction-Qual i ty Compi ler- Compi ler Project,"

Paul

Computer; vol . 13, no. 8 (August 1980): 38-49.

Winalski, Stan Wh itlock (Fortran), Bevin Brett
14.

(Ada), and Farokh Morshed (C).

W Wu l f et a l . , The Design of an Optimizing
Compiler ( New York, l\1Y: American E l sevier

R. Johnsson , "An Approach to G lobal Register
Al locatio n ,''

References
I.

R . Sites, e d . , Alpha Architecture Reference
Manual (Bur l i ngton , iVlA: D igital Press, 1992).

2.

K. Cooper, M. H a l l , and L. Torczon, "The Per
ils of Interprocedural Knowledge," Rice COMP

TR90-132 (1990).
3.

15.

thesis,

Carnegie-Me l l o n

R. Sethi a nd ). U l l m a n , "The Generation of
Optimal Code for Arithmetic Expressions,"

journal of the ACM, vol . 17, no. 4 (October,
1970): 715-728.

General Reference

K. Cooper, M. H a l l , and L. Torczon , " Unex
pected Side E ffects of I n l ine Substitu tio n : A
Case Study," TOPIAS ( March 1992): 2 2 - 32 .

4.

P h . D.

U n i versity, December 1975.

P Ank l a m et a l . ,

•

Engineering a Compiler ( Bedford,

MA: Digital Press, 1982).

F Chow, " Mini mizing Register Usage Penalty

at Procedure Cal l s," S!GPIA N '88 Conference

on Program ming Language Design and
Implementation (June 1988): 85-94.
5.

T. Lengauer and R. Tarjan, "A Fast Algorithm

for F i nd ing Dominators in a F lowgraph,"
TOPIAS, voJ . 1 , no. 1 (July 1979) : 121-141 .

6.

). Reif, " Symbol ic I n terpretation in Almost Lin
ear Time," Conference Records of the Fifth
ACIH

Symposium on Principles of Program
ming Languages (1978): 76-83.

7.

). Reif and R. Tarjan, "Symbolic Program Anal
ysis in Almost-Linear Time," SIAI'vl journal of

Computing, vol. 1 1 , n o . 1 (February 1981) :

81-93.
8.

K.

H a rris

and

S.

Hobbs,

" VAX

Fort ran,"

Optimization in Compilers, ed . , F Al len,

B . Rosen, and F Zad e k ( New York, NY : ACM
Press, forthcoming).

9.

R.

Cattel l ,

" Formalization and Automatic

Derivation of Code Generators,'' P h . D. thesis,
C MU-CS-78 -1 15,

Carnegie-Mel lo n University,

April 1978.
10.

A. Aho and S. Johnso n , " Optimal Code Gener
ation for Expression Trees," journal of the
AC!H, vol . 23, no. 3 ( J u ly 1976): 488-501.

11.

B . Leverett, " Register Allocation in Optim iz
ing Compilers," P h . D. thesis, CMU-CS-81-103,
Carnegie-Mel lon University, February 1981 .

1 36

Vol. 4 No. 4

SjJecial fssue 1')92

D igital Technical journal

Richard L. Sites
Anton Chernoff
Matthew B. Kirk
Maurice P. Marks
Scott G. Robinson

Binary Translation
Binary translation is a technique used to change an executable program for one
computer architecture and operating system into an executable program for a eli/
ferent computer architecture and operating system. Two binary translators are
among the migration tools available for Alpha A XP computers: VEST translates
Open VMS VAX binary images to Open VMS AXP images; mx translates ULTRIX MIPS
images to DEC OSF/1 AXP images. In both cases, translated code usual�)' runs on
Alpha AXP computers as fast orJaster than the original code runs on the original
l:lrchitecture. In contrast to other migration efforts in the industr)J, the VAX transla
tor reproduces subtle CISC behavior on a RJSC machine, and both open-ended trans
lators provide good petformance on c�ynamically modified programs. Alpha AXP
binary translators are important migration tools-hundreds of translated
Open VMS VAX and ULTRJX MIPS images currently run on Alpha AXP systems.

When D igital started to design the Alph a AX P archi

•

tecture in the fal l of 1988, the Alpha A)\.P team was
concerned about how to run existing VAX code a nd
soon- to-exist MIPS code on the new Alpha AXP com

•

cation must be ported by reb u i ld i ng , u s i ng native
compilers. For a single program written in a stan

M icrocoded emulator (e. g . , PDP-11 compatibil ity
mode in early VA,\: computers)

puters. u To take ful l advantage of the performance

capabil ity of a new computer architecture, an appl i

Software i n terpreter (e . g . , Insignia Solutions'
SoftPC)

•

Binary translator (e. g . , H u n ter System's XDOS)

•

Native compi ler

dard program m i ng language, this is a matte r of

A software i nterpreter is a program that reads

recompile and run. A complex software appl ication,

i nstructions of the o l d arc h i tecture one at a t i me,

however, can be b u i lt from h u ndreds of source

p erforming each operation i n turn o n a soft

p ieces using dozens of tools. A native port of such

ware-maintained version of the old architecture's

an appl ication is possible only when a l l parts of the

state. Interpreters

build path are runn i ng on the new architecture.

o n a wide variety of machines and can faithfu l ly

are

not very fast, b u t they run

Therefore, devisi ng a way to run a n existi ng (old
archi tectu re) bi nary version of a complex applica

FASTER

tion o n a new architecture is an important interim
measure. Such a technique a l lows a user to get

NATIVE
COMPILER

appl ications up and running immed i ately, with
minimal porting effort. Once a user's everyday envi
ron ment is establ ished , appl ications can be rebuilt
over time, using handwritten native code or par
tially native and partially old code.

SLOWER

Background
Several techn iques are used in the industry to r u n
the binary code o f an old archi tecture o n a new
archi tecture. Figure 1 shows fou r common tech
n iques, from slowest to fastest:

Digital Techuicaljourua/

Vol. 4 No. 4

BINARY
TRANSLATOR

!>jJecial lssue

1992

M I C ROCODED
E M U LATOR

SOFTWARE
I NT E R PRETER

Figure 1

Common Techniquesfor Running Old
Code on New Computers

1 37

Alpha AXP Architecture and Systems

reproduce the behavior of self-modi fying pro

also d i rectly or i n d i rectly i nvoke operat i ng system

grams, programs that branch to data, programs that

services. In simple environments with a single dom

branch to a checksum o f themselves, etc. Cachi ng
interpreters gain speed by retaining preclecocled

inant l ibrary, it can be sufficient to rew r i te that
I i brary in native code and to i nterpret user pro

forms of p reviously in terpretecl instruct i o ns.

grams, particu l a r l y user p rograms that actu a l l y

A m icrocoded emu lator operates similarly to a

spend most of their time in t h e I i brary. This strategy

software interpreter but usual ly with some key

is commonly used to ru n Windows and Macintosh

hardware assists t o decode the old i nstru ctions

programs under the UNIX opera t i ng syste m .

qu ickly and to hold hardware state i nfo rmation in

In m o re robust environmen ts, i t is n o t practical

registers of the m i c romach ine. An e m u lator is typi

to rewrite all the shared J ibraries by hand ; col lec

c a l ly faster than an i n terpreter but can run only o n

tions of dozens or even hundreds of i mages (such as

a specific m icrocoded n e w machine. This technique

typical VAX ALL-IN-1 systems) must be r u n i n the old

cannot be used to run existing code on a reduced

environment, with a n occasional excursion i nto the

instruction set computer (RJSC) mach ine, since ruse

n ative opera t i ng system. Over time, it is desirable to

architectures do not have a microcoded h a rdware

rebui l d some images using a native compiler while

layer u nderly i ng the visible machine archi tecture.

retain i ng other i mages as translated code, and to

A translated binary program is a sequence of

achieve i n teroperabil i ty between these old and

new-architecture i nstructions t h at reproduce the

new i mages. The i nterface between an old environ

behavior of an o ld-architecture program . Typi c a lly,

ment and a n ew one typical ly consists of "jacket''

much of the state information of the old machine is

rou t ines that receive a c a l l using o l d conventio ns

kept i n registers i n the new mach i ne . Translated

and data stru ctu res, reformat the parameters, p er

code fai thfu l ly reproduces the cal l ing standard ,

form a native cal l using new conventions and data

implicit state, i nstruction side effects, branch i ng

structu res, reformat the resu lt, and return.

flow, a nd other artiJacts of the o l d mach ine.

The Alpha ;\.,'\ P M igration Tools team considered

Transl ated programs can be m uch faster than

r u n ning old VAX binary programs on Alph a AX P

i n terpreters o r emulators, b u t slower than native

computers using a s i m p l e software i nterpreter, but
rejected this method because the p e rformance

compiled programs.
Translators

can

be

classified

as

either

(1)

woul d be too s l ow to be usefu l . We a lso rejected

bounded translation systems, i n which a l l the

the idea of using some for m of m icrocoded emula

i nstru ctions of the old p rogram must exist a t trans

tor. This technique wou ld compromise the perfor

l a te time and m ust be found and translated to new

mance of a n a tive Alpha AXP i mp lementation, and

i nstructions, 1 '5 or (2) o p en-ended translation sys

VAX compatibi l i ty would be nearly impossible to

tems, in which code may a l s o be d iscovered, cre

achieve without m icrocode, w h ich is i nconsistent

ated, or mod ified at exec u t i o n time. Bounded

with a high-speed ruse design.

systems usual ly require manual i n tervention to find
100 percent of the code; open-ended systems can
be fu l ly au tomatic.
To run exis t i ng VAX and MIPS p rograms, an open

We therefore turned to open-ended binary trans

lation. We were aware of the earlier Hew lett
Packard binary translator, but its s ingle-image HP
3000 input code l ooked much simpler to translate

ended system is absolu tely necessary For example,

than l a rge c o llections of hand-coded VAX assembly

some customer programs write l icense-check code

l anguage p rograms .G One member of the team

(VAX i n structions) to memory, and branch to that

(R. Sites) wrote a VAX-to-VAX binary translator in
October 1988 as proof-of-concept. The concept

code. A bounded system fails o n such programs.
A native-compiled p rogram is a sequence of new
architecture instructions produced by recompil ing
the program. Native-comp i led programs usu a l ly
use newer, faster cal l i ng conventions than old p ro
grams. With a we l l - tuned optimizing compiler,
n a tive-compiled programs can be substa n t ia l ly
faster than any of the other choices.

looked feasible, so we set the fol lowing ambitious
product goals:
1 . Open-ended (completely au tomatic) translation
of a lmost all user-mode appl ications from the
OpenVMS VA)( system to the OpenVMS AXP

system

Most large programs are not self-contained; they

2. Open-ended transl ation of a l most a l l user-mode

cal l l ibrary routines, windowi ng services, data

applications from the ULTRIX system to the DEC

bases, and tool kits, for example. These programs

OSF/1 system

Hi/. 4 No.

4

Special issue 1992

D igital Teclmical journal

Binary Translation

3. Run-time performance of translated code o n

To achieve these goals, the Alpha AXP M igration

Alpha AXP computers t h a t meets o r exceeds the

Tools team created two binary translators: VEST,

performance of the original code o n the original

which translates OpenVMS VAX binary i mages to
OpenVMS AXP images, and mx, which translates

architecture
4. Optional reproduction of subtle old-architecture

details, at the cost of run-time performance, e . g . ,
complex

i nstruction

set

compu ter

(CISC)

i nstruction atomicity for m u l ti threaded app l ica
t ions and exact arithmetic traps for sophi s t i
cated error hand lers

ULTRIX MIPS i mages to DEC OSF/1

A.."XP

i mages.

H owever, binary translation is only half the migra
tion process. As shown in Figure 2, the other half is
to b u i l d a run-time environment i n which to exe
cute the translated code. This second h a l f of the
process m u s t bridge any d i fferences between old
and new operating systems, cal l ing standards,

5. I f translation is not possible, generation of

expl icit messages that give reasons and specify
what source changes are necessary

d iscovered that the process of b u i l d i ng flow graphs
of the code and tracking data dependencies yielded

i nformation about source code bugs, p erfo r ma nce
bottlenecks, and dependencies on features not avail
able i n all Alpha A.."X P operating systems. This analy
sis information could be valuable to a source code
maintainer. Thus, we added one more product goal :
6 . Optional source analysis information

I

tio n , this part of the process must also include a
way to run old code that was not d iscovered (or clid
not exist) at translate t ime. The translated i m age

While we were creating the VA.'( translator, we

O L D B I NARY
IMAGE

exception hand l ing, etc. For open-ended transla

environment (TIE) and m x r run-time environment
support the VEST and mx translators, respectively,
by reproducing the o l d operati ng environments.
Each environment supports open-ended transla
tion by including a fal l back interpreter of old code,
and extensive r u n-time feedback to avoid u s i ng the
interpreter except for dynam ical ly created code.
Our design philosophy is to do everything feasible
to stay o u t of the i n terpreter, rather than to increase
the speed of the interpreter. This approach gives

OPTIONAL
INTERFACE
DESCRIPTIONS

I

TRAN S LATOR
(VEST/MX)

I
I
N EW BINARY I M A G E
• OLD DATA
• OLD CODE
•

NEW CODE

I
I

l

OPTIONAL
LISTING
AND E R ROR
MESSAGES

OPTIONAL
INTERFACE
DESC R I PTION

OPTIONAL
FLOW
GRAPHS

R U N · TIME
S U P PORT
(TIE/MX)

OTHER
TRANSLATED
IMAGES

OTHER
NATIVE
I MAGES

I
I

I
I

I

PROGRAM
LOADER

Figure 2
D igital Technical journal

Vol. 4 No. 4

Binary Translation ana Execution Process

Special lssue 1992

1 39

Alpha AXP Arc h i tecture and Systems

better performa nce over a wider range of programs

Code a n alysis c a n detect m a n y problems, i n c lud

than using pure i nterpreters or bounded transla

ing some that i n d i cate latent bugs in the source

tion systems.

i m age. VEST can detect, for exa mple, u n i n itial ized

The re ma inder of this paper d iscusses the two

variables, i m properly formed VAX CASE instruc

b inary translato r/ru n-time env ironment pairs avail

tio ns, stack depth mismatches along two different

ami

paths to the same code (the program expects data

mx/mxr. To establ ish a basis fo r the d iscussion, the

able

fo r Al pha

to be at a certain stack depth), i m properly formed

reader must

A.',(P

computers:

fo llowing terms:

returns from subrouti nes, and modifications to a

datum, al ignment, instruction ato m i c i ty, granular

VAX call frame. A latent bug in the source i m age

i t y,

understa nd

interlocked

update,

the

V E Sl/T I E

and

word

tearing.

Definitions of these terms appear i n the References
and Note section.-

should be fixed , si nce the translated i mage m ay
demonstrate i ncorrect behavior clue to that bug.
Analysis also detects the use of unsu pported
OpenVMS features inclu d i ng unsupported system

VEST: Translating a VAX Image
Tra nslating a VAX image involves two main steps:
ana lyzing VA.,'{ code and generating Alpha AXP code.
The tr:111slated i mages produced are OpenVMS AXP
i mages and may be run just l i ke native im ages .><
Translated i mages run with the assistance of the
translated i mage environ ment, ·wh ich is discussed
l a ter in this p a p e r. The V EST bi nary translator is
written in C++ and runs on VAX , M I PS , and Alpha
AX!' machi nes. The TIE is writ ten in the O penVi'viS
system program m i ng languages. HLISS and Alpha
assembler.

Some problems reported by VEST resul t from
code that is hackish in nature. For example, we
fou n d code that expects a call mask at an entry
point to be executed as a no-op i nstruction so that
the code preceding the subrou tine can simpl y exe
cute the call mask, rather than go through the over
head

of a

VAX jump

(J.MP)

i nstruct i o n .

VEST

reproduces the behavior of the VAX progra m, even
if this behavior is a resul t of luck.
A VEST-generated flow graph is d isplayed i n
F igure ) . Dashed J ines represent code paths fol
lowed if a conditio nal branch is taken. Solid l i nes

Analysis
To locate VAX code, V EST starts disassembl ing code
at known entry points and recursively traces the
progra m's flow of control . Entry points come from
main and global routi nes, debug symbol table
entries, and optional information files (including
run-time feedback from the TJ E) .
A s VEST traces the program, i t bu ilds a f low graph
that consists of basic blocks ( i . e . , straight - l i n e code
sequences) annotated with information derived
from parsing instructions. VEST then performs sev
eral analyses on the flow graph to propagate con
text information to each basic block and e l i minate
unnecessary

services. The source image m u st be mod ified to
eliminate the use of these features.

operations.

Context

information

i n d icate fall- through paths. A problem is high
l ighted by a wide, dashed p o i n ter whose bottom
end i n d i cates the basic block in wh ich the problem
was uncovered . Fu ll blocks show the path that
reveals the error; empty blocks show basic blocks
that are not in the error path. I n Figure 3. a path
exists by which register 3 (R3) may be used without
being set if the VA.,'< BNEQ (branch if the register
does not equal zero) instruction in the second basic
block is true the first time through the code
sequence.

Code Generation

includes condi t i o n code usage, register contents,

The VEST translator generates code by convert ing

stack depth, and a variety of other inform a t ion that

each VA.,'{ i nstruction in to zero or more Alpha AXP

al lows VEST to generate opti mized code.

instructions. The architecture m a p p i ng is straight

A n a lysis is importan t for achieving good perfor

forward because there are more Alpha AXP registers

mance. For example, no condition codes exist in

than VAX registers. The VAX architecture has only 1 5

the Alpha AXP architecture. Without ana lysis it

registers, wh ich a r e usec.l for both floating-point

would be necessary to compute condition codes

and i nteger operations. The Alpha A.,'
': .STO�l E r : -c : · � : 8
\ 'l h l
11 I E:-J t.lf'.l.oc

1 OH
I

I
I

I

;�.�
.

- --- -

�.

h l B �.ge
: ��"" . ' : . e_·:r.

hand lers look up the cal l stack fo r pointers to spe

: IJ •"1 ' ! )

cific VAX instructions.) The addresses of statica l ly
a l l ocated data i n the translated i m age are identical
to their VAX addresses. The image contains a VA.,'< -to
AJpha AXP address m a pping table for use d u ring
lookups and may contain an instruction atomicity
table, described in the VAX Jnstruction Guarantees
section.
Translated images use the OpenVMS VA,'< caU ing
standard . Native im ages use different conven tions,
but translated im ages i nteroperate with native or

(
Figure 3

transl ated shareable i mages. Automatic jacketing

)

services are provided in the TIE to convert calls
using one set of conventions into the other. In
many cases, jacketing services permit substi tution

VEST-generated Flow Graph Showing
Uninitialized Variable

of a nat ive shareable im age fo r a translated share
able image without mod ification. However, a jacket
rou t ine is sometimes required. For example, on
OpenVMS AXP systems, the translated FORTRAN
run-time l i b rary, FORRTL_TV, invokes the native

stack pointer, and R 1 5 is used to resolve PC-relative

Alpha AXP l i brary DEC $ F O R RTL for I/O-related sub

references. Floating-point operations are mapped

rou tine calls. D EC$FORRTL has a different interface

to FO through F 14.

than FORRTL has on an Op enVJVIS VAX system. For

The VAX architecture has condition codes that
may be referenced exp l icitly. I n transl ated images,
condition codes are mapped i nto R 2 2 and R23.

these cal ls, FORRTL_TV contains handwri tten jacket
rou tines.

Similar to the HP 3000 translator, R23 is used as a

Files Used

fast condition code register for posit ive/negative/

Translating an image requires only one file-a VAX

zero resu lts f' R22 contains a l l four condition code

executable image. Several optional files m a ke trans

b i ts and is calcu l ated only when necessary. Al l

lation more effective.

Digital Technical journal

Vol. 4 No. 4

Special Issue

1992

141

Alpha AXP Architecture and Systems

1 . Im age information fi les ( I I Fs). VEST au tomati

c:l l ly c reates JJFs to provide information about
shareable im age interfaces. The information
incl udes the add resses of entry points, names of
routines, and resource util izatio n.
2 . Symbol information files (SIFs). VEST a u tomati

ca lly generates SIFs to control the g l obal symbol
table in a transla ted shared l i brary, faci l itating
interoperation between translated and nat ive
images.
3

Hand-edi ted information files (HIFs) . The ·rtE
auto m a t ica l ly generates HIFs, which m ay be
hand-edited to supply information that VEST can
nor cleu uce. HJFs contain d i rectives to tel l VEST
about undetected entry points, to force it to
change specific assumptions about an image (l ur
ing t ranslation, a nd to provide known in terface
properties to be propagated into an IIF .

described i n deta i l in the section Speci al
Considerations for Instruction Atom icity.

Untranslatable Images
Some characteristics make OpenVMS VAX im ages
un translat able, i n c l u d i ng:
•

Exception handler issues. Images that depend
on exami ning the VAX processor status lo ngworcl
(I'SL) du ring exception hand l ing m us t be modi
fied , because the VAX PSL is not ava i lable within
exception hand lers.

•

Direct reference to undocumented system ser
v ices. Some software contains refe rences to
unsupported and undo cumen ted system ser
v ices. such as an in ternal-to-VJ'v!S service, which
parses i mage symbol tables. VEST high l ights
these references.

•

Exact VA,'( memory ma nagement requi rements.
Images that depend on exact VAX memory m an
agement behavior do not fu nction properly and
must be modified. These i m ages include those
that depend on VAX page s ize or that expect
certain objects to be m apped to particular
add resses.

•

Image format. Programs that use i m ages as data
are not able to read OpenVJVIS AXP i mages wi th
out mod ificatio ns, because the im age fo r mats
are different.

VEST Performance Considerations
In evaluating translated code performance, we rec
ognized that there was a significant trade-off
between re rform ance and the accuracy of emu lat
ing the VAX architecture. VEST permits users to
select severa l architectu ral assumptions and opti
m izations, i ncluding:
•

•

D-float precisio n . The A l ph a AXP architecture
p rovides hardware support for D-float with only
53-bit mantissas, whereas the VAX archi tecture
provides 56-bit m a n t issas. The user may select
transl ation with either 53-bit h a rdware support
(faster) or 56-bit software support (slower).
AI ignment. Alpha A,'( P instructions support only

natura l ly a l igned l ongword (32-bit) and quad
word (64- bit) mem ory operations. Unal igned
me mory operations cause a l ignment fa u l ts,
wh ich are handkd transparen tly by software at
significa nt run-time expense. The user may
direct VEST to assume that data references are
unal igned whenever a l ignment information is
unavailable.
•

Instruction atomicity. Mu ltitasking and m u l t i
processing programs may depend on i nstruction
atomicity and memory operation characterist ics
similar to those of the VAX architecture. VEST
uses speci a l code sequences to p roduce exact
VAX memory characteristics. VEST a n d the TIE
cooperate tO ensure VAX instruction atomicity
when instructed to do so. This mechanism is

142

TIE Design Overview
The run-time translated image environment TIE
assists i n executing translated OpenVMS \1,\X im ages
under the OpenVMS AXP operating system. Figure 4
and Table I show the contents of the TIE.

Problems Solved at Run Time
Com pJications may occur when translated
OpenVMS VAX im ages are ru n u nder the OpenVMS
AXP operating system. This section discusses the
fo l lowing related topics: the fa i lure to find a l l code
du ring translation, VA,'< instru ction guaran tees,
instruction atomici ty, memory update, and preserv
ing VAX exceptions.

Failure to Find All Code during Translation
\'Vhen the VEST binary translator encounters a
branch or subroutine cal l to an u nknown destina
tion, VEST generates code to cal l one of the TIE
lookup rou tines. The lookup routines map a VAX

Vvl. 4 No. 4

Special lssuf! /'}')2

D igital Technical journal

Binary Translation

instruction address to a translated Alpha A.'\P code

I f t he target of the flow change is translated cod e ,

address. If an address mapping exists, then a trans

the i n terpreter ex its to t h i s c o d e . Otherwise, t h e

fe r to the translated code is performed. Otherwise,

i nterpreter continues t o in terpret t h e target.
Lookup operations that transfer control to the

the VAX interpreter execu tes the destination code .

the starti ng VA.'\ code

When t h e VAX i nterpreter encounters a flow o f con

i n terpreter a lso record

trol change, it checks for returns to translated code.

address in an HJF file. The VAX i mage can then be
retranslated with the HIF i nformation, resu l t i ng i n
a n image that runs faster.

TRANSLATED
MAIN A N D
SHAREABLE
IMAGES

JACKETING
I NTERFACE

Alpha AXP (nontranslated) rou t ines. The TIE sup
plies the required special aurojacketing processing

t

OPENVMS AXP

load time, each translated im age identifies its e l f to

EXCEPTION
HANDLING

SYSTEM
CALLBACKS

lookup rou t i nes. The TIE mai ntains a cache of trans

t

t

that a l lows i nteroperation between translated and
native routines with n o manual i ntervention. At

t

t

t

+

II

the TIE and supplies a m a p p i ng table used by the
l. ations to speed up the actual lookup processing.
Every translated image contains both the origi nal

VAX code and the corresponding Alpha AXP code.

TIE

\Vhen a translated image identifies itself, the TIE

SYSTEM
SERVICES
EMULATION

EXCEPTION
HANDLING

JACKETING
INTERFACE

VAX
INTE R P R ETER

Lookup routi nes are also used to cal l nat ive

NATIVE
IMAGES

marks i ts original VAX add resses with the page pro
tection cal led fault on execute (FOE). An Alpha A.'\ P

t

processor that attempts to execute an instruction
on one of these pages generates an access violation

VAX STATE
MANAGER

.._j L

fau l t . This faul t is processed by a TIE con d i t i o n han
d ler to convert the FOE page pro tection into an
appropriate destination address lookup operati o n .

COMPLEX
INSTRUCTIONS

F o r example, t h e F O E m ight occur when a trans
Jared rou t i ne returns to its cal ler. If the cal ler was
i n terpreted , then i t s return address is a VAX code
address instead of a trans lated VA.'\ (Alpha AXP

Figure 4

Table 1

code) address. The Alpha A.'\ P processor attempts

VEST Run- time Environm.ent

TI E Contents

VAX-to-Aipha AXP Address M apping
(VAX State Manager)

Used to find computed destinations and other cases
where VEST did not f i n d the original VAX code. Each
translated i mage has a mapping table i ncluded.

VAX I nstruction Atomicity Controller
(VAX State Manager)

Ach ieves VAX i nstruction atom icity for asynchronous
events. This allows data sharing between the single
asynchronous execution context (AST) provided by
OpenVMS and non-AST level routines.

VAX I n struction I nterpreter

Executes VAX i nstructions not found by VEST.

VAX Complex I nstructions

Some VAX instru ctions do not have code generated i n - l i ne
by VEST. Those instru ctions are processed i n the TIE.
Examples are MOVC3 and MOVC5 that move byte strings.

OpenVMS VAX Exception Processing

Certain aspects of OpenVMS AXP exception processing
are necessarily d ifferent from OpenVMS VAX. For
example, the VAX computers have two scratch registers,
but Alpha AXP computers have 1 5. Translated condition
handlers are passed the VAX equivalents.

Routines for Differences between OpenVMS
VAX and Open VMS AXP System Services

Some operating system i nterfaces were rearch itected.
The TI E intervenes to make the d ifferences transparent.

Digital Tee/mica! journal

Vol.

4 No.

4

Special Issue 1992

1 4 :)

Alpha AXP Architecture and Systems

to execute the VAX code and generates a FOE cond i

u nder lying ru se instructions manip u late fou r or

t i o n . 'T'he T I E condition hand ler converts this i n to a

eight bytes a t a time. F i n a l ly, VEST/TIE can provide

J .VI P lookup opera t i o n .

exact memory read-write ordering and arithmetic
exceptions, e . g . , overflow. A l l these provisions are

VAX Instruction Guarantees

I nstruction guaran

optional and require extra execu tion t i m e .

tees arc characteristics of a compu ter arch i tecture

Tahles 2 a n d 3 show t h e visibi l i ty d i ffe rences

that are i n herent to instructions execu ted on that

bet ween various guarantees on VAX and AJpha AXP

archi tecture. For example, on a VAX compu ter, if

systems as wel l as for translated VA)( programs.

i nstruction l writes data to memory and t hen
instruction 2 writes data to memory, a second pro

Special Considerations fur Instruction A tom icity

cessor must not see the write from instruction 2

The VA X architectu re req ui res that in terrupted

before the write from instruction l. This p roperty

instructions complete or appea r never to have

is cal led strict read-write ordering.

started. Since translation is a process of converting

The VES'I/TfE pair can provide the i ll u s i o n that a

one VAX instru ction to potent i a l l y many Al pha AXP

single CISC instruction is executed in its entirety,

instructions, run-time processing m u s t achieve this

even though the unde rlying translation is a series

guarantee of inst ruction atomicity. Hence, a VAX

of ruse instructions. VEST/fi E ca n also prov ide t he

i nstruction ato m i c i t y control ler (lAC) was created

i J J usion of t wo processors updating ad j acen t mem

to manipulate AJpha AXP state to a n equ ivalent

ory hytcs without inte r ference, even though the

VAX state. \Vhen a translated async h ronous event

Ta ble 2

Single Processor G u a ra ntees
Single Processor Guarantees Cha racterized by What an Observer Sees
o n the Same Processor That Executes the Data Change

Topic

VAX

Tra n slated VAX

N ative Alpha AXP

I nstruction
Atomicity

An entire
VAX instruction

An entire translated
VAX instruction with
/PRESERVE=INSTRUCTION
_ATOMICITY and TI E's
instruction atomicity
control ler, else a single
Alpha AXP instruction

A si ngle Alpha AXP
instruction

Ta b l e

3

Mu ltiple Processor Gua rantees
M u l tiple Processor Guarantees Characterized by What a n Observer
on a Different Processor Sees versus the One Executing the Data Change

Topic

VAX

Tra nslated VAX

Nat ive Alpha AXP

Byte Gran ul arity

Yes, hardware
ensu res this

Yes, with
/PRESERVE=M EMORY
ATO MICITY
-

Yes, via LDx_L,
merge, STx_C
sequence

I nterlocked U pdate

Yes, for aligned
dat u m using interlock
i nstructions

Yes, for aligned dat u m
using VAX interlock
i nstructions

Yes, v i a LDx_L,
mod ify, STx_C
sequence

Word Tearing

Aligned longword
writes change a l l
bytes at once

Aligned longword o r
quadword writes
change all bytes
at once

Aligned longword o r
quadword writes
change a l l bytes
at once

Other writes are
al lowed to change
one byte at a time

1 44

Vol. 4 No. 4

Special Issue 1992

Digital Teclmical jom"Tial

Binary Translation

processing rou tine is called, the lAC is invoked. The

access to shared memory. Lo ngword- size upd ates

lAC examines the Alpha A,'(}' instruction stream and

to al igned locations are performed using nor

either backs up the interrupted program counter to

m a l load/store instructions to ensure longword

restart at the equivalent VAX instruction boundary

granularity.

or executes the remaining instructions to t he next

Many mu ltiprocessing VAX programs depend

bou ndary. Many VAX programs do not require this

on byte granularity for memory update. VEST

guarantee to operate correct ly, so VEST emits code

generates byte-granular code

that is VA,'\ instruction atomic only if the qual ifier

/PR.ESERVE=M EMORY_ATOMlCITY i s specified when

if the condition

/PRESERVE=INSTRUCTION_ATOMlCITY is specified

translating an image. In addition, VEST generates

when translating an image.

strict read-write ordering code if the qualifier

VEST-generated code consists of fou r sections
that are detected by the lAC. These sections have
the following fu nctions:
•

Get operands to temporary registers

•

Operate on these temporary registers

•

Atomica l ly update VAX resu lts that could gener
ate side effects (i.e . , an exception or interlocked
access)

•

/PRESERVE=READ_WRITE_OR.DERJNG

is

specified

when translating an image.

Preserving VAX Exceptions

Alpha AXP i nstruc

tions do not have the same exception characteris
tics as VAX instruct ions. For instance, an arithmetic
faul t i s imprecise, i . e . , not synchronous with the
instruction that caused it. The Alpha A.,'\.P hardware
generates an arithmetic fau l t that gets mapped
i n to an OpenVMS AXP high-performance arith

Perform any updates that cannot generate side

metic (HPARJTH) exception. To retain compati

effects (e.g. , register updates)

bility with VA,'\ condition hand lers, the TIE maps

The VAX i nterpreter achieves VA,'\ i nstruction

call ing a translated condition hand ler. Most VAX

atomicity by using the atomic move, register to
memory

(AMOVRM)

instruction.

The AMOVRM

instruction is implemented in privileged archi
tecture library (PAL) subroutines and updates a
contiguous region of memory containing VAX
state without being i nterrupted. At the begin
ning of each interpreted VAX instruction, a read and
set flag (RS) instruction sets a flag that is c leared
when

an

interrupt

occurs

on

the processor.

HPARJTH into a corresponding VA,'\ exception when
languages

do

not

For those that do,

requ ire

precise

exceptions.

l i ke BASIC, VEST generates

the necessary t rap barrier (TRAPB) instructions
if /PRESERVE=FLOATI NG_EXCEPTIONS is specified
when translating an image.

Open VMS AXP and
OpenVMS VAX Differences
Functional

Dzffe1-ences

Most

OpenVMS

AXP

AMOVRM tests the flag, and if set, performs the

system services are identical to their OpenVMS VAX

update and returns a success indication. If the flag

cou nterparts. Services that depend on a VAX- spe

is clear, the A.J\10VR.M instruc tion ind icates failure,

cific mechanism are changed fo r the Alpha AXP

and the i n terpreter reprocesses the interrupted

architecture. The TIE intervenes in such system ser

instruction.

vices to ensure the translated code sees the old
interface.
VAX instruction

For example, the declare change mode hand ler

atomicity ensures that an arithmetic instru ction

($ DCLCMH) system service establ ishes a handler for

does not have any partia l ly updated memory loca

VAX change mode to user (CHMU) instructions. The

tions, as v iewed from the processor on which that

hand ler is invoked as if i t were an interrupt service

Issues with Changing Memory

instruction is executed. In a m u l t iprocessing envi

ro u tine requ ired to use the VAX return from inter

ronment, inspection from another processor cou ld

rupt or exception (REI) instruction to return to the

resu lt in a perception of partial resu lts.

invoker's context. On OpenVMS AXP systems, the

Since an Alpha AXP processor accesses mem

handler is called as a normal procedure. To ensure

ory only in al igned longwords or quadwords, it

compatibility, the T I E inserts its own hand ler when

is therefore not byte granu lar. To achieve byte

call ing OpenVMS AX P $DCLCMH. When a CHMU is

granularity, VEST generates a load-locked/store

invoked on Alpha A.XP computers, the TIE hand ler

cond itional code sequence, which ensures that a

cal l s the hand ler of the translated image, using the

memory location is updated as if it were byte granu

same VAX-specific mechanisms that the hand ler

lar. This sequence is also used to ensure interlocked

expects.

D igital Tech11ica/ journal

Vol. 4 No. 4

Special Issue 1992

145

Alpha AXP Architecture and Systems

Exception Handling OpenVMS A..'( P exception
p rocessing is a l most identical to that rerformed in
the OpenVMS VA..'< system . The major difference is
that the VAX mechanism array needs to hold the
value of only two temporary registers, RO and R I ,
whereas the Alpha A."'\P mechanism array needs to
hold the value of 15 temporary registers, RO, R l , ami
R 16 through R28.
Complex Instructions Translati ng some VAX
instructions would require many Alpha AXP
instructions . Instead, VEST generates code that calls
a TJE subroutine. S u brou tines are i m p lemen ted in
two ways: ( 1 ) hand written nat ive emu l ation rou
tines, e.g., MOVC5, and (2) VEST- translated VAX emu
lation routines, e . g . , POLYH .
Together, VEST ami T I E can transl ate and run most
existing user-mode VAX binary im ages_ As shown in
Table 4, performance of translated VA.'\ programs
s l ightly exceeds the original go a l . Performance
depends heavily on the frequency of use of VAX fea
tures that are not present in Alpha AXP mach ines.

ULTRIX MIPS Translation
mx is the translator that converts lJITRIX M I PS pro
gra ms to DEC OSF/ 1 AXP programs. The mx project

Ta ble

4

sta rted after VEST was functional, and we took
advantage of the VEST common code base for much
of the analysis and Alpha AXP code assembly phases
of the translator. In fact, abou t half of the code i n
mx is compiled from t h e same source fi les a s those
used for VEST, with some arch itectural specifics
supp l ied by differing include fil es_ The code-shar
i ng aspects of C++ have proven qu i te val uable in
this regard_
mxr is the ru n-time support system for translated
programs. I t provides services simi Jar to TIE, emu
lating the liLTRIX M I PS environment on a DEC OSF/ 1
AXP system. mxr is written i n C + + , C , and Alpha
assem bler.

Challenges
Creating a translator for the ;\·l i PS R2000/R3000
architecture presented us with a host of new oppor
tunit ies, along witb some significant cha l lenges.
The basic structure of the mx translator is much
simpler than that of VEST. Both the source and
the target architectures are !USC: machines; there
fore, the two instruction sets have a considerable
s i m i larity. Many instructions translate one for one.
The ivll l'S architectu re has very few instruction side
effects or su btle a rchitectural details, a l though

Tra nslated VA X Performance, Norm a l ized to Native-compiled OpenVMS AXP Code

VAX Time
o n VAX 661 0
(83.3 M Hz)

Program

VEST
Tra nslated Time
o n DEC 7000 AXP
(167 MHz)*

Native Ti m e
on D E C 7000 AXP
(1 67 M Hz)

SPECmark89
_t

gee
expresso
spice2g6
dodue
nasa7
li
eqntott
matrix300
fpppp
tom catv

1 .9
3.1
2.8
2.9
4.4
2.7
3.3
8.8
3.8
5.3

2.7
1 .8
3.0
6.2
4.2
2.2
4.2
2.7
2.9

1 .0
1 .0
1 .0
1 .0
1 .0
1 .0
1 .0
1 .0
1 .0

Geometric Mean
(without gee)

3.8

3.1

1 .0

Notes:
The larger the number, t h e slower t h e performance. These performance numbers were measured on derated field test hardware a n d
software a t various t i m e s d u ring

1 992;

production results w i l l v a r y somewhat. T h e S P E C benchmarks a r e written in FORTRAN a n d C ;

n o conclusions should b e drawn about other c l asses o f programs written i n other languages.
"The DEC 7000 system was ru n n i n g at a derated speed compared to production DEC 7000 systems.
t Ti m i ng information for t h i s run is not available.

1 46

ViJI. 4 .Yo. 4

-�Jwcil ll lsslle

!<)'J.!

D igital Tecb11ical journal

Binary Translation

those that are present are particularly tricky.

architecture bas more than 32 registers, includ ing

Furthermore, the format of an executable program

the HI and LO registers used by the m u l t iply and

under the ULTRIX system collects a l l code in a single

d ivide instructions, and a floating-poi n t cond ition

contiguous segment and makes it easy for mx to

register, whose layout and contents do not corre

rel iably find close to 100 percent of the code in the

spond to the Alpha A..'\P floating-point cond i t ion

M I PS application. The system interfaces to the

register.

ULTRIX and DEC OSF/1 systems are similar enough
that most ULTRJX system ca l ls have fu nctional ly

piler techniques. To assign registers to 33 M IPS

identical counterparts under the DEC OSF/ l system.

resources (the 32 general registers plus one 64-bit

In mx, we assign registers using standard com

The chal lenges in mx stem from the fact that the

register to hold both HI and LO), certain registers

source architecture is a RJSC machine. For example,

are p ermanently mapped, and other M IPS registers

DEC OSF/1 A..'\P is a 64-bit compu ting environment,

are kept in either AXP registers or memory. The

i.e., al l pointers used to com mu n icate with the

M I PS argu ment-passing registers AO through A3 are

operating system are 64 bits wide. This environ

permanently assigned to Alpha AXP registers R 16

ment does not present a problem when the pointer

through R 19, which are the argument registers in

is passed in a register. However, when a pointer (or

the DEC OSF/ 1 AXP cal l ing standard. This correspon

a long data item, such as a f i le s ize) is passed in

dence simplifies the work needed when mxr must

memory, i t m ust be converted between the 32-bit

take arguments for a n UI.TRIX system cal l and pass

representation, used by the ULTRIX system, and the

them to a DEC OSF/1 system ca l l . Simi larly, the argu

64-bit A..'\ P representation , even when the seman

ment return registers VO and V 1 are mapped to the

tics of the operating system call are the same on

Alpha A..""XP argument return registers RO and R 1 . The

both systems.

return address registers and stack poi nter registers

A significant challenge is the fact that our users'

of the two machines are also mapped . M I PS RO is

expectations for performance of translated pro

mapped to Alpha AXP R31 , where both registers

grams are much higher than fo r VEST. Reas o ning

contain the same hard-wired zero value. We reserve

that the source and target mach ines are sim ilar,

Alpha AXP registers R22 through R24 as scratch reg

users also expect mx to achieve a translated pro

isters and also use them when in terfacing to mxr.

gram performance better than that of the source

We reserve Alpha A..'\P R 14 as a pointer to an mxr

program , since Alpha A..'\ P processors are faster.

com mu n ication area. F inal ly, we reserve three

Thus, as our performance goal , we set out to pro

more registers as scratch registers for use by the

duce a translated program that runs at about the

code generator.

same speed

as

the origina l program wou ld run on a

The rem aining 16 Alpha AXP registers are avail

MIPS R4000 machine with a 100-megahertz (MHz)

able to be assigned to the remaining 23 tviiPS

internal clock rate.

resources. After the code is analyzed and we have
register usage information, the 16 most frequently

Mapping the Architectures

used MIPS registers get mapped to the remai ning 16

At first glance, it appears that we could simply

Alpha AXP registers, and the remaining registers are

assign each MIPS register to a corresponding Alpha

assigned to memory slots in the m..'(r com mu nica

AXP register, because each machine has 32 general

tion area. When a M IPS basic block uses one of the

purpose registers. The translated code would t hen

slotted registers, mx assigns it to one of the scratch

have two scratch registers, s i nce t he MIPS architec

registers. If the first reference reads the old con

ture does not a l low user-level programs to use reg

tents of the register, m x generates a load instruc

isters KO and K l , wh ich are reserved for the

t ion from the com m u nications area. If the value of
the MIPS resource changes in the basic block, the

operating system kernel.
Unfortunately, translation requires more than

scratch register is stored in the com m u n ication

two scratch registers. The Alpha AXP architecture

area before the end of the block. As in most compil

does not have byte or halfword (16 -bit) loads or

ers, if we run out of registers, a spill a lgorithm

stores, and

the code sequences for perform

i ng these operations require fou r or five scratch

chooses a value to save in the com mun ication area
and frees up a register.

registers. Furthermore, mx requ ires a base register

Alpha A..'{P integer registers are 64 bits wide,

to locate mxr without having to load a 64-bit

whereas M I PS registers are only 32 bits wide. We

add ress constant at each call. Final ly, the MI PS

chose to keep a l l 32-bit values in Alpha AXP i nteger

Digital Technical journal

Vol. 4 No. 4

Special issue 19')2

1 47

Alpha AXP Architecture and Systems

registers as sign-extended val ues, with the h igh 32

AXP registers, and w h ich MIPS resources are nor

bits equal to bit 3 1 . This approach occasiona l ly

m a l ly kept i n memory. This table allows mxr to find

requ ires mx to generate additional code to create

the MIPS resources at run time.

canonical 32-bit integer resu lts, but the 64-bit com
pare operations do not need to change the val ues
that they are comparing.
The floating-point architecture is more complex.
Each of the 32 M I PS floating-point registers i s 32 bits
wide. Only the even registers are used fo r single
precision , and a double-precision number is kept
in a n even-odd register pair. We map each pair of
M I PS floating-point registers onto a single 64-bit
Alpha AXP floating-p oint register. Also, one Alpha
AX P floating-point register represents the condition
code bit of the MlPS floating-point control register.
Thus, the m x code generator can use 14 scratch
registers. nL'< goes to considerable effort to find
paired loads and stores in the MIPS code stream, and
to merge them into one Alpha AXP floating-point
operation .
M I PS single-precision operations cause problems
with floating-point correspondence. Since on MIPS
machines, the single-precision nu mber is kept in
only the even register of the register pair, the even
and odd registers in a pair are independent when
single-precision (or integer) operations are done in

Finding Code
As with the VEST t ranslator, OL'C finds code by
starting a t entry points and recursively tracing
down the flow of contro l . mx finds entry points
u s i ng the executable file header, the symbol table

(if present), and feedback from mxr (if present).
Finally, nn performs a l inear scan of the entire
text section for u nexamined words. mx analyzes
any data that looks l ike plausible code but does not
connect

this data i n to the m a i n flow graph.

Plausible code consists of a series of va l id M IPS
instructions term inated by an u ncond itional trans
fer of contro l .
While finding code a n d connecting the basic
blocks into a flow graph, mx looks for the code
sequence that indicates a switch statement, i . e . , a
m u l t i-way branch, usually t h rough an element of a
table. mx finds the branch table and connects each
of the possible targets as successors of the branch .

Code A nalysis

the floating-point u n i t . On Alpha �'XP machi n es,

Our static analysis of hu ndreds of M IPS programs

computation m ust be done on a value extended to

i nd icates that only 10 instructions accoun t for

double for m a t in the whole 64-bit register. We

about 85 percent of al I code. These i nstructions are

defined two forms for values i n Alpha AX P float ing

LW, AD D I U , SW , NOP, ADDU, BEQ, ,JAL, BNE, LUI , and

point registers: computational form, in which com

SLL. The correspond i ng sequences of Alpha AXP

pu tation is done,

and canonical for m , which

code range from zero operation codes, or opcodes,

mimics the M IPS even and odd registers. If a M I PS

(for NOP, since the Alpha AXP architecture does not

program loads an even register and uses this regis

require NOPs anywhere in the code stream) to two

ter as a single-precision value, mx loads the value

opcodes (for SLL).

from memory to be used compu tationally. lf a M I PS

Code analysis for source programs is much more

program loads only an even register but does not

i mportant in mx than in VEST, because the cod ing

use this register in the basic block, mx puts the 32-

idioms

bit value into h a l f of the Alpha AXP floating-point

between the Alpha �'\ P and M I PS processors. The

register. This permits correct behavior i n the patho

simple technique of mapping each M I PS instruction

logical case where half of a floating-point number is

to a sequence of one or more Alpha AXP i nstruc

for

m a ny

common

operations

d iffer

loaded in one place, and the other h a l f is loaded i n

tions loses much of the context i n formation in the

some other basic block. If a register is used as a sin

original program .

gle-precision number in a basic block without first

For example, the idiom used to load a 32-bit

being loaded , the code generator inserts code to

constant i nto a register on MIPS machines is to gen

convert i t from canonical to compu tational float

erate a load upper i m med iate (LUI) opcode, placing

ing-point fo rm. If a single-precision value has been

a 16-bit constant in the high-order 16 bits of a

compu ted in a block and is l ive at the end of the

register. This operation is fol lowed by an OR i m me

block, i t i s converted to canonical for m .

d iate

mx inserts a register mapping table into t h e
translated

program t h a t indicates w h i c h MIPS

(ORJ)

opcode,

logical ly

ORing

a

16-bit

zero-extended value i n to t h e register. The LUI
corresponds exactly to the Alpha AXP load add ress

resources are statica l ly mapped to which Alpha

h igh (LDAH) opcode.

148

Vol. 4 No. 4

However, the Alpha �'
!. 4 No. 1

.\j;eciol lssue I'J'Jl

Digital Techuicaljournal

Einar).' Translation

system groups, and the respective r u n - t i me l ibrary

Due to extreme technica l obstacles, some classes
of p rograms w i l l never be supported by mx. We

groups, especial ly Matt LaPine, Larry Woodman,

decided not to translate programs that use p r ivi

H a i Huang, Dan Mu rphy, Nitin Karkhanis, Ray

leged opcodes or system calls o r that need to ru n

Lanza, Anton Verhulst , and Terry G rieb.
The

with superuser privi leges. In cases where the fi le
system hierarchy d iffers between the ULTRIX and
DEC OSF/ 1 AX!' systems, programs that expect files

Port i ng

ami

Performance

Engineeri ng

Group d i d extensive porting and testing of cus
tomer appl ications. The group members, especial ly

to be in particu l a r p laces or i n a particu l a r for m a t

Shamin Bhindarwala and Robi Al-Jaar, were sources

m a y fa i l . S i m i l arly, programs t h a t read /dev/kmem

of extremely valuable customer feedback. The

and ex pect to see an

ULTRIX

M I PS memory layout

Certain other c lasses o f programs are not cur
ren t l y supported ,

Engineering System Group u nder M i ke Greenfield
also made extensive early use of the transl ators and

fai l .

provided valuable feedback.

bu t are technica ! J y feasible.

The Alpha ''-"'< P Migration Tools team is rel a t ively

These i nclude big endian MIPS programs from non

s m a l l for the substan t i a l amou n t of work accom

Digital M I PS environments, programs that use

p l ished in the past two and o ne-h a l f years. Every

R4000 or R6000 i nstructions that are not presen t

person h as made several key contributions. In add i

on t h e R3000 model, programs that need to be

tion to the au thors of t h is paper, the team members

m u l t i processor safe, and programs that require cer

are: Kate Burleson ,

tain categories of precise exception behavior.

Darcy,

Peigi Cleminshaw, George

Frean ,

Bruce

Gordon,

Rick

Gorton, Kevi n Koch , Mark Herdeg, Giovanni Del la

Summary
Building successfu l

Catherine

turnkey binary

translators

requires hard work but not magic. We b u i l t two d if
feren t translators, VEST and m x . In both cases, the
ol(l a nd new environments are, by design, quite
simi l ar i n fundamental data types, memory address

Libera, Nikki M i rghafori, Srinivasan M u rari , J i m
Paradis, and Ashu tosh Roy.

References and Note
1 . R . Sites, e(l . , Alpba Architecture Reference

Manual (Bur l i ngton , MA: D igital Press, 1992).

ing, register and stack usage, and opera t i ng system
services. Translators between dissimilar arch itec
tures or operating systems are a d i fferen t m a t ter.

2. R .

Sites, ·'Alpha tL'< I' Architecture," Digital
Tec!Jnical.fournal, vol . 4, no. 4 ( 1992, this issue):

Translating the code m ight be a reasonably straight
forward task. However, e m u l a t i ng a run - t i me envi
ronment in which to execute the code m ight

19-34.
3. C. H un ter and J Ban n i ng, " DOS a t RISC," Byte

1"�resent insurmountable technical and business

Magazine (November 1989): 361- 368.

obstacles. Without captu ring the environment, an

4. Echo Logic, News Release (May 4, 1992).

instruction translator wou l d be of no use.
The idea of b inary translation is becom ing more

5. L. Wirbel, " DOS-to-UN I X Comp i ler," Electronic

Engineering Times (March 14, 1988): 83.

common in the compu ter industry, as various other
compan ies start on their transitions to 64-bit
arch itectures.

G. A. Bergh , K . Kei l m a n , D. Magenheimer, and
J M i l l er, ·'HP 3000 Emu lation on HP Precision
Arch itecture Computers," Hewlett-Packard.fo u r

Acknowledgments

nat (December 19H7).

Steve Hobbs origin a l l y suggested the binary trans la
tion path in the architecture task force d iscussions.
Nancy Kronenberg and Bob S u p n i k added critical
early support and l ater coord i na t i o n . Jud Leonard
set the e ngineering d i rection of doing carefu l static
translation once, instead of o n - the- f l y dynamic
transl ation at each execution. Butler Lampson
boosted mora le at a critical time. Jim Gettys has
a l so been a n i m portant and vocal supporter.
The success of the translators wou l d not have

7

Datum is the term used to refer to a piece
of i nformation that has an address ancl a size.
Alignment is the property of a datu m of size
2" bytes. This datum is a l igned i f its byte address
has n low-order zeros. A size or address not
meeting t h is constra i n t impl ies that the datum is
unal igned.
Instruction atomicity is the property of i nstruc

been possible without the enthusiastic support of

t i o n execution on single p rocessor systems

the OpenVMS t'-"'< P and DEC OSF/ 1 AXP operating

such that an i n terrupted instruction has been

Digital Technical journal

Vol. 4 No.

4

.�j;ecial ls.we 1992

I51

Alpha AXP Architecture and Systems

completed or has never started , i . e . , partial exe

i ndependent updates to the same a l igned datu m

cution of an instruction is never observed.

w i l l be consistent. This property causes serial
i zation of the i ndependent read-m odify-write

Granul arity is the property of memory writes on

sequences

m u l tiprocessor systems such that i ndependent

and

is

not

guaranteed

for

an

u n a l igned datu m .

writes to adjacent a l igned data produce consis
tent resu l ts. The terms byte, word , longword ,

Word tearing i s t h e p roperty o f a ] igned memory

quadword , and octaword granu l arity refer to

writes on m u l t iprocessor systems such t hat a

writ ing 1 - , 2-, 4 -, 8-, and 16 -byte size adjacent

reader i ndependent of the wri ter can see partial

data.

results of the write.

I nterlocked update is the property of memory

8. N. Kronenberg et a l . , " Porting OpenVMS from

updates (read-modify-write sequences) on m u l ti

VAX to Alpha AXP,'' Digital Technical jou rnal,

processor

vol . 4, no. 4 ( 1992, this issue): 1 1 1 - 120.

1 52

systems

such

that

s i m u l taneous

Vol.

4 No. 4

.)pecial

Issue f9'JJ

D igital Tecbnical journal

jeffrey A. Cofller
Zia Mohamed
Peter M. Spiro

Porting Digital's Database
Management Products to the
Alpha AXP Platform
Tbe cornerstone software cornponent of bigb-end production systems is a database
management �)!Stem. Digital bas successfully ported the DEC Rdb for Open VMS rela
tional database management system and the DEC DBMS for Open VJJS 11etwork
database management system to the Alpha AXP platform. Rdb and DBMS were per
haps tbe most complex layered products to be ported Tbe tigbt coupling oftbese two
products to the Open VMS VAX system made tbe port a challenging task. To avoid tbe
fu ture problem of integrating two source code bases, the porting team decided to
use a common code base and to overlap current VAX development with the Alpha
AXP port. The goal was to provide an easy migration path for software products to
the Alpha AXP platform.

D igital is one of a smal. l n u m ber of vemlors compet

transaction processing and information manage

i ng in the h igh-end, complex production systems

ment products such as C D D . ACMS, a n d DEC RALLY,

mar ker. App lications for this market support ind us

which i ntegrate with t he Rd b and DBMS systems.

tries such as bank ing, stock exchanges, teleco m m u

Database m anagement systems are among the

nications, and information services. The Alpha A X I'

most complex of all software produ cts. App l i ca

platform i s i deal l y su i ted t o meet the response

tions expect these systems to have 7 by 24 avai labil

time, throughput, and ava ilabil ity requirements of

i ty, soph isticated concurrency capabi l i ties, fast data

these appl i ca t i ons, since i t offers i n c reased perfo r

access, high-speed

mance w h i le m a i n t a i ni ng the superb avai labi l i ty

nisms, and l arge bu ffer pools. To provide such func

characteristics of VMScl uster systems.

tio n a l i ty,

the

Rdb

back u p and restore mecha
and

DBMS

products

make

Although h igh-end produ c t i o n systems involve a

extensive u s e of the O p e nVMS VA X system, the VA X

collection of software packages, the cornersto n e

run-time l ib raries, ami the HLI SS and VAX MACR0-32

software component is a database m a n agement

programming l anguages. The cu rrent release of the

system. D igita l offers two database management

product set uses more than 100 system services or

systems for hi gh-end commercial systems: DEC Rdb

run-time l ibrary cal l s. The two products u t il ize

for OpenVMS, a rel a t i o n a l database ma nagement

a lmost every BUSS BU I LT I N fu nct i o n , i . e . , a mach ine

system , a nd DEC D BMS for OpenVMS, a n e t work

specific fu nction c a l l that generates i n - l ine code.

(CODASYL) database m anagement system . D ig i t a l

Combined, Rdb and D BMS comprise m o re than 30

had to p o r t the D E C Rd b for OpenVMS VAX and D EC

d i fferent images. The produ cts run in elevated pro

DBMS for OpenVMS VAX database systems to the

cessing modes, both executive and kernel, and

Alpha AXP platform as early as possible to continue

include user-written system services.

to compete in this commercial arena. The resulting

Further compo u nd i ng the complexity of porti ng

pro d ucts a re the DEC Rd b for OpenVMS A X P and

the Rclb and DBMS software to the Alpha AXP p l a t

DEC DHMS for OpenVi'viS AXP systems. (Since these

fo rm is the fact that they are mature products; DBMS

two prod ucts for the Alpha AXP system are the

was released in 1981 , Rd b in 1984. Because various

same as those fo r t h e VAX system , hereafter, we

system capabi l it ies did not exist in t he early 1980s,

wil l refer to the products as Rclb and

DBM S . )

the two database m a nagement systems include

A d d i t i o n a l l y, both software p roducts dr ive many

code that is no lo nger requ ired. For exa mple. both

sales of Digita l 's OpenVMS operating system and

pro d u ct s have code to move bytes from one clara

Digital Technical ]oul'rwl

Vol.

4 No. 4

.\j;ccial lssue 1')<)2

1 53

Alpha A.,XP Architecture and Systems

t ype to another. Al so, d u r i ng i m age ru ndown , the

The DB:V1S prod uct also p rovi des l a nguage pre

products r e l y o n u n d o c u m e n ted, operatin g system

processors, an in teract ive query front end, a n d

behavioral

o t h e r software necessary to defi n e , create, a n d

patte rns

such

as

the

asynchronous

system trap (AST) d e l i very protocols. I n a d d i t i o n ,

mana ge d a t a in s i m p l e o r complex datab ases. I n

t h e Rd b software c o n t a i n s a m o d iJied version of the

c o n t rast to Rd b , DB,\>IS provi d es a CODASYL i n ter

Open VMS SORT rou t i n e .

face to the database.

R d b and DBMS were i n it i a l ly designed to ru n
only

on

the

OpenVMS

VAX

operating

syst e m .

Consequ e n t l y, both products heav i l y u t i l ize VAX 

Figure 1 shows the re l ationship of the Rclb ami
DBMS software products to the KODA da tabase
kernel

specific features for perfo rm ance gains. 1 F o r exam
ple, Rd b generates VAX m a c h i n e code rou t i nes as

Porting Policies

part of query exec u t i o n plans; the m a c h i n e code i s

I n i t i a l ly, we developed pol icies to gu ide our port to

carefu l l y generated for m a x i m u m execu t i o n effi

t h e Al pha A X L' pla tfo r m . These p o l i c i es,

ciency This t ight coup l i ng of Rdb a nd DBMS to t h e

app l i ed to t h e KO DA, Rcl b , and DB:VIS tea m s. were

OpenV,viS VA X system m a d e the port a cha l lengi ng

designed to s i m pl ify the port and to ease long- term

task.

m a i ntenance requ i re m e nts.

which

S i nce the Ope nVMS a n d BLISS groups were b u sy
with their own p o r t in g projects, we in the Database
Systems Group had to accomplish our port with l it

Common Source Code Base

t l e outside help. The task was noteworthy beca use,

O u r most i m p o r t a n t d e c i s i o n was to have a com

by necessity, the team had to port its p roduct set to

mon source code base. That is, we wantecl to have

the Al pha A X P p l a t fo r m earl ier than most of the

one set of source code that could be compiled a n d

other porting groups. At the same t i m e , Rdb and

r u n on e i t h e r a V A X or an AJ pha A X P system. A t the

DBMS were p er h aps the most c o m p lex l ayered

t i m e we began our port, the OpenVMS group was

products t h a t \VOll id be porte d . O u r goal was to

the o n l y other software group t ha t had s t a rted their

port these two products in a t i m e l y fash i o n , so that

port, a nd they had chosen to have two distinct code

Digital wou l d truly succeed in provi di ng an easy

bases. (The Open V.\>lS A X P p o r t i ng sched u le d ic

m igration p a t h fo r software products to the Alpha

tated the choice.) So w i t h respect to code base, the

AXP p latfo r m .

path we chose was u n tested. We al so decided to

In t h i s paper, w e first present a brief descrip tion

m a i n t a i n common c o m m a nd procedu res to com

of the archi tecture of the two database m a nage

pile, b u i l d , and l i n k , and common regress ion tests

ment system products. We next describe the gu id

between the VA X and Alpha t\.'C P systems.

i ng pol i cies we fo r m u l a ted to al low the port to

A p r i m ary reason for our code base decision was

proceed as effi c i e n t l y as poss i b l e . Then, we d o c u

that we d id not have the res o u rces to ma nage two

ment porting issues that we resolved fo r the two

d i ffer e n t code bases. A l s o , al though two d i vergent

prod ucts. F i n a l l y, we sum m a r ize our ex p e r i e n ces

code sou rces wou lcl have a l lowed fo r a stable code

re lated to this effo r t .

Product Architecture
Digi tal is u nique in the database i n d ustry in that we

DBMS

ROB

prov ide two d ifferent types of database m anage
ment systems that layer on top of the same database
kernel, whic h is called KODA. The KO DA kernel
p rovides journal i ng and recovery, locking, access

KODA DATABASE K E R N E L

methods ( e . g . , B - tree, hashing), rec o rd and page
management, and bu ffe r p o o l m a n agem e n t .
The Rd b software prov ides lang uage prep roces

O P E NVMS O P E R ATI N G SYSTEM

sors, an i n teractive query front e n d , a c a l l a ble i n ter
fa ce, cata logue m a nage m e n t , q u e ry optim izatio n ,
and rel.a t i o n a l operations s u c h a s j o i n , s e l e c t , a ncl
project. Rd b suppl ies a relational in terface to the

Figure

! 54

1

Re/ationsbijJ uf Rdb and DBMS
to the KODA Da tabase Kemel

database.

1'<11. 4 No. 4

.�jJecial lssue

1')')2

D igital Technical journal

Purting Digital's Database Nlcmagernent Products to the Alpha AXP Platform
base with which to begin the Alpha AXP port, the
group strongly wanted to avoid having to merge the

O n t he first pass, we decided to port the VA X code

two code bases at a future date. Consequ e n tl y,

clean u p some code for style, co nvention, and per

since our rrc l i m inary i nvestigation i n d i cated that a

formance, b u t basical ly, the Alpha A X P release

w i t hout designing any new a lgorithms. We d id

single code base was feasible and that we could

remains functional l y equ ivalent to the latest VAX

hide most o f the platform dependencies through

release.

the superb m acro capabi l i ty of the BLISS l anguage ,
we proceeded w i t h t he comm o n source code

Correct and Fast Code Execution

implementation . The si ngle code base a l lowed us to

We did not priori t i ze o u r effort to first, be correct,

b u i ld and release Alpha AXP and VAX versions of our

and seco n d , be fast. We decided that we must be

produ cts at the same time.

correct and fast on certain key issues. For example,
o n VAX systems, o u r argument -passing mechanism

Concurrent Releases

u t i l i zed the argument p oi n ter (AP). To m i n i m i ze

Our release schedu le compli ca ted the process of

code changes, we could have used the ARGPTR con

adhering to the si ngle code base pol.icy To meet the

struct in the BLISS cross compiler. However, ARGPTR

schedule, we had to overlap some of the Alpha A X P

is i nefficient and, therefore, not appropriate for our

port with our current VAX releases. That is, the sce

needs. Consequent ly, we ensured that our new

nario we fol l owed was NOT: work on a VAX release;

argu ment -passing

complete a l l necessary code changes; stabi l i ze the

though doing so was t ime-consu m i ng.

release; and then create a newer set of sou rces for
the Alpha A X P port. Rather, for the beginning por

design

was

efficient,

even

Minimizing Platform-specific Modules

tion of the Alpha AXP port, we a lso had to change

Code con d i t ional i za t i o n , i .e . , p ro d u c i ng separate

source code desti ned for a VAX release. Thus, if a

code for the VAX and the Alpha AXP platfo rms,

module had to be changed for the earlier VAX

requires various levels of code dupl ication. For

release and the same module had a l ready been

example, the process may requ ire the d u p l ication

ported for the Alpha AXP release, the engineer had

of a n entire module, routines within a module, o r

to propagate the code change to the Alpha AXP

certa i n l ines of c o d e within a routine. To minim ize

source code.

the amount of code d upl icated , we conditional ized

To m i n i m ize the effect of double code changes,

on the smal lest code segment possible, using a sen

we first worked on those m o d u les for the Alpha

si ble approach. For example, when forced i n to

AXP release that were reasonably stable in the cur

using cond itional code, we avo ided dupl icating

ren t VAX code stream . For example, the BLISS

modu les by choosing to keep w i t h i n a si ngle mod

R EQUIRE files that we use for data defi nitions were

u le. Ideal l y, we conditional ized just a few l i nes.

reasonably stable for the VAX release by the time the

Wherever possible, BLISS macros were mod ified to

Alpha AXP port began . The mod u les that did not

hide the code condition a lization.

change for the VA X release were also good candi
dates for helping us to avoid m a k i ng double code
changes. When we fina l ly began to port the bu l k of
the modu les, they were mostly stable ami , as a
resu lt, only bug fixes for the VAX release requ ired
that we manual ly mod i fy the same module for the
Alpha AX I' release.
Furthermore , once we began work on t he Alpha
AXP release, we needed the capabil ity of being able

to compile, l in k , and test on both the A l pha AXP
and VAX plat forms. So we had to m o dify our devel
opment environment to a llow us to identify the
code change session as either an Alpha tL'\P or a VAX

Rdb ls Rdb
\Ve wan ted our database management products to
" look and feel" the same on a n Alpha AXP system as
they did on a VAX sy�tem. So, to paraph rase from the

Open VMS operati ng system maxim, we wanted Rdb

to be Rdb ' That is, the p orted Rcl b should have the
same u t i l i t ies, the same data structures, the same
data defi n ition capabili t ies, the same data manipu
lation constructs, etc . , as the DEC Rdb for Oren VMS
VAX product. I ncorporated in this desire for same

ness was the fundamental p o i n t that we were not
going to change the on-disk structures. D llJYIS was

session.

ported with the same goa l in m ind.

No New Functionality

No Changes to On-disk Structures

The Alpha AX I' release of the database m a n agement

The KODA kernel stores records o n database pages.

system product set contains no new fu n c t i o n a l ity.

Digital Tee/mica/ journal

VfJ/. 4 No. 4

Special lss/le

1992

Unfortunately, the database page is not natur a l l y

Alpha A,'(P Architecture and Systems

fields and fields w i t h i n t h e
a l i g n i ng these
f i e l d s wou l d boost p e rfo rma n ce , to r e a l i gn all the
structu res on the d a t :� has e page would re quire the
d atabase ro be u nload e d and then reloaded. Cu rr ent
c u s to m ers c a n n o t affo rd the downtime n e e d e d to
pe r tc > rm t he conversion, so w e decided to m a i n t a i n
t h e same page/record structure. Furthermore, by
m a i n t ai n i ng the same o n-d is k structure for t h e VAX
and Alpha :\ X I' databases, we do n o t p r eclu de
fu t ure concu rrent access to the database i n a
m i xed-arc h i tectu re VNIScluster. Th us, our p res en t
d esign does n o t r e qu i re an u nl o a d/rel o ad opera
t i o n , si nce pe r fo r m i n g that action wo u l d he to o
m u ch ol an i m p ed i m en t to m igrati ng to the Alpha
AXl' p l a t form . Hmvever, w e do p l a n to i n ve s t igate
t h e p o te nt i a l p e r fo r m a n ce boost from a l i g ned
pages/records and, i f the gai n i s substa n t i a l , to offer
a l igned ; page header

records a r e not a l i g n ed . A l t hough

Var i a n t ed co de

•

Data a lignment and field resizing

•

Argu m e n t -passing

•

BUILTIN

•

VA X

•

The CALLG m e chan i sm and AP

•

VAX MACR0-32 modules

•

Message fi le support

mechanism

functions

testi ng
references

To simpl i fy co n d i t i o n a l code, we
a set of l i te r a ls , for ex a m pl e KO D $ K_VA X or
KOD $ K_ALPHA, that can be used in :1 l l our BLISS
modu les. We cou l d then use t hese l i terals to cond i
tional i ze code. The code example shown i n Fi gure

Varian ted Code

added

2 i l l ustrates the conditionalizing of the PROBE

some a l i g n m e n t solu t i o n . Note that t h is s e c t i o n

The PROBE i n s t r u ct i o n c hec ks the
re a d/wr i te access of a memory locat ion. On Al pha
AX I' systems, the i nstruction i s q u i te d i.ffe r e n t from
the co r re sp o n d i ng i nstruction on VAX systems.
H o we ve r BLISS easily handles this d ifference i n a
macro, wh ich a llows us to c hange the name and the
order of the argu ments, pass a rg u me n t s by value
i nstea d of r e fe r en ce and use a n offset i nstead of a
len g t h . By developing such a macro, t he actual
sou rce code d i d not h ave to change .
i n s t r u ct i o n .

rekrs o n l y to dat a stru ctur e s tied to o n - d i s k s t r uc
t u res. We did a l ign a l l i n - m e m o ry stru c t u res, and
we elaborate on t h is topic in

•

the next se c t i o n .

,

Porting Details
In t h i s sec t i o n we d e s c r i be a

general set of issues
the gro u ps involved
in p o r tin g rhe d a tabase m a n a ge m e n t system so ft
ware to the A l p h a AXP p l a t for m We t h en e x p l a in
some of t he more i n terest i ng issues and solutions

,

and sol u t i ons that ap plied t o a ll



.

a nd the c o m p i l e r on a VAX system woulcl prod uce

On t he first
im med iately mod ified a l l i n - m e m o ry data
s t r u c t u res so that they were n a t u ra l l y a l i gne d This
s t e p avo i de d i n cu rr i n g a s i gnifi ca n t p e r fo rm a n ce
p e n a l t y on rile A l p h a AXP pl at fo r m . In add it i o n ,
s i n c e n o si ngle A l p h a AXP i n s t r u ctions e x i s t that
cou ld be used ro easil y m a n ipu l a t e bytes o r words,
many of o u r i n- m e m o r y byte (8-bit) a n d word
( ! o -b i t) fields were changed to l o ngworcls (32 bits)
to reduce the object code size and improve

a nother set. Com m o n issues were:

perti) r m a n c e .

Data Alignment and Field Resizing

per tai n i ng to each group.

pas s , we

.

Com.mon Issues
A col l e c r i o n of general

porting issues a ppl ied to the
gro u p s . For exa m p l e , a l l

Rd h , DII\IS, ami KODA
gro ups nee ded

the capab i l i t y t o c o n cl i t io n a l ize

cocle i n a mo d u l e , so that the

com pi le r o n an A l pha

AX!' svstl'm wou ld p ro d u c e one set of objec t code,

$PROBER

( BASE,

% I F

LEN

=

4,

%THEN

(BUILTIN

%ELSE

( BU I LT I N
PROBER

0 )

( BASE,

LEN

-

1 ,

MAX

(MODE,

$ P R E V_ M O D E ) ) )

PROBER;

( %REF

( MO D E ) ,

%REF

( LEN ) ,

BAS E ) )

%,

Figure 2

I �6

=

P A L_ P R O B E R ;

P A L_P R O B E R

%F I

MODE

K O D $ K _A L P H A

Conditionalized PROBE Instruction

lfJ!. 4 No. 4

SjJecinl lssue 1992

Digital Tecbllica/ ]our11al

Porting Digital's Database klanagement Products to the Alpha AXP Pia {form

Once we a l igned the in-memory d a t a structures,

support l i b rary. Agai n , we used BLISS macros to

two groups of data structu res remained u n al igned :

s o l ve the proble m . Essen tial ly. o u r m a c ros catego

those t ied to the database root file, which records

rized the BUILT I Ns and then pe rformed the appro

database parameters such as assoc iated files and

p riate

da tabase settings, and the d atabase pages that actu

exa mple,

a l ly contain the data records. Since the database

betwee n t h e VA X and A l p h a AXP i m p lementations,

root file is relatively s m a l l (i.e . , less than 100 blocks

as i n d i cated by Figure 2.

expa nsio n ,
the

based

on

the

category.

For

PROBE BUILTIN d i ffe red marked ly

in size), it was a l igned also. Thus, the root file is
automatica l l y

re-created

in

a

conversion

that

occurs when upgra d i ng a database prod uct to sup
port both the Alpha AX P and VA X arch itectures.
Since th is convers i o n i nvariably takes place when
converting t o a newer vers i o n of either the Rdb or
the DBMS product, the a d d i t i o n a l rea l i gnment of
the root is a m inor a d d i t ional expense.
Thus far, we have not pu rsued any poten t i a l mod
ifications of the page data structu res, such as a l ign
ing them once they are fetched i n t o m e m o ry. Note
t ha t these structures d o not generate una I igned
fau l ts. I nstea d , they force the c o m p i l e r to generate
a few a d d i t i o n a l instructions to hand le the odd
a l ignment.

VAX Testing

Anoth e r ge neral problem that we

had to guard against was the possibi l i ty that the
Alpha AXP code cha nges wou ld i ntroduce bugs i nto
the VAX versions of the products. Consequently, we
adopted a pol icy whe reby a l l Alpha AXP c h a nges
had to be rested on a VAX sys t e m . This pol icy
ensured that we m a i n tained a steady pattern of cor
rect VAX behavi or. Also, since the VAX enviro n m e n t
w a s m o r e stable than the Alpha AXP environment,
testing on a VA X system helped tremendou s l y in
i d e n t ifying and fixing bugs related to the port.

The CALLG Mecbanis111 and AP References
Alpha

AXP

platform

does

not

d i rectly

Th e

support

CALLG, a VAX proced u re cal l ing mechan is m , and
and

references to the AP. The C\ Ll.G mechanism and A P

are

references are slow since they are s i m u l ated a n d

ent irely d ifferent. Rather than us ing the standard

a u tomatica l ly al locate stack space t o acco m m odate

BLISS mecha n ism , the exist i ng code dep ended

the largest possible argu m e n t l ist ( i . e . , 255). In situ

Argument-passing
Alpha

AXP

The

klecbanism

argu m e n t - passing

VAX

mechanisms

stro ngly on the VAX argument -passing mecha nisms

ati ons w h e re p e rfo r mance was not cri t ical, fo r

by u s i ng BLISS m a c ros to reference argu m e n t s from

examp.le, in an error h a n d l e r, we replaced CALL(; by

the AP. T h is approac h was not possible on Alpha

a standard rou t i n e cal l on both the VAX ancl the

A X P systems due to t h e lack of an AP register. (You

Alph a AXP software versions. When p e r fo rmance

cou ld fo rce the AP to be generated, but that process

was an issue , we used conditional code to retain the

wou ld

m e m ory.)

CALLG mechanism fo r the VAX code and to use a

Therefore , we changed our proced u re h e a d i n gs to

standard rou tine ca l l in the A l pha AXP cod e. I n

PI

i nstances where the CALLC mechanism i s used t o

be

slow

and

wou ld

waste

decl are a generic fo r m a l parameter l is t (e .g. ,

fo r both the Alpha A.,'\ P and the VAX

pass the a rg u m e n t l ist to the next ro u t i n e , we con

systems a nd then developed another set of BLISS

stru cted an argument vector and re p l aced CALLG by

macros that al lowed us to bind to the argu ments

a special cal l l i n kage . The new mechanism passed

through

PN )

a

based on the generated fo r m a l parameter l ist. Since

the pointer to the argument vecto r by means of

this process involved changing every rou tine dec la

si ngle parameter or a g l o b a l register. T h i s s o l u t i o n

rati o n , we developed a text - p rocessing tool that

guara n teed good p e rfo rma nce o n both VAX a n d

would automatic a l ly change the rou t i ne headi ngs

Alpha A X P systems yet avoided a ny cond i t i o n a l i z i ng

and thereby avoid the expen sive and error-prone

of the code.

task of manually changing each rout i n e .

VA X MACR0-32 Modules
BUILTIN Functions

Together, t h e KODA, Rd b, and

For

a

variety of reasons,

we used VA X MACR0-32 to code some ro u t i n es in

DBMS code uses most of t h e BLISS Bli.I LTJ N fu nc

the Rdb, DBMS, and KO DA software. For example,

t i ons. This fac t presented a p roblem fo r the team

basic operations such as record compression, record

porting the software to the Alpha AXP platfo r m .

ex pansi on, ami bu ffe r i n i t i a l ization are pe rfo rmed

Some VAX BU !LT ! Ns were not supported, some

through ca l ls to VAX MACR0-32 ro u t i nes that are

behaved d i ffe rently, and some were e l i m ina ted as

heav i l y o p t i m ized fo r efficient operati o n . Some

BUILT!Ns but emu lated by Starlet, an Op enVi\i!S

routines

Digital Techuicaljourllal

Vol. 4 No. 4

Special Issue 19')2

are

coded

in

VAX

MACR0-32

for

ease

1 )7

Alpha AXP Architecture and Systems

of character m a n ipu l a t i o n .

Al so, we

used

VA X

c hanged the mechanism to defi n e the KOD$_ sym

MACR0-32 to code m a chine i nstructions that were

bo l i c v a l u es to be compat ible w i t h both the VA X

not ava i lable through a BLISS BUILTJ N func t i o n .

and AJ pha A X P architectures.

We adopted various sol u tions for t h e s e VAX

First, we removed all . LITERAL declarations from

MACR0-32 r o u t i nes. For those rou t i n es where p e r

the KODA message fi l e . As a res u l t , a l l KODA mes

fo rmance was not an issue ami BLISS generated

sages

acceptable code, we converted to BUSS code. For

messages. Then, a fter passing the m essage source

were

defined

strictly as RDMS

or DBMS

rou tines where performa nce was abso lu tely criti

file t h rough the message com p i ler to get t h e mes

c a l , we rewrote the rou tine i n Alpha A X P MACR0- 64

sage object file, we invoked the Al'\IALYZE/OBJECT

to u t i l i ze the a d d i t i o n a l registers. F i n a l ly, in some

faci l i ty to get a l isting of the message symbol codes

cases where we could n o t rew rite the routine in

and va lues for each message. F i n a l l y, we wrote a

B U SS code and did not have the resources ro con

sma l l u t i l i t y to read the ANALYZE/OBJECT o u t p u t

vert to

a n d generate a BJJ SS . 8 32 f i l e , whicl1 i s shown i n

,'v!ACR0-64

code, we employed the Alpha

Figure

:'I'IACRO cross compi ler.

5.

Th is BLISS progra m , when compi led and i nc l u ded
Message File Support

Due to the str ucture of the

i n a n exec u t able i m age , defi nes the appropriate

da tabase produc ts, as shown in Figure I , each c o m

KOO$_ message codes and their associa ted valu es.

ponent has separate message files. Both Rdb and

This proced u re is used o n both the OpenVMS VA X

DBMS have a message file that i s separate from the

and the O p e nVMS AXP operat i ng systems to ge ner

KODA message file. Furthermore , t h e Rdb and DBMS

ate the message fi les. Furtherm ore, since this group

software share the KODA message file.

no l onger writes programs that read object cod e ,

The message files are merged d ur i ng the b u i l d

the resu l t i ng method i s ea..<; ier to m a i n t a i n .

cycle. s o t ha t custom ers are n o t required t o b e
aware o f the mod u lar layo u t of t h e code. A s a res u l t ,

The fo l l ow i n g th ree sections d iscuss s o m e prob
lems enco u n tered by each of the p o rting teams.

KO DA messages, w h e n appeml ecl to Rd b's message
fi le, print as Rdb messages (e.g . , RD.'v!S-F-msgcode,

Porting the KODA Database Kernel

message text). However, the Rdb source code sti l l

Am o ng the issues that the KO DA gro u p d ealt with

references

were those re lated to c a l l ing mechanisms, kernel

the

KODA message codes w i t h

the

KODS_ message prefix .

mode ru ndown hand Ins, and a bugcheck d u m p

Prior t o t h e i ntrodu c t i o n o f t h e Alpha A X P arch i

mech a n ism .

tecture, the KO DA messages were defi ned w i t h
The KODA data

. l.ITERAL declarations i n t h e message files. Si nce we

Stacl�-switching/Stall Mechanism

occasi o na l ly link i m ages with m u l t iple message

base kernel performs its own m u l t i threading activi

files, we wrote a program that wo u l d read an . O B.J

ties. A single process can be a c t ively a t t ached to

f i le and write a new . OBJ file w i thout writing the

m u ltiple databases i n the c o ntext of a si ngle instan

KO DA l i teral declarations. This process wou ld no

t iation of the software. For example, i n the DBMS

longer work since AJ pha AXP object files have a d if

i n t e ractive query (OBQ) fa c i l i t y, the user can per

fe rent fo r m a t than VAX object files. As a result, we

for m the fol lowing opera t i o n :

MODULE

DBMKO D M S G

BEG IN
GLOBAL

LITERAL

K O D $ _A B O R T _ W A I T

%X ' 0028800C ' ;

GLOBAL

LITERAL

K O D $ _A C C V I O

%X ' 002885EC ' ;

GLOBAL

LI TERAL

K O D $ _A I J A C T I V E

%X ' 00288BA3 ' ;

GLOBAL

LI TERAL

KOD$

% X ' 00 2 8 8 B 3 3 ' ;

AIJ ALLDONE

END
E LU D O M

Fi�ure 3

! '58

BLISS Code to Genemte KOD iV!essa�e Deji'n itions

Vof. -1 ,Vo. i

.\jJt'ciaf Issue 19'Jl

Digital TeciJIIical jourual

Porting Digital's Database Management Products to the Alpha A XP Pla tform

I

dbq>

Attach

to

f

DB1

ON

S T R EAM

1

BIND

dbq>
d b q>

I

dbq>

as

h a n d l e r a l so c leaned up OpenVMS data st ructures

user 1 .

such as the pend i ng AST queue. These OpenVMS

At tach

t o

second

database

DB2

ON

STR EAM

2

BIND

dbq>

da tabase

i rs t

as

user2 .

AX P

dbq>
dbq>

I

dbq>

SET

user1

Estab l i s h
STR EAM

data structu res changed signifi c a n t l y fo r the A l p ha
arch itec ture.

For

example,

an

Al pha

AXP

system has five p e n d i ng AST queues in stead of one.

contex t .

In a d d i t i o n , this h a ndler ro utine wo u l d acq u i re the

1

OpenVMS sched u ler spinlock and perform ·'poor
This exnmple has the user at tached to two d i ffe r

m a n's lockdown,"' which effectively pages the entire

e n t chtabases, DB I and DB2. To issue queries agai nst

rou tine in t o m e m o ry (s ince the code cannot incur n

either database, the u s e r ent ers the SET STREA."vl

page fa u l t at elevated i n ter rupt priority l e ve l , ! PL).

c o m m a n d . In response, KODA establ ishes the cor

For Alpha AXP, code and data cannot be located i n

rect datn stru c tu res and stream context fo r t h i s

the s a m e PSECT, s o this trick w a s n o t poss i b l e .

database sess ion . This process i n volves switch i ng
data structures and stack context. Consequ ent ly,
KODA m a nages its own stack fo r its exe c u t i ve mode
code nod

data structures.

This stack-switch i ng

mechan ism is complex, and t h i s code is i nt i m a t e l y
tied t o the VAX procedu re c a l l i ng mecha n i s m . Fo r
exa mple, whenever a query must sta l l (e . g . , w h i l e
wa i t i ng for a lock request), KO DA saves the current
execut ive mode cont ext and then swi tches back
t h rough the stream code out to user mode. Thi s
action al lows the process t o receive user-mode
ASTs. This mecha n i s m essenti a l ly saves a c a l l frame
that nfter the user-mode s t a l l has completed,

so

KODA can set u p the appropriate stack and retu rn to
the cal l i n g rou tine by means of the saved call fra me.

Instead, w e u s e d the $ L KWSET m a c r o to lock pages
i n memory and t hen to c l e a n u p the OpenVMS data
structures.
After we c o m pleted ancl tested the code, the
database and OpenVMS engineering teams decid ed
that such i n t ricacy was need lessly complex, and
that the OpenVMS AXP software cou ld clean up
t h e data st ructu res based o n irs i mage control
block and rel ated structures. This example shows
how the Open VMS A X P system offe rs d ifferent fu nc
tion al ity t h a n the OpenVMS VAX system , i . e . , the
port offered the opportunity to c lean u p existing
mechanis ms.

Bugcheck Dump Mechanism

Complex, sophisti

The c a l l ing/return mechanism i s e n t i re l y d i ffer

cated software products are by nature d i fficu l t to

ent for the VAX nnd Alpha A X P arch i tectures. On

debug. Most of these products u t i l i ze a data struc

Alpha AXI' systems, for each rou t i n e , the compi ler

t u re cll1 m p i ng mechanism whenever a n i n tern a l

generates prologue cod e a nd epi logue code to man

software o r hardware e r r o r is enc o u n tered. KODA

age the rou t i n e ca l l i ng mechanism. Accord i ngly,

Ius a mecha n i s m called a bugcheck cl u m p tha t per

the KODA stack mec h a n i s m had to rely on t h i s new

forms this service . When an u nexpected exception

mech a n i s m . I n a d d i t i o n . for t h is level of support,

i s generated, the bugcheck d u m p cocle prints nll rel

the rou t i n e that was coded i n BLISS fo r t he VAX plat

evant clara structu res i n t o a fi le. In a d d i t i o n , the

form had to be coded i n

MACR0-64

on the Alpha

cl u m p i nclud es a stack d u m p . On VAX syste ms, the
bugcheck d u m p trnces bnck down the stack u s i ng

AXP platfo r m .

the saved c a l l frames and p r ints o u t a l l t he fields i n

Kernel- ntode Rundown Han dlers
ple

of KODA's close

tie

to

Anot h e r exam

OpenVi'vlS

be hnvior

each ca l l fra me, the rou tine name, a n d t h e argu
ments passed .

i n volved the use of KODA's kernel-mode ru ndown

In pnrti c u l ar, the method for printing the sym

h a n d l er. On VAX systems, i n the event of an abnor

bo l i c name of the ro u t i nes i s especi a l l y cl ever. After

mal fai l u re , we m u st cl ean up c e r t a i n cl ara st ruc

l i n k i ng an image, we u t i l i ze a progrnm t h a t scnns

t u res

and

release

resources

such

as

locks

or

the symbol table (.STB file) prod uced by the l i nker.

c h a n n e l s . F u r t h e r m o r e , da tabase recovery m u st

Th e n the program creates its own object fi l e , which

start before the im age ru ndown is completed, so

i ncl u d es a relative offset of a l l the rou t i n es and their

t hat surviv i ng processes can not acqui re locks on

symb o l i c na mes. Final ly, the i m age is re l i n ked, and

resources before the da tabases are recove red .

t h is new object file i s incl ude d into the i m age i n a

\XIe acco m pl i sh t h is ima ge cleanup through the

particu l a r PSECT. Wben tracing back down the call

use of a user-defi ned system service (i . e . , a system

frames, the bugcheck cl u m p a l s o checks the special

by the OpenVMS syst em),

PSECT to locate and print the correct ro utine name.

wh ich acts as a kernel-mode ru ndown h a nd ler.

service

not

defined

This d u m p i s an i n va l u able tool i n dete r m i n ing the

Jn a d d i tion to re leas i n g da tabase resou rces, the

causes of unexpected errors. F igure 4 incl udes two

Digital Teclmical journal

Vol. 4 No 4

Special issue I'JI.J2

1 '59

AJpha AXP Architecture and Sysrems

Saved
ARG#

PC = 000408 A F
: D I O $ F E T C H _D 8 K E Y + 0 0 0 0 0 0 4 F
A r g u m e n t [ d a t a . . . J - ---- -- -- --- ---- ---------- -- ----------------- --- --- --

1

00206484 :

2

00000001

0 00 1 F C F C

Hand l e r
Saved

00000000 ,

=

AP

002064 F4
PSW

002064 4 C ,

=

00206 50C
0000,

=

Saved

FP

=

207COOOO

CALLS

000277C7

1 ,

=

00206430,

0001 0000

STACKO FFS
PC

Op code

=

00020001

0
EO

=

SR2

002646DO :

00000000

00000000

000069 1 8

F F DAA3E8

F FF63770

00000000

SR3

00008C 4 1 :

01 3A2048

C2 F F F F F F

F F F F F85E

E0009 5 87

D 5 1 2A4EO

40000000

1 8C00040

SR4

00264680 :

00000008

00206 4 5 C

002646AO

00000000

00000000

00000000

00000000

20

bytes

of

stack

da ta

f r om

0020641 C

to

0020643 0 :

002646800000000 1 00206 48400000002

0000

' . . . . 4d

001 C7D08

001 0

' . } . . '

Sa ved
ARG#

00000000

. . . . . OF& . '

PC = 000 55241
:
PS I $ M O D I F Y S T I T M + 0 0 0 0 0 0 3 3
A r g u m e n t [ d a t a . . . J - - -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - -- - - -

1

00206484 :

2

00000096

3

002646 0 0 :

0001 F C F C

002064F4

00000000

00000000

Hand l e r
Saved

AP

00000000,

=
=

PSW

00206490,

0020650C

207COOOO

000069 1 8

F F DAA3E8

=

0000,

Saved

FP

=

C A LLS

=

1 ,

00206464,

000277C7

0001 0000

00020001

FF F63770

00000000

00000000

STACKOFFS
PC

Opcode

=
=

0
DD

SR2

=

00256042 :

00020096

000000 5 F

00000057

00000000

0000 0002

0001 0000

002E2A1 3

SR3

=

00264 680 :

00000000

000000 0 1

00000008

002646AO

00264670

00000000

00000000

24

bytes

of

s t a c k

data

f r om

0020644C

to

00206464 :

002646 D00000009600206484 00000003

0000

' . . . . 4d

001 C7C F8002646CO

001 0

' @ F& . x l . . '

Figure

4

. . . . . PF& . '

Bugcheck DumjJ

rou t i ne ca l l s from a stack trace, i n d icated by the

process is s i m p le r t h an d i rectly crea t i ng a n object

l i n es of code that begi n with " Saved PC."

file, as we did p reviously.

Alpha A X !' systems have no equivalent to the \ : \ X

Even though the routines prov i d ed t h i s c a l l trace

c a l l fra mes. s o i t is i mposs i b l e t o u s e the c a l l frame

back capabi l i t y, we were m issi n g the argu ments

mechanism to trace cJown through the stack. As

passecJ to the rou tin es, perhaps the most i m portant

mentio ned previously, A l pha AXP rou t i n es u t i l i ze

parr of the stack trace . The VA X mechanism cap

prologue ami epi logue cocJe for returning from rou·

tured this data, because very often a bugcheck

t i n e cal l s. P roced u re descri ptors c o n t a i n i nfo rma

resu lts from one rou tine passing a n i mprop er argu

tion

such

as

entry

a d d ress

and

register save

ment to a n other rou t i n e . The A l p h a A X P system
does not provide a way to capture this i n formation,

info rm a t i o n .
O n Alpha A X P systems, a n other Dig i t a l gro u p
supplied a s e t o f rou t i nes that a l l ows tracing t h e

because the rou t i n e cal l i ng sequence reuses regis
ters R 16 through R 2 l fo r passing argu ments.

c a l l sequence. Th is set provided t he basic capabi l
i t y to pri nt the ro u t i n e ca l l ing sequ e n ce that led to

Porting Rdb

an abnormal excep t i o n . In a d d i t i o n . the A l p ha A X !'

Some issues hand led by the R d b p o r t i ng group

l i n ker prod u ced a symbol table fi l e . However. we

were associated w i t h the d ispatch code, Al p h a AXP

decided

cock

Al though

to simpl ify o u r bugc heck mechan ism .
we

sti l l search the symbol table file t(>r a l l

ge nera t i o n ,

Rd b

pre c o m p i lers,

ancJ

Rdb

system rel a tions.

rou t ine addresses, rather t h a n create a n Al pha A X !'
object fi l e , we create a VA X MACR0-32 file that

Dispatch Code

i n c l u d es

the

layer of the Rdb software a n d is ca l led d irect ly by

Then,

s i m p l y use the Alpha :\·lACRO cross com

we

rou tine

name

a n cJ

add ress/offse t .

The d i spatch code is the topmost

the user app l ication by means of r e l a t i o n a l ca l l

(K.cl) ca l l s 2 The

p i ler to ge nerate the Alpha AXP object, which gets

i nterface

l i n ked i n to the i mage on t he second p ass. In fact,

code is to d i rect the user request to the correct tar

main h1 nction o f d ispatch

we changed our VAX bugcheck rou tine to produce a

get Rc.l b executive (local or remote) for processing.

MACR0-.'>2 file with rou tine name and offsets. Tbi s

O n VAX syste ms, the dispatch code passes the user

160

Vol. 4 Nu. -1

Special issue 1')')2

D igital Technical journal

Porting Dl��ft{l/'s Dota{)ase 1Hanagement Products to the Alpha AXP Platform

argu m e n t s to the Rd b s o ftware using the CALLG
l i n kage.

'•

On Alpha A X P systems, CALLG l i n ka ge is

IDATA ITEM1,DATA ITEM21

NULL

BIT VECTOR

very i n effic ient. The refore , the d i spatch code was
cha nged to b u i l d a u s er arg u me n t vector in the

Figure 5

same s t y l e as the VAX argu ment l ist, a n d the pointer
to the argument vec tor was passed as a single
para meter. The code in Rd b was c ha nged to bind to

Rdb Record Layout

systems. ; Therefo re , t h e a lgor ithm was modified to

the

fe t c h a batch of n u l l bits into a register. When a l l

U s i ng two d i ffe rent ca l l i ng mec hanisms i n the

w r i t te n and t he next batch of n u l l bits is fe tched.

the user argu ments liSing the o ffset from
p o i nter to the argu ment vector.

d ispatch to pass u ser arguments was a carefu l
design . On VAX systems, the existing CALL( ; mecha
nism was ret a i ned to e n s u re backward c o m p a t i b i l
i t y between d i fferent ve rsions of the Rd b d i spatch ,
Ru b layered products, and gateways. A new ca l l i ng
mecha n ism was used on AJp h a A X I ' systems ro
ensure good perfo rm a nce, since every user request
to the Rdb execu t ive goes t h rough the d ispatch.

This approach reduced the n u m be r of load ami
store i nstructions and made the code seque nce
m u c h more efficient.
O n Alpha AXP syste ms, the m a ch ine code rou
ti nes generated by Rdb use fo u r d i fferent address
i ng m o d es to access data i t e m s : a bs o l u te add ress,
base register p l u s offset, in teger register content,
and floati ng-po i n t reg ister c o n t e n t . Each of the
A l p h a AXP registers R l2 t h rough R l5 is used as a

Rdb uses c o m p i led BLISS code

Code Generator

n u l l bits i n t he register are processe d , t h e batch is

base reg ister. Th u s, a n y data stored with i n 256K

user

(4 X 64K) of mem ory space can be accessed effi

requests. D u r i ng request co m p i l at i o n , Rd b gener

c i e n t ly To m ax i m i ze data access efficiency and

and

generated

m a c h i n e code to

ates h ighly efficient rou t i n e s

exec u t e

u s i n g the

t a rget

cach i ng, cha nges were made in the code gen e rator

p e rfo r m

to allocate data dense ly. To i m p rove performan ce

basic d a t a o p erations incl u d i ng d a t a co nvers i o n ,

fu rther, data items were a llocat ed at quadworc1 o r

d a t a movement between bu ffers, aggregat i o n , a n d

longworcl al igned addresses.

mach i ne

in structions.

These

ro u t i n es

An Alpha A X !' code sequence execu tes more

express ion ev a l u a t i o n .
T h e design of the Rd b c o d e ge n e rator t o prod uce

efficie n t l y w hen i nstructions can be m u l t i- issued

Alpha A X I' m a c h i n e code was u n d o u bted l y the

and exe c u ted i n para l le l . This can be ach ieved

most complex porting task. ljsl' of a mech a n i s m

by

o t h e r t ha n c o d e ge neration wo u l d have reduced

while m a i nt a i n i ng any chronological dependency

reordering

the

sequence

of

i nstructions

the p o r t i ng effort. However, at the time we began

between i nstructions. To t a ke advan tage of this

porting Rd b , i t was not clear i f a n a lternate mecha

Alpha AXP feature, BUSS macros were deve loped

nism wou ld guarantee an acceptable level of perfor

to reorder and in terleave the i n structions in a gen

ma nce. Good p e r formance was considered cri tical

erated code sequence.

to the suc cess o f Rcl b on Alpha A X P systems.

On Alpha AXP systems, backward branches in the

Therefore, we decided ro add fu nctional i t y to the

code slow down the exec u t i o n because of i n struc

Rd b code ge nerator to produce Alpha A X P code. To

tion s t ream inval iclat io n . ' Cha nges were m ade i n

generate effic i e n t Alp h a A X P code sequences, we

t h e R d b code ge n e rator to m i n i m ize backward

obse rved specific gu idel i nes . '

branches. T h is cha nge a t ti mes i n c reased the size of

On Alpha AXP systems, code that references data

the generated code b u t i m proved the code execu

items w i t h i ncreas i ng memory add resses executes

t i o n effi cien cy. Further, Boolean code ge neration

was

a l gori t h ms were m o d i fied to i ncorporate branch

c ha nged to first o rder the data items by i nc reasi ng

p rediction log i c ; code sequences with a s m a l ler

memory addresses a n d then generate code to pro

p roba b i l i t y of exec u t i o n were branched o u t of the

more efficien t ly.

Therefore,

the algo r i t h m

m a i n code s t ream. Th i s technique m a x i m ized t he

cess the data.
I n Rdb, each data item has a n u l l hit that ind icates

effect of i nstruction stream cach in g.

whether or not the value o f the data i tem is k nown .
As shown i n F i g u re 5, to cons erve s pace, the n u l l

Rdb Precompilers

bits of d i ffe re n t data items are stored together l i ke

cesses a user a p p l ication p rogram t h a t i n c l u d es

a bit vecto r w i t h i n a record . Loadi ng/stor i ng a

Rdb state me n t s and replaces t hese statements by

nu l I h i t is an expens ive opera t i o n on Alpha A X P

stand ard RCI cal ls to t h e Rdb software 2 The Rd b

Digital Teclmicaljourua/

Vol. 4 No. 4

.SjJecial Issue 19')2

A n Rdb p recom pi ler prep ro

161

Alpha AXP Architecture and Systems

statements embedded in the app l ications can be

Porting DBMS

one of three types: stru ctured query language

This section d isc usses some experiences of the

(SQL), Rdb preprocessors l a nguage (Rdb l'HE). or

relational

data

m a n ipulation

language

(RDJ'v!L).

There are th ree differen t Rdb precompi lers to sup
port these languages.
The SQL precompi l er, an industry-standard l a n

ORMS p o rt i ng group, namely those rel a ted to the

Database Con tro l System (DBCS) i n terface, the
H_FLOAT data type suppon, and the usc of the
AJpha User-mode Debugging Environ ment (AlJD).

guage i n terface to Ru b , is a strategic Rub com ro

DBivl$32. the Primary lnteJjace to the DBtv!S

nent. A long- term goa l of this precomriler is

DBCS for the DBMS software uses a si ngle subrou

The

flexibil ity in future developments and ease of m a i n

tine (DBM $ .12) as i ts primary entry p o i n t. Th is entry

tenance. To meet this goa l , the SQL p recompiler was

p o i n t is used by the DBMS precompi lers (FDML,

redesigned to use the GEM com piler o n Alpha AXP

for Fortran, and D M L, for other lang uages except

systems to prerrocess S Q L appl ication programs

COBOL), as wel l as other layered p roducts, such as

and produce Alpha AXP object code.

COBOL and DATATR ! EVE.

The Rd bPRE precom piler is a proprietary lan

After receiv i ng contro l , DBM S :)2 pe rforms some

guage interface to Rd b. The long-term goal is no

processing and then, using the CAJ.Lc; mechanism ,

new fu nctional ity and m i n i m a l m a intena nce . So

passes the e n t ire argument l ist to lower-level rou

the

t ines t(>r further processi n g . These lower- leveJ rou

main

objective was to red uce

the

effort

required to port this compi ler. This was ach ieved by

ti nes, in t u rn , often pass o n the argu ment l ist,

retaining the existing design and using the Alpha

sometimes as deep as five or six levels.

MACRO cross comriler to produce Alpha A X P

Because we folll1(1 CALLG to be i neffic ient, we
decided to change the primary en try poi nt i n to the

objects from V A X MACR0-32 files.
The R.DML precompiler is a l s o a proprietary la n
guage in terface to Rdb. Unl i ke rhe Rd bPRE precom

DBCS. Rather than passing up to 26 separate argu

ments, Dll.VlS creates a vector of longwords; each

pi ler, this compi ler does nor produce V A X .'ltACR0-.12

longword contains an argument that would have

files. So po rting it was an easy and straightforward

been passed using a parameter. Once this vector is
created (often d u r i ng the compil ation phase for the

task .

Rclb .System Relations

R d b u s e s system re lations

to record information abo u t the user re lations and
the databas e . The system re lations are stored on
d i s k and loaded i n to memory o n demand. Since
they are frequently referenced duri ng user request
processing, efficient access to data in system rela
tions is critica l for performance. O n A l p ha A X P
systems, accessing data from memory is efficient if
it is located on either a Iongword or a quadword
address boundary. i Therefore, changes were made
ro the in-memory system data structures to al ign
each data field tO at least a longword address bou nd

precompi lers), D B M $ 32_VEC (the VECTOR ve rsion
of DBM$32) is cal led with a s ingle parameter: the
address of the argument l ist. An example is shown
i n Figure 6.
Layered products usi ng DBi\·15 were advised of the
new i n te rface and were requested to use i r as soon
as possible. However, since the changed inte rface
was i ncompatible with some existing products, the

old i nterface was retained. D R M S 32_ VEC uses the
n ew i nterface, and DBM$32 homes the argument l ist
(thus crea ting the above vector) and then passes
that, by reference, to D B M $ 32_V E C : .

ary. Further, data fields that were a byte or a word

Support of H_FLOA T Data TJ pes

were expanded to a longword.

data type is fu l ly supported o n the VAX processor,

The H_FLOAT

The data in system re lations was accessed by

but the Alpha AXP processor has no high-precision

using RdbPRE statements embedded i n Rub source

floati ng-p o i n t formats. Al though fac il it ies exist o n

modu les.

Alpha A X!' processors t o read an H_F LOAT data

Porting such

Rdb m o d ules posed a

dilem m a . To compile these modu les,

first the

RdbPRE compi ler had to be ported to the Alpha AXP

type, n o such facil i t y exists to write

;m

I-I_F LOAT

data typ e .

platform. Vice versa , to port and test the Rd bPRE

A s a resu lt, D B M S customers arc advised t o el imi

precompi ler, Rdb had to be ported and running on

nate any 1-l_fi .OAT data i n databases before moving

the Alpha AXP platform . Moreover, Rd b!'RE was no

them to an Alpha AX P system. The DBMS Database

longer a strategic language in terface. Therefore,

Restructure U t i l it y (DRU) can be us ecl to cha nge a l l

n ew BLISS macros were designed t hat rep.! aced the

H_FLOAT data to another com m on floa ting-roint

embedded Rd bPRE statemen ts.

format.

1 62

Vol. 4 No. 4

.\f!t!Cial lssue /'}9..!

Digital Technical journal

Porting Digital's Database Management Products to t!Je Alpha AXP Pla tform

DBM$32 I N T E R FACE

DBM$32_ VEC I NTERFACE

ARG1 = FI RST PARAMETER
ARG2 = SECOND PARAMETER

A RG 1 � �------�
LENGTH OF VECTOR
FIRST PARAMETER

ARGN

=

N T H PARAMETER

SECOND PARAMETER

NTH PARAMETER

Figure 6

DBCS Routine-calling JnteJjace

I n prepara tion for m ixed VAX ami A lpha A X P

5. Most of the changes that we made i n DBMS were

VMScl uster systems, DBMS was m o d i fied such that

not con d i t i o n a l , that is, the changes wou ld affect

databases with H_FLOAT data can sti l l be accessed .

both VAX and Al pha AXP systems. As a result, we

However, a r u n - t i me conversion error occurs if

were able to test o u r code on VA.,'{ systems with a

H_FLOAT data is accessed

fairly h ig h degree of cert a i n t y that our code was

from an Alpha A X P

correct, barring a n y operating system or com

system.

p i le r bugs.

Use of A UD

The Alpha User-mode Debuggi ng

Environment is a set of faci l it ies that ai ds testing
and debugging of n a t ive Alpha AXP code o n any
OpenVMS VA X system. AUD a l lowed as much Alpha
A X !' user-mode code as possible to be ported im me
d iately to the Alpha AXP system and to be s u bst a n
t i a l l y debugged before Alpha AXP h a rdware was
ava i l able. Early in the DBMS porting effo rt , we used
AUD to veri fy our port and to ensu re that our code
was wo rking correctly.
However, several issues hampered the success of
using Al J D in porting the DBMS software:
I . DBMS makes freque n t use of signaled excep

We d id eventual ly get an AlJ D version of DBMS
worki n g . However, s i nce we spent a considerable
a m o u n t of time acco m p l ishing this, and we did not
actual ly find a ny bugs i n o u r code by using AUD, we
decided not to use AUD i n fu rther areas of DBMS.
Shortly after using AUD , we received our Alpha
Demonstra t i o n U n it (AD l l ) and could test our code
on act u a l Alpha AXP hardware . The o nly problems
we fou n d , wh ich were m issed d u ring our i n itial
port, were VA X-st y l e argu ment I ist assu m ptio ns.
Some of our code assu med that rou ti n e argu ments
were contiguous i n virtual m e mory; on Alpha AXP
systems, this is not the case.

tions. AUD had d i fficu l t y in hand l i ng exceptions
that cross the boundary between the Alph a AX P

Conclusion

a nd VAX systems.

To conclude the paper, we d iscuss our plans for per

2. DBMS uses special stack manipu l a t i o n code

(stream code) to perform m u l t ith read ing func
tions. AU D wou ld become co nfused if the stack
were to change u nexpected ly.
). At the ti me we were using AUD, the DBCS had
been ported, but KODA ( i . e . , the low- level ser
vices used by the DBCS) had not. As a resu l t ,
many variables needed to be defined as crossing
the bou ndary between the Alpha A X P a n d VAX
systems. The setup t i m e to define this i nfor m a
tion was significant.

formance testing and our reflections on the porting
process.

Petjormance
We have only begun o u r performance tests. Cur
rent l y, we are r u n n i ng the TPC-B performance
bench mark . We a lso plan to test aga i nst a l l TPC
benchmarks (A, B, and C) and other benchmarks
such as the Wisconsin benchmark. We are trying to
m i n imize the amou nt of time spent in PA Lcod e ,
decreasing the code path length, reducing t h e cycles
per instru ction, and optimizing i n ternal algorithms.

VAX proces

Planned testing wil I a lso evaluate the effect of

sor, many VA X depen dencies were not caught by

add itional data al ignment. As men t io n ed earl ier, the

Al i D . I n particu l a r, system services that changed

ease-of-migration issue is paramou nt for our cu rrent

in subtle ways wou ld work as before because the

customers. Consequent ly, we have not rea l igned

operating system was sti l l the OpenVMS syst e m .

the database pages because that action would

4 . Since the code was sti l l r u n n i ng on a

D igital Technical journal

11JI.

4 No. 4

SjJecial lssttl! I'J91

Alpha AXP Architecture and Systems

requ i re too much downtime. Nevertheless, we do
not want to preclude new customers, or c u rre nt
customers who need the performance boost, from
u t i l i zi ng a properly al igned database page. To test
the potential pe rformance improvement, we plan
to create a test database that is completely a l igned ,
in memory and on disk, and compare the TPC per
fo rmance agai nst the standard database.

Reflections
At the begi nning of the paper, we stated that our
goal was for Digital to p rovide an easy m igration
path to the Alpha AXP platform for software prod
ucts. Al though we encou n tered some d ifficulties,
we bel ieve o u r Rdb and DBMS porting efforts attest
to Digital's success in th is endeavor.
As one example of how the experience in flu
enced o u r approach to porting, we had to learn
new methodologies. practices, and system behavior
on the Alpha A X P machi nes. For instance, when
stepping through a particular code seque nce with
the debugger, we wou ld end up in an infinite loop;
if we just ran the cod e, t he sequence wou ld work.
Although this behavior was documented , we
encountered the problem several t i mes before we
ful l y u nderstood the ram ifications and appropri
ately changed our development methods.
Overal l, the porting effort had the fol lowing pos
itive resu lts:
•

•

•

•

The port allowed us to clean u p our cocle, even
though we tried to avoid algorithm changes.
Because we had to port and review every l i ne of
code, we managed to move the code to a more
consistent coding convention.
The p o rt acted as a learn ing experience for most
of the engineers . Most mature products contain
some code that has not been m o d ified in years.
The port fo rced us to review ancl understand
such code sequences. As a resu lt, we ended up
with more knowledgeab.le engineers.
The port al lowed us to transform the code i n to
a more portable state . As we moved away from
tight ties to VAX behavior, we simplified fu ture
tasks such as mov ing to the OSF/ 1 and Windows
NT operating systems.

•

•

Surprisi ngly, the code dicl not grow appreciably
in size or complexity. One stre ngth of the Rdb
and DBMS software has been the abi l i ty to easi .ly
mod ify the code and to add new fu nctional ity.
Even after t he port, we find that the products
are as mal leable and as easy to m o d i fy as before.
We fou nd unreported bugs in our VA X products.

Virtua l ly a l l the groups involved d id a masterful
j ob . The program team and various Alpha AXP com
mittees anricipated p otential issues and ensu red
that the program proceeded smoothly and pre
di ctably. The cross compil ers from the language
groups worked su perbly. The OpenV:.01S A X !' and
hardware groups del ivered their products on time,
and when a user logs i n to an Alpha AX P system, the
Open VMS A X P system is not o n ly fa m i l iar but faster.

Acknowledgments
The successfu l port of the Rdb and DBMS software
to the OpenV1vi S A X P operati ng system was a resu lt
of the contributions made by many of the engineers
in the Database Systems Group. The a u thors si n
cerely acknowledge the effort of each engineer i n
achieving the project goal, that is, t o b e able to
qu ickly offer correct versions of Rclb ancl D!:IMS on
the Alpha AXP platfo r m . Finally, an unsung hero in
the company-wide effort was D igital's VAX Notes
commun ications fac i l ity. VAX Notes hmctioned as
an excel lent med i u m for iden tifying and sharing
p roblems and solutions.

References
l . T Leonard , VA X Architecture Reference Manual

( Bedfo rd .

MA:

Digital Press, Order No. EY-3459E

IW, 1987 ) .
2 . OS'Rl Handbook ( M aynard, MA : Digital Equ ipment

Corpo ration, Order No. AA-GV71 A-TE, 1986)
Calling Standard ( Maynard, :.01 A :
Digi tal Equipment Corporation, Order No. A A

3. Ope n VMS

I'QY2A-TK, 1992) .
4. R.

Sites, eel . , Alpha A rchitecture Reference
Manual ( 13urli ngto n, M A : D igital Press, Order
No. EY-L'S20E-OP, 1992)

Although overlapp i ng current VAX development
with the Alpha A X P port slowed dow n the port
ing process, the decision to use a common code
base el iminated the fu ture need to i n tegrate two
<.1 ivergent sou rce codes.

1 64

Vol.

,Vo. 4

Special Issue 1992

D igital Techuical journal

james V. Colombo
Pamela]. Rickard
Paul Benoit

DECnetfor OpenVMSAXP:
A Case History
Tbe DECnet for Open VMS AXP networking software facilitates the integration of
Open VMS AXP systems into existing DECnet computing environments. This new soft
ware product supports application migration by providing the following net

working capabilities: support of compatible libraries, consistent application
programming inteifaces, and the assurance of a common semantic operation with
the Open VLHS VA X system. The team implemented a phasedporting process and exe
cuted the project cooperatively The effort resulted in a solid knowledge base with

which to approach future porting undertakings. Using common code where possi
ble and avoiding architecture-specific code were lessons learned during the project.

The DECnet for Open VMS AXP networking software

and identifies specific problem areas. It concludes

product plays an i mportant role in the integration

with a summary of the lessons learned during the

of Open VMS AXP systems into existing DECnet com

course of the project.

puting environments. The availability of DECnet
software on the AJpha JL'(P hardware platform facil
itates application migration. The networking capa
bil ities needed to support this migration activity
include support of compatible l ibraries, consistent
application programming interfaces (APis), and the
assurance of a common semantic operation with
the OpenVMS VAX system. The network features

Project Overview
In addition to presenting the DECnet for OpenVMS
AXP features, this section details how we derived a
project schedule and gives an overview of the soft
ware components.

such as network file transfer, remote file access,

Software Code Base

remote login, downline load, and local and remote

Prior to the formation of a team to port a DECnet

network management allow the OpenVMS A,"(p

product from VAX to the AJpha AXP architecture,

system to participate fu lly in a DECnet network.
The pu rpose of this paper is to describe the pro
cess of porting the DECnet-VAX product to the
OpenVMS IL'
cial lssue

1992

4.33 weeks,

and

1 67

Alpha AXP Architecture and Systems

Ta ble 4

M o d u l e Count Method
Total Ti me

Compo nent

BLISS

MACRO

Link

per Component

DTRIDTS
EVL
HLD
M I RROR
MOM
NCP
N ETACP
N ETDRIVER*
N ICONFIG
N M Lt
N ETSERVER

0.00
1 . 00
0.00
0.00
1 . 50
3 . 50
0 . 00
0 . 00
0.70
3.1 0
0.30

2.80
0.00
1 . 80
0.20
1 . 40
0.40
4 . 80
0.80
0.00
1 . 40
0.00

2 . 00
2.00
2.00
2.00
4.00
4.00
6.00
6.00
2 . 00
4.00
2.00

4 . 80
3.00
3.80
2.20
6.90
7.90
1 0 .80
6.80
2.70
8.50
2.30

1 0.1 0
2.33
0.1 9

1 3.60
3. 1 4
0 . 26

36.00
8.31
0.69

59.70
1 3. 78
1 .1 5

TOTALS
Weeks
Months
Years
Notes:
•

I nc l udes estimates for N DDRIVER

t I ncl udes estimates for N M LS H R
Note that t h e data presented i s i n weeks, unless otherwise specified. A week equals five working days, a month e q u a l s
a y e a r equals 1 2 months o r 52 weeks.

Ta ble 5

4 . 3 3 weeks,

and

Planned Project Sch e d u l e
Total Time

Code
Component

Port

Debug

Review

Test

per Component

DTRIDTS
EVL
HLD
M I RROR
MOM
NCP
N ETACP
N ETDRIVER*
N ICONFIG
N M Lt
N ETSERVER

4 . 80
3.00
3.80
2.20
6.90
7.90
1 0 .80
6.80
2 . 70
8.50
2.30

4.00
4.00
4.00
4.00
4 .00
4.00
8.00
8.00
4.00
4.00
4.00

2.00
2.00
2.00
2.00
2.00
2.00
6.00
6.00
2.00
2.00
2 . 00

6.00
6.00
6.00
6.00
6.00
6.00
6.00
6.00
6.00
6.00
6.00

1 6.80
1 5.00
1 5.80
1 4.20
1 8.90
1 9.90
30.80
26.80
1 4 .70
20.50
1 4 .30

59.70
1 3.78
1 .1 5

52.00
1 2 .00
1 . 00

30.00
6.92
0.58

66.00
1 5 .23
1 . 27

207.70
47.93
3.99

TOTALS
Weeks
Months
Years
Notes:
•

I ncludes estimates for N D D RIVER

t I ncludes estimates for N M LS H R

Note t h a t the data presented i s i n weeks, unless otherwise specified. A week equals f i v e work i ng days, a m o n t h equals
a year equals 1 2 months or 52 weeks.

I GR

\ 'r ,f. - 1

So. 1

.\jJC'Citil /ssul! I 'J' JJ

4.33

weeks, a n d

Dip,ital Ti!clmical jounw/

DECnetfor OpenVMS AXP: A Case History

OpenVM S AXP was targeted for base level five.

m ade architecture-specific code conditional on the

However, it was h ighly desirable to provide file

platform on which it wou ld execute. Our long-term

transfer and remote login capabi l i t y over DECnet as

goal is to incorporate common code into future

early as possible. The project team worked closely

DECnet for Open VMS products.

with the OpenVMS AXP group to deliver this sup
port prior to base level four.

DECnetfor OpenVMS AXP Components
This section describes

Conunon Code

OpenVMS

the

major DECnet for

components and l ists the porting

AXP

One of the most i mportant decisions that helped us

issues relevant to each 2 F igure 1 shows the i nter

del iver our software a head of schedule was bui ld

connection of the various components of the
DECnet for OpenVMS A..\: P software. Detailed info r

ing common code for the VAX and Alpha AXP

systems. Dur i ng the course of porting code, we dis

m at ion for each porting issue is further d iscussed i n

covered two advantages to building common code.

this paper u nder the Porting Issues headi ng.

The first was having the abi l i ty to generate VAX and
Alpha AXP images from a s i ngle set of source code.

NETDRIVER

The second was bei ng able to debug o u r ported

d river, i . e . , a device driver that does not d i rectly

NETDRNER

is

a

pseudo

device

changes in a stable OpenVtviS VAX environment. We

contro l any hardware devices. It implements the

accompl ished this by rewriting code that requ i red

routing, end com m u nicat i o n , and sess i o n control

change so that i t worked o n both platforms. We

layers of the Phase rv version of DNA. 1

I

I I

RT P AD

I

REMACP

I

I I

I I

DTS

I

DTR

I

I I

II

USER

I

I

!

DATABASE

I

I
I

CTD R I V E R

RTTD R IV E R

IJ
I

1-I1

LOCAL

PERM AN ENT

I

I

1
I

....I1

I

R E MOTE
NML

I

$010

NETDRIVER

I
I

SESSION
1-_
_
_
U_
N_
IC
_
A
M_
_
E
T
N
C_
O M_
10
D
----t
N
ROUTING

I

4 No. 4

I

I

I

!k1i.

N I CO N F I G

N I C E MESSAGES

I

Digital Tecbnical]ounwl

I

APPLICATION

$010

Figure 1

I

EVL

Jl

N M LSH R

NETSERVER

I

l
NCP

I

I

RMS

I
DATA LINK D R I V E R

NETACP
ROUTING
DATABASE
VOLATILE
DATABASE

I
I

$010
MOM

I

$010
NDDRIVER

I

I

DECnetfor OpenViHS AXP Components

Special l:�sue

1992

1 69

Alpha AXP At·chitecture and Systems

The queue 1!0 request ($QIO) system service is

the

DNA

command term inal (CTERNl) protocol .

the i nterface into the session con trol layer. The

CTD RTVER

NETDRIVER rou ting layer communicates with other

tions with the exceptio n tha t RITDRIVE R is used for

device drivers that implement the data l i n k layer of

interoperabi l ity with older i m plementations of

DNA.

communicates

NETDRIVER

with

NETACP

(another component d iscussed later in this section)

and

RTTDRJ.VER

remote terminal support.
control process

perform similar func

REMACP

is an ancil lary

that receives incoming

(ACI')

to perfo rm network management fu nctions, to

requests for remote term inal support. After RbvJACP

report state and network topology changes, and to

establis hes a connection with the remote node,

perform operations that require process context.

either

NETDRIVER i s written in
sented

us

with

many

MACI�0-32

porting

code and pre·

issues,

includ

ing device d r i ve r changes, coroutines, memory

or

CTDRIVER

d irectly with

com m u nicates

RTTDRJVER

NE'f'DRIVER

to send and receive

remote terminal protocol messages.
CTDRIVER,

and REMACP are written i n

RJTDRIVER,

management changes, page size depen dencies,

MACR0-32 code a n d presentee! t h e fol lowing port

atomicity and granu larity problems, OpenVMS

ing issues: device driver changes, u na ligned refer

AXP

operating system data structu re changes, u nal igned

ences,

references, and up-level stack references.

st ructure changes, and for REMACP, changes in the

OpenVMS

inte rface with

MOM

The

m a intenance

operations

by the maintenance operation protoco l (�lOP). One
such service operation is downline loading remote
NDDRTVER

(d escri bed i n the

next subsection) to commu nicate with the remote
system over a DECnet circuit. MOM communicates
with NETACP to gather i nformation abo u t nodes
requesting to be down l ine loaded. NETACP creates a
process running the MOM im age when a request for
a service operation is received on a circu i t enabled
to perform service operations.
MOM is writte n primari ly i n BUSS-32 code. Porting

issues i ncluded removing dependencies on the for
mat of a VA X argu ment J ist, condition hand l ing
changes, and Alpha 1L"XP im age header changes.

NDDRIVER

The pseudo device driver NDDRIVEH

implements an interface that a llows MOM to use a
DECnet circ u i t to perform service operations using
DNA

operating

system

data

CTDRIVER.

m o d u le

(MOM) image processes service operations defined

systems. MOM uses

AXP

M OP The MOM image uses the $QIO system
.

NETACP

1\ E1ACP runs as an ACP that assists

N ETDRIVER i n perform ing network operations that
require process context. Examples include creating
processes for incoming logical links and assigning
channels to data l i nk devices.
NETACP

NETDRIVER

and

a l so wor.k together to maintain information

about the state of the network. Another major func
tion performed by NETACP i s t l1e management of
the network configuration p arameters residing in
virtual memory.
NETACP is written i n

MACR0-32

cod e. Port i ng

issues included corou ti nes, usage of processor
status longword

(PSL)

condition codes, memory

management changes, page s ize depend encies,
atomicity and granu l arity problems, OpenVMS

AXP

operating system data structure changes, and
u n a l igned references. In addition, the use of "poor
programmer's lockdown," a method of locking
pages into a working set, requ ired modification.

service interface to send lVlOP messages to and
receive MOP messages from

N D D RIVER,

which then

commun icates with the data l ink device drivers to

Nl:T.mRVER

The

N ETSERVER

im age i s run by

serve r p rocesses created to hand le incoming logi

transmit and receive these messages. ND DRIVER

cal link requests.

communicates with

comm and p rocedure associated with the network

NETACP to perform tasks

N ETSERVER

invokes the im age or

that requ ire process context and to receive notifica

object specified by the incoming logical l i nk. To

tion of state changes to circu i t s enabled for service

avo id the overhead of process c reation, a server

operations.

process can be reused after the logical link it was

N O D RJVER

is written in

MACR0-32

code. Porting

servicing is terminated. Idle server processes regis

issues included changes to device drivers, memory

ter themselves with NETACP so that they may be

management, and OpenVJVrs

reused for another logical link.

tL"XP

op erating system

data structures, as wel l as page size dependencies.

NETSERVER

is written in

BLISS-32

code. The

only porting change necessary was the addition

CTlJRJVER, RTTDRI VER, and REMACP

CT DRIV E R

of the

!3LISS VOLAT I LE

is a pseudo device driver fo r remote terminals using

declarations.

1 70

Vol 4 No. 4

a tt r i b u te to several data

Special Issue 1 992

D igital Tecbnicaljournal

DECnetfor OpenVMS A XP: A Case 1-IistOJy

NCP

The network conrrol p rogram (NCP) is the

user in terface t creates a logi

the DECnet test receiver (DTR) are coopera t i ng pro

cal l i nk to the network ma nagement l istener ( N M L)

grams that can be used to test the network connec

The DECnet test sender (DTS) and

object on the re mote node ami exchanges NICE pro

tion between two nodes. DTS runs on the local node

tocol messages over this logi cal l i n k .

and c o m m u n icates with DTR on the remote n o d e .

NCP co nsists p r i m a r i l y o f Bl..ISS-32 modu les. T h e

DTS and DTR c a n b e u s e d t o test t h e through p u t and

major p o r t i n g issue associated w i t h NCP was cha ng

r e l i ab i l i t y of a l i n e over which DECnet is r u n n i ng .

i n g t h e code to use LIB$TABJ .E_I'ARSE rather than

LIB$TPARSE.

DTS and DTR are writ ten p r i m a r i l y in M ACil0-32
code. The two major porting issues associated with

DTS and DTR were changing the code to u s e
NlVILSHR is a shareable i mage that pro

LIB$TABLE_PARSE r a t h e r t h a n U B$TPA RSE and add

cesses NICE protocol network m anagement mes

i ng some BLISS-32 code to s u p por t floati ng- p o i n t

sages on an O p e nVMS system. N M LS H R decodes

o p e rations.

NMLSHR

NICE me ssages received as i n p u t and p er forms the
requested m a n agement opera t i o n . N 1YI LS H R b u i l d s

RTPA D

N ICE p rotocol messages as a res ponse to requests

a loca l t e r m i n a l and the remote terminal services of

asking fo r network ma nagement info r m a t i o n to be

a remote n o d e . RTPA D i s i n voked as the resu lt of

RTPAD prov ides the connec t i o n between

retu rned. NCI' a n d NNIL both l i n k with the N M LSHR

executing the SET HOST com mand of the Digital

i mage ro cal l the rou t i nes that process the N ICE pro

Command La nguage (DCL) . RTPAD c o m m u n icates

tocol messages.

wi t h RE:viACP and CTD RIVER o r RlTD R I VER o n the

NMLSHR is w r i t t en in BL.ISS- 32 and MACR0-32.
Porr i ng issues i n c l u d ed d e p e ndencies on the for

remote system to provide remote terminal support.

RTPAD accepts input from the local t e r m i n a l (which

mar of a VA X argu m e n t I ist and c h a nges req u i red to

cou ld be another remote t e r m i n a l ) and sends t h i s

l i n k shareable i m ages.

d a t a over the network t o the remote n o d e . O u t p u t
from the remote n o d e is received b y RTI'AD a n d d is

1

IVIL

The network ma nagement l istener (NM I..)

nection to the

a

p l ayed o n the local term i na l .

con

RTPAD i s written i n .YIACR0-32 code. Porting

N M I.. object to perform remote

issues i n c lucled u n a l igned references and al igning

i m age is r u n when a re mot e node requests

netwo rk ma nagement o p e ration s. NML sends N ICE

dat a structure fields on natural boundaries.

protocol messages to and receives them from t h e
remote n o d e . N MI. passes N I C E protocol messages

NJCONF!G

received from the remote node to N M LSHR fo r

that l istens to the MOP system i d e n tification mes

decoding and receives messages from N M LSHR to

sages broadcast on E t hernet c i rcu its and mai n t a i n s

send to the remote node.

a d a tabase of c o n fi g urat i o n i n forma t i o n t<> r a l l sys

N ICON FJG is the Ethernet configurato r

N M L is writ ten in Bl..I SS-32 code. The o n ly porting

tems heard . NCP is used to man age and d ispla y the

change made to N M L code was ro add the BUSS

informa tion m a i n tai ned by N!CON FI(;. N ICONFIG

VOLATILE attribute to one data declarat i o n .

run s as a process created by N M L'ilm and co m m u ni
cates with N MLSHR over a DECnet logical l i n k usin g

EVL

T h e event logger (EV I..) receives eve n t mes

the NICE protocol.

sages from the vari ous DNA l ayers. EVL can also act

N ICONFIG is written in BLISS-32 code. The o n ly

as an e vent s i n k for m essages generated at a remote

p or t i ng change was to remove the m o d u l e switch

node. EVI.. is started by N ETAC I' and declares i t se l f

LANGUAG E .

a s a network object so t h a t re mote n o d e s c a n con
nect to the EVL object and send event messages. EVL

HLD

can log events to a fi le in b i nary fo rm o r fo r m a t the

the DECnet-RSX sate l l i te loader to down l ine load

Digital Tecbnical journal

l'r!l. 4 Nu. 1

SjJecial lssue 1992

T h e h o s t loader ( HLD) com m u n icates with

I71

Alpha AXP Architecture and Systems

tasks to an RSX-115 node. H l.D is w r i t ten i n ,\•l ACR0-

procedures were cop ied onto t h e d is k from a AX P

.')2 co de. The o n ly porting cha nge was to up date the

syste m . Each t i me new DECnet for O p e n V M S AXP

structu re defi n it i o n language used to c reate one

i mages or test p rocedu res had to be adclecl t o the

data structure.

shared d i s k d u r i ng a test o r debug session, the Alpha

AXP test system had to be stOpped, the d i s k
m i rror p a r t i c ipates i n

mou n te d on t h e VA X system, i m ages copi e d , the disk

network servic es protocol and ro u t i ng l a yer loop

d is m o u n ted , a n d the A l p ha A.,'\ P system rebooted .

MIRROR

The

loopba c k

back testing. M I RROR is written in MACH0- :)2 co d e .

Provi d i ng fi le transfe r s u p p o r t by means of t he

N o p o r t ing changes were requ i red t h o u g h changes

DECnet for OpenVMS AXP software ea rly in t h e

were made ro t he li nk proce , l u re .

Alpha AXP project provided i n c reased p ro d u c t i v i t y
fo r anyo ne resting o n A l r ha AXP p rototype systems.

DECnet- VAX Port to the OpenVMS
AXP Operating System

Porting Process

This sec t i o n d iscusses the deve lo p m e n t e n v i ron

The process of p o r t i n g the DECnet software from

m e n t , process, and i ssues re la ted to porting the

the

D ECnet -VA X product to the OpenVJviS operating

p l a t form consisted of t he fo l lowing steps: code

syste m .

preparatio n , c o mp i la t i o n . l i n k ing, c o d e review,

VAX

hardware p la t fo r m

to t h e Alpha

AXP

debug, a n d test i ng. We d i d nor start t h e task of port

DECnetfor Open VMS AXP
Development Environment

ing DECnet -VAX w i t h a co mpletely clear v i s i o n of

DECnet fo r OpenV.'vlS AXP i s bu i l t with a n d i n te

more abo u t the tools a nd p or t i ng process, we

the t o t a l process. As we progressed a n d lea rned

grated i n to the OpenVMS A X I' opera t i ng syste m .

i mp roved ou r port i n g tech n i ques a n d , as a resu l t ,

Many changes were being m a d e t o system data

ou r p roductivity.

struct ures that dire c t ly affected the DECnet soft
ware.

These

changes requ i red

t he

DECnet

fo r

OpenVMS A X P software to be b u i lt with a n d tested
on

many i n te r i m opera t i ng system base leve l s

befo re t h e c o m b i ned
sys t e m a n d

OpenV,\·IS A X P operating

DECnet fo r OpenVMS

AXP k i t was

s h i p ped fo r layered product development.
Because the development tools cha nge'! thro u g l1out the project, we u s ed the same tools to port t h e
DECnet -\1,.\ X software a s were u s e t l to deve l op the

Our strategy was ro begin by porting the d r ivers
and privileged code . These c o m p o n e n t s were t h e
m os t compl ex: t hey were w r i t te n completely i n
.\olACR0-.')2 code and hat.! the greatest poten tia l for
cha nge. We started w i t h NETDRIVER and NETACI',
assig n i ng one engi neer to work o n each com po
n e n t . As o u r porting group grew in n u m ber, we
began to port, in paral lel, the RUSS m od u les that
comprise N C P , N M l., N M I.S H R , EVL , and MO M .
T h e fo l l owing is a n overview of t h e process we

operating system base levels. When we copied ror

used to port the DECnet-VAX soft ware to t h e Alpha

tions of an OpenV M S AXP base le ve l , we also cop ied

A X P platfo r m . Later sections c o n ta i n deta i l s of CO(i

the too.! d i rectories associated with the system

i ng pra c t ices that had t o change.

bu ild . We used cross co m p i lers for .\·l AC : R0- .')2 and
1 \ USS- .12 . wbicb a l lowed u s to deve l o p Alpha AXP

Code Prepamtion

soft ware o n a n Ope nV\olS VAX system .< In add i t i o n ,

p rocedures that we cou ld use early i n the porting

O u r first task was to create

we used the Op enVMS A X P l i n ker, l i bra rian. a n d

process to comp i le s i ngle m o d u les of a DEC:net for

system d u m p ana lyzer (SDA) c ross to o l s o n t h e VA X

Open VMS AX I' compone n t . We also p o r te d t h e com

system . '' We a lso used the OpenV,vlS A X !' debug

ponent's b u i ld proce d u re to use the new Alpha A X P

gi ng tools Delta and

XDelra

on t he A l pha .\XI' proto

cross tools.
Next, we began to prepare the code for i n i t ial

type hardware (,
I n i t i a l D EC:net fo r OpenVMS A X !' test i ng was

a

comp i la t i o n . J'-•1.\ CR0- .')2 code must have each e n t ry

VAX syste m . Such test i n g was

point i d e n tified prior to the i n i t i a l comp i l e . E n t ry

possible because we designed a maj ority of t h e

p o i n ts are identified by a compiler directive such as

accompli shed on

a nd

Each

d i rect ive

DEC:net fo r O p e nV M S AXP c o d e t o r u n o n b o t h VA X

. J S Fl_ENTRY

and A l p h a A X P hardware platforms.

accepts optional para meters that i d e n t i fy register

.CALL_ENTRY.

The Alpha A.,'\1' p rototype system used for testing

usage. However, t h i s i n forma t i o n i s n o r requ ired

u t i l i zed a shared d is k that c o n ta i ned the OpenVMS

a t this p o i n t in the p o r t i ng process. The Alpha

A X P operating syste m i m ages. The images a n d t es t

A X !'

1 72

l'ci/.

,\ lACR0-:12

4 ,Vn. • f

c o m p i le r

.\jJ<"cial Iss//<'

/'J'Jl

will

prov i d e

re gister

D igital Tecbuical journal

DECnetfor Ope nVMS A XP: A Case History

usage hints du ring the compilation, if so directed .

some atomicity and granularity problems that are

As the team became fam i l iar with the porting

not resolved/addressed m ight cause code fai lures

process, we were able to combine these steps

during debug. 1

and include the register usage informati o n when

NETDRJVER

and N ETACP c o n t a ined architecture

declaring entry points. Also, as our experience

specific code, i ncluding memory management,

i ncreased , we were able to make changes to non

driver tables, a nd structure defi n i tions, which had

portable coding practices prior to the initial com

to be made cond itional for the OpenV.MS AXP a n d

p ile of a module.

OpenVMS V A X systems. A prefix file was added to

Our experience proved, as we expected, that

each iVLACR0-32 m o d u le during the Alpha AXP com

BLISS code is far easier to port than MACR0-32 code.

p i lation step. This file contained an Alpha AXP dec

For the DECnet-VAX components containing BLISS

l aration that a l l owed us to i nc l ude the d irectives

modules, we began the port by running the compo

required for conditional comp i l ation. To compile

BUSS rou ti nes do not

t he ported code on a VAX system, it was necessary

require that enttl' points be identified. The com

to provide a VAX declaration and macros for t he

piler can process each module, identify errors, and

various entry-point d i rectives that when expanded

provide warning and informational messages.

contained no instructions. These were p laced in a

nent's b u i l d procedure.

Compile Process

After we completed the initial

code preparation and created customized build
procedures, the real iterative process of porting
began. At this point we compi l ed o ne or more
modules, made additional modifications based o n
the compi lation resu lts, and recompiled u nt i l we
were reasonably satisfied that a l l t he errors were
fixed .
The Alpha AXP cross compi lers, the iVLACR0-32
compiler in particular, have t he capab i l i ty of pro
v id i ng a vast array of informational and warning
messages. When com p i l ing a modu le, we always
requested a l l informational messages. The infor
mation assisted us in identifying the input and o u t
put registers as wel l as the registers that the
compi ler automatical ly preserved . Using this infor

common l ibrary file and conditional ly compiled.
The l ibrary file i s included i n each module. Figure 2
is an example of a l ibrary file that contains a VAX
declaration and macros.
BLISS

architecture-specific

code

was

made

conditional us ing the %if %bliss(bl iss32v) or %if
%bl iss(bl iss32e) constructs for OpenVMS VAX and
OpenVMS AXP, respectively.
After porting a l l the modules within a compo
nent, the component's b u i ld procedure was run to
ensure that each m o d u l e had been ported without
error. This was typica l ly the first attempt to l i nk the
component. We also ran the OpenVMS VAX proce
dure to ensure that the code wou ld continue to
compile and l i nk on the OpenVMS VAX operating
system.

m ation, we verified the register usage i n each rou

Linking

tine and add ecl the i nformation to the entry-point

times. The DECnet for Open VMS AXP software con

directives. Other i nformational and warning mes

tains clrivers, system images, and shareable im ages.

sages

directed

us

to

cod i ng

techniques

The process of l inking was d ifficult at

that

Each component required changes to the l in k p ro

required change. By working with one module at a

cedures. We m a de these procedu res cond itional for

t i me, we avoided making repetitive porting errors

both the Open VMS VAX and the Open VMS AXP oper

in multiple modu les prior to our complete und er

ating systems.

stand ing of how to solve the more complex porting
problems.

The process of l inking the ported modules
brought to l ight many u nresolved references. I n

Some informational messages caution t hat cer

genera l , these references were t o external rou ti nes

tain coding techn i ques such as data a l ignment

that had changed for the OpenVMS AXP operating

should be m o d ified. We observed that attempting

system. One of the most d i fficult aspects of the

to make changes to a l i gn a l l data structure ele

porting project was determi n ing which changes

ments prior to comp leting pre l i minary debug and

to the OpenVMS operating system had an impact

testi ng caused many debug problems. Therefore,

on our project. Dete rmining these changes was

we decided to esta b l i s h a porting pol icy to change

diffic u l t because

o n ly as muc h code as was absolutely necessary

tig h t ly integrated i nto the Open VMS AXP operating

prior to the initial debug and test of a DECnet for

system. The process of porting applications to

DECnet for OpenVMS AXP is

OpenVMS AXP software component. A d hering to

the OpenVMS A)\P environment shou ld not be as

this pol icy required careful consideration, since

d ifficult.

Digital Technical journal

Vol. 4 No. 4

Special Issue 1992

173

Alpha AXP Arc hitecture and Systems

. SUBTITLE
Def i ne
ma c r o
. MACRO
. I F

$DECNETDEF

a l l

those

s ymbo l s

that

shou l d

precede

a l l

DECnet

modu l e s .

$DECNETDEF

N O T_D E F I N E D
These

A l p h a _A X P

make

not h i ng

Al pha

when

AXP

code

comp i l e

on

VAX

bu i l d s

by

do i n g

e n c oun t e red

VAX=1
. J SB

ENTRY
. ma c ro

. j s b_e n t r y ,

i nput,

output,

s c ratch,

preserve

. endm
. J SB32

ENTRY
. ma c ro

. j s b 3 2_en t r y ,

scratch,

p r e se rve

. endm
. CALL

ENTRY
.ma c ro

. c a l l_e n t r y ,

prese rve,

h o m e _a r g s = f a l s e ,

i n pu t ,

m a x_a r g s = O , 
output,

s c ra t c h

. endm
. ENDC
. ENDM
I

Figure 2

Code Ret'ieu•

Libmry File That Contains a VAX Declaration

und Macros

W h e n a l l t h e known por t i n g prob

l o ad i ng the p o rted N ETDRIVER and N ETACI' compo

lems t()lmd d u r ing the c o m p i l e and l i n k phases had

nents. Since m a n y of the req u i red cha nges were

been corrected, we began our code review process.

com mon to both OpenV:\•IS A X !' ami OpenW•IS VAX

The original VA X code, the ported code, and a d if

systems, we were able to d ebug m u c h of t h i s code

ference l is t i ng were ava i lable to t h e porting t e a m .

b e fore we had access to Alpha A X !' hardware . We

O n e or m o r e m e mbers of the t e a m reviewed t h e

fo und and fixed a nu m ber of proble m s using t h i s

c hanges made a n d p o i n t e d o u t a n y problems t h a t

techn ique.

were identi fied t o the person respo n s i ble fo r the
mod u le being reviewe d .

·when we were reasonably confi d e n t that t h e

We a l l h a d r re v io u s l y

ported c o d e w a s w o r k i n g o n t h e OpenV,VIS VA X

agreed t h a t t h e reviews wou l d be friend ly a n d t h a t

o p e ra t i ng syste m , we began testing on A l p h a A X !'

egos wou ld b e left o u t of the process. We found t h a t

prototype hardware , w h i c h fo rtunately had j u st

o u r successfu l c o d e rev iews were well worth t h e

become a vai lable. We c o m pleted the d r iver load

effort .

and ACP i n i t i a l ization testi ng. The i n i tial test uncov

Initial

reviews

turned

up

d i fferin g

p h i los

ered

some

problems

that

re q u i red

srecial

oph ies rega rding the porting p rocess. We d i sc u ssed

workaroumls to a l low debug to c o n t i n u e . These

these d ifkre ncl·s ami reach ed a cons ensu s. The

problems were corrected in l a ter ve rsions o f the

reviews u n covered errors in the porting process,

tools. S i nce the user i n t e rface had not yet heen

and correcting these problems reduced the amount

ported, test code was written to start DECnet for

of debugging required. The review process also

OpenVMS AXP and begin debugging the

a l lowed us to agree on and m a i n t a i n c o d i n g s t a n

face to the driver.

$QIO

inter

Eve ntu a l ly NCP, NML, and NMLSHR were ported ,

dards.

a n d more comprehensive debugging bega n . We

Debugging

Our

approach

to

debugging

the

used the OpenVMS A X P XDelta a n d Delta to o l s to

DECnet for Openv:vts A X I' s o ftware was to b u i l d the

debug the DECnet for Open Vi'•1S AX!' code on our

co m m o n ported code fo r a VA X system and to

Alp h a AXP prototype hardware . System fa i l u res

replace t h e Open V.viS VAX i m ages w i t h our ported

were clebuggecl using the SOA cross tool on

version on one of our workst ations. We began by

s ys t e m . \Ve learned how to trace cal l c h a i n s by

1 74

Vol. 4 No. 4

Special Jss11e /'J'Jl

a

VA X

Digital Tecbuical jourual

/JJ£netfor Open VJ\1/S AX 1-'.

studying

the

Open VMS

ca l l i ng

standard .

A

Case Histmy

su brout i n e c a l l s . \l(!e concl uded that the code,

l ' nderstanding the format of l inkage p airs, proce

wh ich had existed for a long time, a l ready saved and

d u re descrip tors, and register save areas made

restored the correct registers. \Ve decided that tr�'

debugging muc h easier prior to the ava i l abil i t y of

i ng to com mu nicate the correct l ist of input, our

these features in SDA. Debugging on an Alpha A X I'

p u t , pass - t h rough, and preserve registers to the

system is more d i fficu l t than on a VA X system s i nce

compiler cou ld be an i mpossible task, espec i a l l y

most VAX instructions generate m u ltiple Alpha A X J>

given o u r sched u l e . \'\1e investigated t he possib i l i t y

in structi ons w hose positions are op t i m i zed by the

of u s i ng t h e JSB32_ENTRY d i rective. T h i s d i rective

compiler to take adva ntage of Alpha AXP archi tec

a l lows the specification of registers that must be

ture features. 'fhus, i t is not a lways easy to fol low

prese rved but does not take any inp ut, output, or

the Alpha A X I' code l i n e by l i ne because the gener

scratch parameters. The OpenVMS AXP MACI{0-3.2

ated AJ p ha AXP code from one l a nguage statement

cross com p i ler wi l l not a u to m a t ica l ly p reserve any

is i nterspersed with Alpha A X P code generated

registers when this d i rective is used. A great deal of

from another language statement.

care must be taken when using t h is en try-po i n t
directive.

After solving the obv ious proble ms dur

Our decision to use .JSI332_ENlRY to declare entry

ing the debug process, we began to test the DECnet

points led to an in teresting problem with asyn

Testing

for OpenV,'V IS AXP code. Earl y ve rs i o ns of the

chronously executing code that could i nterru p t

OpenVMS A X P file system , record management ser

other threads o f execu t i o n . The DECnet-VA X code

vices (RMS), and the fil e access l istener (FAL) were

that we ported used PUS H R and l'OPR ins tructions

m ade avai lable to us. We in turn provided the

to save a nd restore regi sters that were m od i fied

DECnet for Open VMS A.XP code to the group porting

by DECnet-VAX code interru p t i ng another thread of

OpenV.'v iS RMS and FAL fo r their use io debugging.

exec u t i o n . W hen add i ng the . .JS B32_E'(fRY d i rec

We were then ab.le to r u n test scripts that used a
variety of DCL commands to pe rform loops of

tives, we specified a register preserve parameter
only on ex ternal entry p o i n ts, ass u m i n g that the

remote copies, d i fferences, and d i rec tory l isti ngs of

rem a i nder of the original DEC:net-VAX code was sav

remote files. DECner network manageme n t scripts

ing the proper registers. The preserve p a rameter

tested the network m anagement int e rface. DTS and
DTR were used to perform data transfer resting.
Since t h e DECnet for OpenVMS AX!' software was
avai lable early, it was used by other Alpha �'\P p o rt
i ng grou ps on Alpha AXP prototype hardware i n
various locations. As t h e code stab i l ized, a t i meshar
i n g system was set u p , w h i c h prov ided t h e opportu
nity for more res t i ng.

saved at rou t i n e entry and restored at rou tine ex i t .
T h e PUSHR a n d l'OPR instructions preserve o n ly
the low-order 32 b i ts of the specified registers.
However, if DECnet-VA X code in a ro uti ne w i t h o u t
t h e . JSB32 _ ENTRY preserve parameter interrupts
another thread of execution that makes use of t he
upper :)2 bits of a register, these upper 32 bits
wo u l d not be properly restored when control

Porting Issues
When we began port i ng t h e DECnet -VA X software
to the Alpha AXP hardware platform, we found
m a n y coding conventions cou ld not be used . Most
of these cod i ng p racti ces are cal led out by the cross
compilers, which significantly help e(l the porting
effort . :\
T h e fol lowing i s a d iscussion o f some p roblems
we encountered whi le porting and how we solved
them.
En try Points

ensmes that all 64 bits of the registers specified are

retu rned to the i n terrupted thread . The solution
was to specify the register preserve parameter on
the . .JSB32_ENTRY directives used to declare t h e
entry p o i n t s of ro u ti nes i n DECnet fo r OpenVMS
AXP t ha t are capable of i n terrupting other th reads
of execution.
Whenever we changed the i np u t or output
parameters to an internal subro u t i n e , we a lso
changed t h e name of that subroutine. This effort
helped i d e n t i fy all the i n ternal cal ls made to sub

Approxi ma tely fo ur months i n to the

rou t ines whose i n terface had changed .

project, the porting team determ ined that u s i ng the

Corou tines

A featu re of the Vi\ X architecture used

. . JS!3_ENTl{Y d i rective in NETDR!VER was goi ng to

th roughout

the

make porting d iffi c u l t . The d iffi c u l t y was clue to

ponents i s c a lled a corou t i n e . Corouti n e s usell

NETAC:P

and

N ETDRJVER

com

the complexity of the code and the fact that some

in MACR0-32 aJ low a subro u t i ne to call code frag

code p aths cont a i ned more than a dozen l ayers of

ments i n other subrout i n es. This technique uses the

Digital Technical journal

Vol. .:; .\'o. · i

.\ju.:ciaf !ssw: I'J'J2

1 7')

Alpha �W Architecture and Systems

j u m p - t o -subro u t i ne construct JSB @(SP)+ to j u mp

Alpha AXP arch itecture. Wh en a coro u t i n e i s sp l i t

between corou t i n es. T h e code example shown i n

i n to mu l t i p le rout ines, some code, such a s that test

Figure 3 demo nstrates the u s e o f the J S B construct.

ing ret u rned values. m ay cha nge re l a t ive loc a t i on.

The genera l flow of the exa m p le i s for MAI N to

I n our exa m p l e , the error p rocessi ng at SAVE is n o

cal l COROUTI N E with RO equal to 0 and R I equal

l onger necessa ry. Instead. ccmoUT ! N E returns to

to I. Usua l ly, COROUTIN E changes the value of R 1 to

NWN if i t detects an erro r, and .'vi A I N s i m p l y retu r n s

2 and calls back JVWN at a ddress SAVE. If COROUT I N E

to its c a l l e r w i t h t h e status i n R O . T h e VA X code

1, t h e n RO i s s e t t o 1

example in Figure 3 was co nve rted to Alpha AX !'

and the coro u t i n e d i a logue termin ates. MAI N a t

code using o u r tech nique. The res u l t i n g code is

address SAVE then tests RO and exi ts . U n d e r n o r m a l

shown in Figure 4.

i s entered w i t h R l n o t e q u a l to

c i rcumstanc es, MAI N at a d d ress SAVE continues,

The use of corou ti nes on A l pha A X !' systems

storing t h e returned value of R 1 in DATA ancl cal l i ng

sho u l d be d iscou raged because of the overhead

back the coro u t i ne at a d d ress FINAL. COROUTI NE at

associated with srori ng the ret u rn add ress i n regis

address FINAL then changes the value of R l to 3, sets

ters and the a d d i t i o n a l consu m p t i o n of stack space.

the return status i n RO to I , a n d returns to MAI N a t

Rather than a simple retu rn address o n the stack,

add ress TERMI NATE. TERMINATE then ex its J\IIAI N via

there wi l l be a register save area on the stack fo r

the RSB i nstru c t i o n .
Al l

entry

points

each subro u t i n e that m a kes u p the coroutine.
in

MACR0-32

code

on

an

Recursive coro u t ines c a n cons u me large q u a n t i ties

O p e n V MS A X P operating system mu st have an entry

of stack space. We have since converted corout ines

d i rective. Thus, i t is not possible to use the JSB con

used in m a i n code p a t h s to straight i n - l ine subrou

struct to j u mp to any random l i ne of code, as the

t i n e cal ls.

previous example demo nstrates. To do so, the code
�IACH0-32 code uses a n u m b e r of

shown in Figure 3 wou l cl have to be split i n to sub

Stack Usage

rou t i nes, each w i t h a .JSB_ENTHY or .JSI332_ENTRY

c o m m o n cod ing tech n iques that req u i re knowl

entry d i rective. Also, we had to cha nge the i m p le

edge of the state of the stack and rhat must be

mentation of corouti nes. Rather than use the s t a ck

changed for t h e OpenVMS

to pass return a d d resses, we passed each return

One such techn ique, referred t o a s an u p - l eve l stack

AXl' operating syste m .

referen c e , occurs whe never a subroutine attem pts

add ress i n a register.
Since some coro u t i nes ported were more com

to access info r m a t io n (ad dress or d a ta ) stored o n

plex than the example shown i n Figure 3, we devel

t he stack b y its caller. Parameter pass ing s o m e t i mes

oped a tec h n ique to port VA X corouti nes to the

uses this tech n ique. If a ro u t i n e p u s hes a rg u m e n t s

MAI N :

SAVE :

TERMI NATE :

MOVL

11 0 ,

RO

Assume

MOV L

11 1 ,

R 1

S e t

J SB

COROUTINE
RO,

TERMI NATE

No

R1 ,

DATA

Save

J SB

@ ( SP ) +

d i a logue

i n

w e

change

t h e

Shou l d

MOVL

11 2 ,

JSB

@ ( S P ) +

F I NAL :

MOVL

11 3 ,

R1

F i na L

EXIT :

MOV L

II 1 ,

RO

S i gna L

not ,

Change
Ca L L

va l ue

status

EXIT
R1

va l u e

wi t h

R1 ,

I f

d i a logue

c o r ou t i n e

Cont i nue
Ex i t

i n

c hanged

the

CMPL

RSB

1 76

change

BLBS

II 1

va l u e

co rout i ne

a

BNEQ

C O R O UT I N E :

Figure 3

Open

MOV L

RSB

fai L u r e

i ni t i a L

e x i t

va l ue'

rout i ne

va lue

the

ba c k

RO

t o

corout i ne

va lue
success

Return

VAX Code Example Showing the Use uf the Construct}SB @ (SP) + to}umjJ bettueen Co mu tines

Vol. 4 No. 4

Special issue 1992

Digital Teclmical journal

DECnetfor OpenVMS AXP: A Case History

MAI N :

. J SB

OUTPUT=,

ENTRY

SCRATCH=
RO

A s sume

R1

Set

fai L u re

MOVL

#0,
#1 ,

MOVAB

SAVE , RZ

Next

corout i ne

B S BW

COROUT I N E

Open

a

MOVL

. J SB

va l u e
address

corout i ne

Return

RSB
COROUTINE :

i n i t i a l

to

ca l l e r

we

change

d i a logue

I N PUT=< R 1 , R 2> , -

ENTRY

0UTPUT=

EXIT :

CMPL

R1 ,

BNEQ

EXIT

PUSHL

RZ

MOVL

#2,

Shou ld

#1

If

Save

exi t

next

Change

R1

F I NAL,R2

Corou t i ne

J SB

@ ( SP ) +

Cont i nue

MOVL

#1 ,

Set

RO

. JSB

the

va l u e ?

rou t i ne

corouti ne

the

MOVAB

address

va l u e
address

at

for

SAVE

to

use

SAVE

status

Return

RSB
SAV E :

not,

to

MAIN

I N PUT= , -

ENTRY

0UTPUT=
PUSHL

RZ

MOVL

R1 ,

JSB

@ ( SP l +

DATA

. J SB

next

Save

the

C on t i n u e
To

RSB

F I NA L :

Save

#3,

R1

RSB

Figure 4

addre ss

-

F INAL

va l ue

corout i ne

d i a logue

a t

F I NAL

COROU T I N E

O U T PUT=

ENTRY

MOVL

corou t i ne
c h a ng e d

;

F i na l

;

To

va l ue

SAVE

Alpha AXP Code Example Showing the Use of the Construct
}SB @(SP)+ tojump between Coroutines

onto the stack prior to jump i ng to a subroutine, the

Subroutines removed the return address from the

cal led subroutine does u p - level stack references to

stack and retu rned to the caller's cal ler. We modi

retrieve the argu ments. Other techniques i nclude

fied the code to remove the up- level stack refer

using the stack as a com m o n data area or a t te m p t·

ence (the c a l l e r's return address) and return a flag

i ng to m a n i p u l ate the caiJer's return address i n

in a register to signal the cal ler that a change in the

order to a l ter t h e program f low.

program flow was desired.

Al l these techniques require re-cod ing. When we
encoun tered code that passed p a rame ters on the
stack, we m o d i fied the code to pass parameters i n
registers. I f a structure was being passed, separate
memory was a l l ocated and the add ress of the struc
ture passed in a register. In one case, NETACP used
coro u t i nes to perform specific functions to update
a com mo n data area a l located on the stack. This
code was redesigned to e l i minate the corou tines
and u p -level stack references. Another alternative

Condition Codes

The Alpha A'"'XP arch itecture

does not sup port globa l condition codes in the pro
cessor status word . Some rou t i nes set condition
codes and returned to the cal ler, which proceeded
to perform a cond i t i o n a l branch o n the results of
the called rou ti ne. A l l occurrences of this tech
n ique were changed ; rou ti nes now pass the resul t
o f a ny conditional test t o t h e cal l e r i n a register.

wo u ld have been to pass the address of the data area
on the stack to the cal led rou tine.

Granularity and Atomicity IssuesH

The NETACP

Altering the program flow when error co n d i

and NETDRIVER components access shared data

t ions were encountered was a lso a co m mo n tech

structu res. Since NETDRlVER can i nterrupt N ETACP,

n ique used in the DECnet -VA X MACR0-32 code.

the DECnet-VAX code rel ies on the atomicity of VAX

Digital Technical]ourllal

Vol. 1 No. 4

5'pedal lssue 1992

1 77

Alpha AXP Architecture and Systems

instructions to provide synchronized access to

L!B$TPARSE Changes

shared fields i n the data structures. The DECnet -VA X
code also rel ies o n byte (8-bit) a n d word ( 1 6 -bit)

PA RS E

gra n u larity for memory writes. S i nce the gra n u la r

VA X ancl OpenVMS A..'\ P op erating systems, respec

ity of Alpha A X P memory wri tes i s e i t h e r longword

tively. The cal l to these rou tines ''' a s made concli

(:-)2- b i t) or quadword ( 6 4 -bit) , DECnet -VAX code

tional fo r the VA X and Alpha A X !' archi tectures.

L l fl $ TPA RSE and LJB$TAFll.E_

are the i n terface routines to a general

p urp ose, table-d riven parser for the OpenVMS

that required atomic access to wore! fields had to

Other changes were requ ired because Ull$TPARSE

be m o d ified to protect aga i nst writes to neighbor

ancl i . I H$'JABJ.E_PARSE d iffer in the way argument

ing byte a n cl word fields sharing the same long

l ists are passed . The method u s eel by UBS TPARSE to

word or quadword . In D ECnet for OpenW,IS AXP,

pass arguments is incompatible with the OpenVMS

word data structure fields shared by N ETAC:l' and

AXP caJ i i ng standard . The L! 13$TPARSE action rou

NETDRJVER

tines requ ired mod ification as a res u l t o f t he

that

required

atomic

access

were

moved to their own a l igned quadwords to p revent

required

i n terference from s i m u l ta neous writes to other

OpenVYIS AX!' operating system . The LJB $TPA R SE

byte and word fields sharing the same quadword.

a c t i o n routines received all or a subset of the argu

change

to

UBSTABLE_I'A RSE

fo r

the

After the word fields were placed i n their own

m e n t block as parameters. LIBSTA.BLE_I'ARSE passes

a l igned quadwords, the code generated b y the

the add ress of the argu men t block to t l1e action

M.ACR0-32 cross compiler for the A DAW! i nstruction

rou t ines. The s o l u t ion we used was to make the

was sufficient to prov ide atomic access to the word

rou ti n e declaration conditiona.l so that o n the

fields. We cou ld also have u sed comp i l e r d i rectives

OpenVNIS VA X operating system the action rou t i nes

to specify that VA X granu la rity and atom icity r u les

continued to receive the argu m e n t block p a rame

be preserved.

ters, and on the Open VMS A..'\P operating system the
action ro u t ines received the add ress of the argu
The lll.ISS-32 code in the DECnet 

ment block . Next, for the OpenV.viS A. X l' op erating

VA X software was relatively s imple to port. We

syste m , the parameter n ames u s ed by the c o m m o n

made minor changes to acid the VOLATILE parameter

c o d e were bou n d t o t h e argu ment block. These

to data i tems that should not be cached i n registers,

changes are shown in Figure 5.

BL/55-32 Code

to cond i t iona l l y com p i le the excep t i o n hand lers

As a resu lt of this relatively s imple though repeti

for VA X or Alpha AXP, and to remove unsupported

tive change, no other changes had to be made in the

b u i l t -i n s . Other modifications were more exten

action rout ines. If at some fu ture time the Open VMS

sive , such as the changes to accommodate the new

VAX opera t i ng system uses L I B $TA B L E_PARSE, there

U fl $TABLE_PARSE.

w i l l be no need fo r conditionals.

% I F

%B L I S S ( BL I SS 32 V )

GLOBAL

ROUTINE

%THEN

ACT$INV

COMMAND

( OPT,STRCNT, STRPTR, TKNCNT, TKNPTR,CHR,
N UM , PA R AM )

I

=

%ELSE
GLOBAL
% I F

R OU T I N E

ACT$ INV

%BLISS (BLISS32E)

COMMAND

( PA R S E

STATE

:

REF

$BBLOCK )

I

% F I

%THEN

BIND
OPT

P A R S E _ S T A T E C T P A $ L _O P T I O N S J ,

STR CNT

P A R S E _ S T A T E [ T P A $ L_ S T R I N G C N T ] ,

S T R PT R

P A R S E _ S T A T E [ T P A $ L_ S T R I N G P T R J ,

TKNCNT

P A R S E _S T A T E [ T P A $ L_T O K E N C N T J ,

TKNPTR

P A R S E _ S T A T E [ T P A $ L_ T O K E N P T R J ,

CHR

P A R S E _ S T A T E [ T P A $ B_ C H A R J ,

NUM

P A R S E _ S T A T E [ T P A $ L_ N U M B E R J ,

PAR AM

PARSE

STATE[TPA$L

PARAM]

% F I

Figure 5

178

L!B$ TPAR5E Changes

Vol. 4 No. 4

.\jiecial ls.,ue 1992

D igila/ 1eclmical jou rual

DECnetfo r Open VMS AXP. A

Conclusion
This port i ng effort not only provided a solid base of
knowledge with which to begi n the port of the
DECnet/OSI for OpenVMS VAX software and the
associated prod ucts, but a lso gave us an apprecia
t i o n of common code and the avoidance of archi
tecture-specific cod e.
More and more software is being po rted to new
hardware platforms. The porting process is often
carried our by individuals who d i d not deve lop
the original software and who may not even be
fam i l iar with it. Our ex pe rience porting the
DECnet-VAX code leads us to bel ieve that new soft
ware development shou ld take into account the
possi bil ity that the code wi l l be ported to new
hardware platf<>rms at some future date. As we con
tinue to port the DECnet/051 for OpenVM5 VAX soft
ware, it is becoming increasingly obv ious that
certain coding practices are difficu l t to port. As a
general suggestion, if the code has knowledge of
the architectu re but can be written using system
routines, system services, or r u n -tim e l i brary func
t ions, write the code in that manner. These system
rou tines wi l l be ported with the operating system,
and in a majority of the cases, the appl ication code
will not require modificati o n .
Also, if archi tecture- specific functions are
requ ired , provide only a m in i m u m amount of code
to perform these required functions and segregate
the code. Document how the code works, why i t
had t o be d o n e that way, what t h e al ternatives were,
and why they were not taken . In addition to helping
maintain the code, this information m ay provide
val uable assistance to a person porting the code in
the future.
If a rou tine is written in assembly l anguage for
the sole purpose of performance i mprovement,
consider rew riting it in a h igh-level language. I t is
possible that the assembly language coding conven
tions that may have been opti mal for one hardware
platform w i l l be slower on a d i fferent hardware
platform . Using h igh- level l anguage compilers,
which generate opti mized h a rdware-specific code,
will elim inate additional porting effort and may
very likely be the best performance solution.
As we d iscovered during the process of p orting
the DECnet -VA X software, MACf{0-32 code is signifi
cantly more d i ffic u l t to port than code writ ten in
higher- level languages. However, certain archi tec
ture-specific fu nctions m ay have to be written in
assembly language. We recommend that these fu nc
tions be isolated. In add ition, we recommend that

D igital Technical journal

Vol. 4 .Vo. 4

,\j;ecial fssue 1991

Case Histc) l y

any other code written i n MACR0-32 be rewri t ten ,
over rime, in a higher-level language.
We dete rmined that the fastest approach to port
i ng was to make the m i n i m u m number of changes
required to get the DECnet fo r OpenVMS A..,'\ 1' soft
ware running. The porting process was accom
pl ished in phases. The first phase i ncluded the
in itial port and addressed any errors th;�t occu rred
u n t i l we successfully com pletnl l inking the i mage .
This phase a lso i ncluded the i n itial debug, which
w;�s first performed on VAX systems because of our
common code approach and, subsequently, clone
o n Alpha AXP p rototype hardware. When the prod
uct was stable, we proceeded to the second phase
in which we beg;�n to method ically a l ign data struc
tures and fix gra n u l arity and atomicity problems.
Small changes cou ld then be made and tested, ami
any new problems were genera l ly easy to identify.
Our team approach to the p roject worked
extremely wel l . Each team member was init i a l ly
responsible for porting specific portions of the
code. As the project progressed, i ndividuals worked
on any part of the p roduct that neetled atte ntion.
This flexibility was a lso used when we began to
debug the ported code and again when we began
to respond to p roblem reports. Priorities were used
to assign resources in order to solve problems as
quickly as possible. Throughout the project, team
members wo r ked together to share knowledge and
to solve problems efficiently. This effective ream
work al lowed us to d e l iver the D ECnet for OpenVMS
AXP produ ct ahead of schedule.

Acknowledgments
The authors wou ld l ike to thank the other members
of the software development tea m , Ken Roberts,
Cathy Wright, our manager John Heron, and the
group engineering m anager Morea Manocchio,
whose hard work made this project a success. In
ad dition, we wo u ld l i ke to thank all the i ndividuals
of the Al pha AXP project who helped us along the
way. I n p a rticu lar, we wou ld like to recognize cer
tain i ndividuals for their i mportant contributions to
the success of this project: Pa u l Weiss, o u r porting
consu ltant; Lenny Scubowitz, David Gagne, and
Ben Thomas of the I/0 team; Karen Noel and M i ke
Harvey of the execut ive group; and Steve Dipirro of
the XDelta tea m .
The DECnet fo r OpenV,\'15 A X P project was only
part of the Alpha AXP team effort. We fee l fortunate
to have experienced the synergy that this team
created .

l 79

Alpha AXP Architecture and Systems

References

7 Open VMS Calling Standard (Maynard: D igital

1 . A . Lauck, D. Oran, a n d R. Perlman, " D i gital
Network

Arch i tec t u re

Overview,"

Digital

Equ ipment Corporat i o n , Order No. AA-PQY2A

TK, 1992).

Technical jounzal, vol. 1 , no. 3 (September
8. N . Kronen berg et a l . , " Po r ting O p e nVMS from

1 98 6) : 10 - 24.
2. P. Beck and ) . Kryc k a , "The DECnet-VAX Prod

u c t - A n In tegrated Approach to Netwo r k i ng,"

Digital Tecbnicaljoum al, vo l.

I, no. 3 (Septem

ber 198o): 88- 99.

3. /11/igrating to an Open VMS Alpha System: Port

ing

V,4 X MACRO

ment

Code (Ma ynard: D i g i t a l Equ ip

Corporation,

Order

No.

A A-PQYEA-TE,

1992) .
4. Open V,lJS

VA X to Alpha AXP," Digital Technical Journal,
vo l . 4, no. 4 (1992, t h i s issue): 1 1 1 - 120.

General References
DECnet for Open VMS Network Ma nagement Utili
ties (Maynard : D igital Equipment Corpora tio n ,
Order No. AA-PQYAA-TK, 1992).
DECn et j(J r

Linker tll/an ual (Maynard : Digi t a l

Equ ipment Corpora t i o n , Order N o . AA-PQXYA

Open VMS Guide to Networking (May

nard : Digi t a l Equ ipment Corpora t i o n , Order No.

AA-PQY8A-TK. 1992).

TK, 1992).

5. Open v,vts Alpha System Dump Analyzer Utility

Manual ( M aynard: D igital Equ ipment Corpora
t i o n , Order No. AA-PQYCA-TE, 1992).

6. Open VMS Delta/XDelta Utility Manual ( M ay
nard : D igital Equipment Corporation, Order No.

A A-PQYPA-TK, 1992).

1 80

DECnet for Open V.MS Networking Manual (May
n a rd : Digi t a l E q u i p m e n t Corpora t i o n , Orde r No.

A A-PQY9A-TK, 1992) .

Migmting to an Open VMS Alpha S)'sten-t: Pia n n ing
for Migration ( Maynard : D i g i t a l Equ ipment Corpo
rat i o n , O rder No. AA-PQY7A-TE, 1992 ) .

Vol. 4 No. 4

Special Issue 1992

Digital Tech11ical journal

George A. Darcy III
Ronald F. Brender
Stephen]. Morris
Michael V. Iles

Using Simulation to Develop
and Port Software
A mong the tools developed to support Digital's Alpha AXP program were four soft
ware simulators. The Mannequin and ISP instruction set simulators were used to
port the Open VMS and OSF!l operating systems to the Alpha A XP platform. The
Alpha User- mode Debugging Environ ment (AUD) allowed Alpha AXP user-mode
code to be debugged with support from tbe Open VMS VAX run -time environment
on VA X hardware. A UD was builtfrom a combination of new and existing Digital
software components. The Alpha User-mode Debugging Environment for
Translated Images (A UDI) allowed translated images to be debugged on a simulator
running on a \1,4. X computer. With these debugging environments, user- mode
applications and code components could be tested before Alpha AXP hardware and
operating system software were available.

Digital developed severa l soft ware simu lators to

in tracking the Alpha AXP arch itecture and in root

su pport i ts Alpha AXP program. 1 These tools

ing ou t software bugs that the OSF/1 group was able

enabled engineers to develop and port software for

to boot the ULTRlX operating system on the hard
ware on the f irst attempt. The Open VMS gro u p had

the 64-bit RISC Alpha A X P architecture concur
re ntly with hardware development. The simu lators

similar success and booted the Open VMS A X P oper

were used for a variety of purposes including port

ating system in a few hours.

ing, testing, verification, and performance analysis.

Note that the Alpha Demonstration U n i t (ADU) is

This paper d iscusses fou r Alpha AXP software simu

an Alpha A..,'\P prototype hardware system and

lators: Mannequin, ISP, AU D, and AUD I .

shou ld not be conh1sed with the Alpha User-mode
Debugging Environment (AUD) or the Alpha User
mode

The Mannequin and ISP Simulators
Two

Alpha

AXP

instruction

set

s i m u lators,

Mannequi n and ISP, were used to port operating
systems to the Alpha AXP p l a tform . The OpenYMS
group used the Man nequ in s i m u l ator to rort the

Debugging

Environment

fo r Trans lated

I m ages (AUDI) , two software simu lator facil i ties d is
cussed later in the pap er.

OpenVMS A XP Porting

OpenVMS VA X system to the Al pha AXP platform .

The Open VMS group used Mannequ in as their Alpha

L i kewise, the OSF/ 1 group used the ISP s i m u lator in

A X P instruction s i m u lator in porting the OpenVMS

their port of the U LTRJX and OSF/ 1 opera t i ng sys
tems to the Alpha AXP plat form. Both simu lators

VA X operating system to the Alpha AXP hardware.

were also used for architectural and design veri f ica

able to debug as much operating system code

tion, and for performance modeling.

Never before had an OpenVMS porting effort been
in advance of hardware.

Prior porting efforts

The .Mannequ in s i m u lator grew out of a s i m u la

debugged only u p to VNJB, a primary boot stage i n

tor <.leveloped for an earlier R ISC project at Digital.

the OpenVMS operating system . Using Mannequ i n ,

The ISP s i m u lator was written anew by engineers

operating system developers were able t o boot the

closely associated with the Alpha AXP architecture.

entire operating system on the s i m u l ator and actu

The two development groups were requested to

ally log in and debug u t i l ities.

boot their respective operating systems on the sim

Some developers used .M annequ i n 's own win

ul ators before attempting to boot on the Alpha

dows i n terface an<.l debugging faci l i ties to debug

Demonstration U n i t (A DU), the Alpha AXP proto

their code. Others ran the X De l ta util ity on top of

type hardware .L The simula tors were so successful

Mannequ i n . _; X Delta is a low-level system debugger

D igital Tee/mica I journal

Vol. 4 No. 4

Special Issue

/'}').2

181

AJpha AXP Architecture and Systems

useu ro debug t he OpenV:V!S VA X kernel anu drivers.

OSF/1 AXP Porting

However, the Mannequ i n i nte rface was usefu l in i n i

The OSF/1 operating system group used the ISP sim

t ia .l l y debugging XDel t a , since t he AJpha A X P con

u l a tor as an Al pha AXP instruction compute e ngine.

sole al lows neither breakpo i n ts nor single stepping.

The strategy was to co nnect the ISP s i m u l ator to

To debug their code before the fu l l OpenV:VIS AXP
operat i ng system was avai l able, other developers
usn! Mannequin in conjunction with the AJpha
primary boot (AI'B) code

and

a

test

harn ess.

Mannequin was especial. l y usefu l in fin d i ng a l ign
ment fau lt s in the boot sequence. since the a l ign
ment tools are not operational u n t i l the OpenVMS
AXJ' system i s com pletely booted. Alignment fau l ts
occur when an attempt is made to access a u n i t of
data located at an address that is n o t a m u l t i p le of
tile size of the data.

Jl!Iicrocode Speedup
One main reason the OpenV,VtS ream was able to
uebug a large part of t he operating system in real
time was the use of specially written m icro code to
speed up the s i m u lator. Mannequ in is capable of
runn ing with special user-wr i t ten m i crocode o n
the VAX 8800 fam i l y of machi nes. ' This mi crocode
is an a d d it ion to the n o r m a l VA X microcode for
the HHOO mach ines; the VAX m icrocode rem a i ns
un change d . With microcode support, a l a rge s u bset
of Alpha AX P instructions is execu ted i n microcode
and a t tains performan ce comparable to nat ive VA X
instructions. The Mannequin m i crocode occupies
95 percent of the total 1 , 024 words of the user

wri table control store .
Using m icrocode assistance greatly speeds up
Mannequin exec u t io n , yield i ng from 350 thousand
Alpha AXP instruct i o ns p e r CPU second (KI PS) to a
peak performance of 1 m i l l i on Alpha A X P inst ruc
tions per CPl i second (M I PS) on a VAX H 8 00.
Without microcode assistance. Mannequ in per for
mance is on the order of 10 K I P S . ( For comp;H ison,
t he !SP simu lator op erates a t approximately 30
KIPS . ) Code streams that exec u te completely in
Manneq u i n microcode show m uch better perfor
mance than those that sw i tch back and for th
between microcode ami the soft ware simu lator.

dbx . a standard UNIX sou rce-level debugger, v i a
dbx's remote interface. An interface was added t o
the lSI' to su pport t h e fol lowing low-level debugger
com mands:
•

Instruction stream examine a n d deposit

•

Data stream exa m i n e ami deposit

•

Register exa m i ne and deposit

•

Single step

•

Con t i nu e

•

f3oot
The dbx debugger was modified to work with the

64-bit Alpha AX P a rc h i tecture. That is, addresses in
the debugger were extended to 6 4 bits, and an
Alpha A X I' disassem bler was provided. The ISP
simu lator and d bx clebugger operated as separate
processes com m u nicat i ng on t he same machine
by means of a socket. A socket is a protocol
i ndependent connection point for interprocess

communications.
Historica l l y, the OSF/1 group used the J S P- d bx

combination to port the l . l.TRIX operat i ng system
to the AJpha AXP platform as an advanced develop
ment effort. When the group began to port t h e
OSF/ I

system ,

Alpha A X P

prototype hardware

(ADUs) and field- test compilers were avai lable .
Thus, the OS I / 1 gro u p used the !SP i n its A D U mode,
where the ISP simulator o perated as a console to
t h e ADU hardware system . The ADO consists of an
Alpha A X I' D ECchip 21064 processor, memory,
d i s ks, Ethernet, and a DEC:station 5000 workstation,
w hich acted as the console i n terface. I ns t ructions
that norm al ly execute on the s i m ulator were trans
ferred to the A D U fo r exec u t i o n . However, the
e nt i re symbo l i c debugging envi ro n me n t re m a inecl
u nchanged .

With m i crocode assistance on an un loaded VAX

Sim ulator Specifics

HHOO, i t takes from 20 to 30 m i n u tes to boot the

The !SP s i m u lator was written entirel y i n portable

Ope nV.\1S

C. The Man neq u i n simu l a to r was a hybrid of the

A X I'

system

and

reach

the

D igital

Com mand Language (DCL) prompt after logi n .

C++ and C l a nguages

Because o f t h is microcode speed u p , software engi

mate !\' 25,000 l i nes of code. Manneq u i n 3 1 ,800

neers were able to simulate and debug a m u ch

li nes The two s i m ulators shared common code:

l a rger part of the opera ting system and u ti ! it ies than

the JSP simu lator provided Mannequin w i t h float

ever before.

ing-point rou tines and a comprehensive instruction

182

Vol. . / No. 4

lSI' co n s isted of approxi

.

.

.\jJeciol lssue J ')'JJ

Digital Tecbuical journal

Using Simulation to Deuelop and Port Software

test p rogram ; M an nequ i n provided ISP with I/0

whereas Manneq u i n supports only the not- last
TLBs

device rou t i nes. Thus, the s i m u lators verified the

used

Alpha AXP architecture as wel l as each other.

a l lowed the operating system and chip design

The Mannequin and ISP s i m u lators tracked and
supported changes in the evolving Al pha A X P archi

(NLU)

algori t h m .

The

configurable

groups to analyze and fi nely rune the translation
lookaside buffers for optimum performance.

tecture and i n PALcode. I'ALcode is special machine
dependent software that provides support for

Performance A nazysis and Benchmarking

many low-level opera t i ng system services such as

The Man nequ i n a n d !SP s i m u lators a l so support

fau l ts

and

exce p tion s.

PA Lcode

a l so

p rov id es

execution of user-mode, stand-alone programs, i . e . ,

i nstructions not i n the base Alpha AXP hardware .

those with l it tle o r no operat i ng system run-time

The two simu lators have features c o m m o n to

support, by providing program loaders for several

many s i m u l a tors, i n c l u d i ng support for load i ng

formats. These formats include two U N I X object for

and r u n n i ng p rograms, sett i ng breakpoints and

m ats (CO FF a nd a.ou t), an OpenV.MS A X !' i m age for

watch points, accessing memory, and saving and

mat, and a system (raw data) i m age format.

restoring machine state. Also su p p or ted are many

machine- s pecific

features, such as I/O devices,

Programs were comp iled with early field-test
A lpha AXP compi lers. Program execu tion was espe

in terval ti mers, and configurable translation look

c i a l ly usefu l for hardware designers anti compiler

aside bu ffers. Besides a com m and l i ne i n terface,

wri ters fo r performance a n a l ys is and benchmark

the M a n neq u i n s i m u lator has a graphical w indows

i n g purp oses. Note that a p p l i c a t i o n s requ i ri ng ful l

i nterface that a llowed users to se e most m achine

operat i ng system support u secl rbe AL I D fac i l i ty,

resources i n a windows-based format, as shown i n

described in a later section.

Figure I .

The s i m u l ators can generate trace files i n a stan

The M annequin and lSI' s i m u l ators support three

basic devices:
•

the two fac i l i ties to share the same trace analysis
tools. The trace files ge n e r a t e d by Mannequin

A console device used for terminal I/O

and

•

A disk device used to boot the operating system

•

An in terval r imer used for interrupts

or

ISP were also used as i n p u t to the Alpha

Performance Model, another s i m u lator that gener
ated detailed perform ance data.
EVIUST and ALPHA$ REPORT were two tools fre

The disk device on the simul ators can be e ither
a file

dard trace file format. This common a l i ty enabled

a physical disk device. The O penVMS

group used a shared disk so that deve lopers cou ld

boot from a common disk while r u n n i ng on the
simulator.

q uen t ly u sed to ana lyze trace fi le s and generate
statistics conce rn i ng machine resou rces used d u r

i ng program execu tion. The types of data generated
by ALPHA$ REPORT i nclude the following
•

The s i m ul ators pr ov ide 16 megabytes (MB) of
physical memory with a defa u l t page size of 8 k i l o
byres (kH). The physical me mory of the simulators

•

•

D istribution of code block run lengths

•

Opcode pair d istribution by class

•

Control/branch instruction flow su m mary

amount for the actual s i m u l ator code).
B oth s i m u l ators have configurable i nstruction
stream ( 1- stream) and data stream ( D-stre a m) trans
lation lookaside bu ffers (TLBs). A TLB is a sma l l

cache that holds recent virtual-to-physical address

I nstruction a nd flo a t i n g- p o i n t register uti l iza

tion summary

m ay be i ncreased to t h e pr ac ti ca l l i m i t of ava i l ab l e
virtual memory on a VAX sy s t em ( m i n u s a sma l l

I nstruction d istribu t i o n by opcode, c lass, and
format

An actua l trace analysis report generated by

translation and protection information. The s i m u la

A LPH.A$ R EPORr is shown i n Figure 2. This example

tor TLlls can have a variable n u m ber of entries i n
each o f the fou r gran u l arity h i nt block sizes.

comes from a scaled version of FPPPP (one o f the 14

Granul arity hints indicate to the transl a t ion buffer

s u i te), with the co n s t a n t NATOMS set equal to 2.

bench marks i n the S PECfp92 floa t i ng- p o i n t rest

i m plementations that a block of pages can be

Figure 2 d isplays a report l is t i ng instruction d istri

treated as a single, larger page. I n essence, there are

bution by opcode.

fou r m i n itranslation buffers. The lSI' s i m u lator sup
ports

selectable

TLB

Digital Teclmical journal

replacement

Vr>l. 4

No. 4

a lgorithms,

.\j>I!Cial lssue

199.!

Alpha AX!' operating system developers ami com
p i ler writers rel ied heav i ly on the trace reports fo r

1 83

�

CfJ
.._,

'1;)
:r
Ill
Mannequ i n

EV1 : STATUS
UNAVAI LABLE

mi c rocode

0

updat e
t race

t race

f i

conso l e

ROO

u n a l i g n e d_t r a p s

ON

a r i t h m e t i c_t r a p s

ON

O F F

Le

A l pha

S i mu l a to r

c y c l e_c o u n t
run

�
�

""'

ON

s rm

4

h a l t_p a l

ON

d t b

EV3/ F I X= ( 4 , 0 , 0 , 3 2 )

i tb

/ F I X= < 0, 0 , 0 , 8 )

NONE
NONE

Log

00000000

R08

00000008

0 0 0 0 00 0 0

EV1 : GPR

00000000

R 1 6

00000000

00000000

R24

F F F F F F F F

F F F FE6 D F

R09

0 0 0 0 00 0 0

00000000

R1 7

00000000

00000000

R25

00000000

00000000

00000000

00000200

R1 0

00000000

00000000

R1 8

00000000

00000000

R26

00000000

00000000

00000000

00000000

R1 9

00000000

000501 08

R27

00000000

00000000

00000000

00040000

R20

F F F F F F F F

F F F F F FCO

R28

00000000

00000000

R03

00000000

00000000

R04

00000000

00000000

R1 1

ROS

00000000

00000000

R 1 3

00000000

00000090

R21

00000000

00000000

R29

00000000

00000002

R06

00000000

00000000

R 1 4

00000000

O O F F2800

R22

80000000

00000000

R30

00000000

01 000000

R07

00000000

00000000

R1 5

00000000

00000000

R23

00000000

00000080

R31

00000000

00000000

R 1 2

EV1 : MEMORY

POOOOOOOO

00050 1 C O :

A2C?OOOO

LDL

R22,0 ( R7 )

POOOOOOOO

000501 C4 :

42C0301 7

ADDL

R2 2 , # 1 , R23

POOOOOOOO

000501 C 8 :

B2 E70000

STL

R23 , 0 ( R7 )

POOOOOOOO

000501 C C :

951 E F FD8

STD

R8, F FD8( R30)

POOOOOOOO

000501 00 :

A1 1 E F FD8

LDL

R8, F FD 8 ( R30 )

000501 04 :

C 3 F F F FAC

BR

1 F F FAC

000501 08 :

45C070 1 9

AND

R1 4 , #3 , R 2 5

POOOOOOOO

000501 D C :

45C071 0E

B I C

R1 4 , #3, R 1 4

�

POOOOOOOO

000501 EO :

2 1 C E F FDO

LDA

R1 4, F F DO( R 1 4 )

�"'

POOOOOOOO

000501 E4 :

B1 0E002C

STL

R8, 2 C ( R 1 4 )

POOOOOOOO

000501 E8:

BOEE0028

STL

R7,28 ( R 1 4 )

POOOOOOOO

000501 E C :

B0CE0024

STL

R6,24 ( R1 4 )

'C
'"

tl

�:
�
�
"'

EV1 >

LOAD

SQUARE

%MQN :

l oaded

%MQN :

22

EV1 >

voooooooo
voooooooo
voooooooo
voooooooo
voooooooo
voooooooo
voooooooo
voooooooo
voooooooo
voooooooo
voooooooo
voooooooo

ROOT

vms

b l ocks;

f i le
entry

( E M T_0 0 : [ D A R C Y J S Q U A R E_ R O O T . E X E ; 1 )
a t

00000000

000501 08

1

<:!"
::

;;·
!:.

�

�
!:.

00000000

R01

POOOOOOOO

;c

00000000

R02

P-> POOOOOOOO

;;::-

STOPPED

p a l _d e b u g

(.r
"'::::'

�

�
,.,

0000000588

sta tus

EV1 : INST

"-

�

V 3 . 1 0-0

Figure 1

Mannequin Simulator Windows

00000000 :

203 FOOOO

00000008 :

205 F E 000

201 FOD04
2421 0001

0000001 0 :

209 FOOOO

24420001

0000001 8 :

40201 403

24840000

00000020 :

00000000

6BE30000

00000028 :

00000000

00000000

00000030 :

00000000

00000000

00000038 :

00000000

00000000

00000040 :

00000000

00000000

00000048 :

00000000

00000000

000000 5 0 :

00000000

00000000

000000 5 8 :

00000000

00000000

2:
;;

r"l
....
=
..,

(1)
Ill
::l
0.
[JJ
�
'Jl
....
(1)

3
'Jl

Using Simulation

ALPHA

I n s t ruct i on

FPPPP

--

Quantum

Stat i st i cs
chem i s t ry

Repo r t

to

Develop and Port Software

6-MAY - 1 992

ca l c u l a t i on

of

a

two-e l e c t ron

i n tegra l

de r i va t i v e

I n s t ruc t i on
( Ran ked

D i s t r i but i on

f r om

hi ghest

to

by

Opcode

Lowes t )
Cumu l a t i ve

Inst ruct i on
Occur rence

Percent

Pe r c e n t

C lass

Mnemon i c

6

LDT

2321 1 5 5

2 5. 41

8

MULl

1 732928

1 8 .97

40

8

ADDT

1 4 3 3798

1 5 . 70

60

6

STT

998446

1 0 . 93

70

1

LDQ

544385

5 . 96

1
1

LDL

241 1 42

2 . 64

STL

1 78828

1 . 96

4

BIS

1 5 1 1 20

1 . 65

3

ADDL

1 26321

1 . 38

8

SUBT

95045

1 . 04

Figure 2

Tbe AUD Facility
Whereas the Mannequ i n and ISP s i m u l ators were
su itable for i ni t ia l debugg i ng of low- level software
such as operating systems, d i rect use of these too ls
fo r user-mode appl ications, i .e . , layered products, is
a d i fferen t mat ter. Porting and debugging Alpha
A X P user-mode code is at best d i ffi c u l t without the
fu l l r u n - t i me support of a n operating system. User
mode appl ications typica l ly take advan tage of a
wide variety of run-t ime l i braries, i nc l u d i ng com
piled code support (su ch as the Fortran r u n - t i me
l ibrary), mathematical rou t i nes, graphics r;o ser
v ices, and database software (such as Rdb for
OpenVMS). Even if a l l this software were i m medi
ately ava i l able t()r Alpha AXP systems, r u n ning i t
under simu lation would be proh ibitive ly slow.
Therefore, Digital developed a m i xed-execution
debugging environment. This Alpha User-mode
Debugging Enviro n ment (At J D) was bu i lt from a
combi nation of new and existing Digital software
components. In the AU D environment, user-mode
code being developed fo r or ported to the Alpha
AXP platform could be comp i led and execu ted as

\I(Jf. 4 .Vu. 4

80

Mmmequin/!SP Trace Output

help i n design ing critical sections of code. For
example, the register usage d istribution report
helped determine how many registers sho u ld be
preservnl by a c a l l and how m a n y should be
scratch (usable by a cal led rou t i ne without being
preserved).

Digital Technical ]Our1w/

20

5/Jeci{l/ /ss//l! /')')2

Alpha A X P code using simul a t i o n on VA X hardware.
At the same time, OpenVMS VA X r u n - t i me services
cal led by the code could be execu ted as native VAX
i nstructions. Thus, modules could be ported and
debugged o n e at a ti me, u n t i l almost the e nt i re
application consisted of bug-free Alpha AXP code.
D u r i ng the design of the AUD environment, two
key techn ical issues were
•

How to efficiently detect cal ls made by execut
ing VAX code to a routine in Alpha A X P code that
could be " execu ted " only by s i m u lation, and
conversely, how to detect cal ls made by Alpha
AXP code bei ng s i m u l ated to native VAX code.

•

How to effect the transformation of parameters,
both location and representation, from that pro
v ided by the cal ler i n o n e dom a i n into the loca
tions and representati ons expected by t he ca I Jed
rout i n e i n the other dom a i n . Al though there
existed wel l-defined and widely f(J I Iowed cal l ing
standards for both domain s, a variety of spec ial
p u rpose, h igh-performance cal l i ng conventions
were used in many situations.

Th is m ixed-execution enviro nment was expected
to have a rel a t ively short l i feti me, because it wou l d
become obsolete a s s o o n as sign ificant nu mbers o f
real A l p h a A_,'\P l1ardware systems became avai l able.
Consequently, AUD itself hac! to be s imple and inex
pensive enough to he created quickly and p u t i n to
use. The deve lopment effort met this requ irement

1 8'5

Alpha AXP Architecture and Systems

The el apsed time from i n i tial concept to first use

fo rmat i mage as output. The standard VAX l i n ker

was about eight m o n ths; t h e total develop ment

can therefore refe rence locations i n the Alpha AXP

effort for AlJD over its l i fe time was between three

i mage

a n d fou r m a n -years.

OpenVMS i m age activator can be used to load the

in

the

normal

way,

and

the

standard

Alpha AXP image for execu t i o n . However, to m i n i

AUD Components

m i ze complexity, we cl id constra i n the Alpha AXP

Desp ite the desire for si mp I ici ty, AU D co nsists of a

im age to be l i n ked as a n absol ute i m age ( i . e. , a
based i mage, i n OpenV.V!S jargon ) . This restricti on

nu mber of cooperat i ng components:

e l i m inated the problem of how to relocate Alpha

•

Ca l l able Man nequ in Alpha Sim u l ator

•

Al iD debugger

•

Al !D i i nker

•

Al pha AXP na tive serv ices

•

VA X jacketing services

•

Al iD Lin kage Ana lyzer (ALA)

w h i c h executes as Alpha AXP code ( u nder s i m u la

•

Selected VAX jackets

eting services. The nat ive services p rovide the

AXP i nstructions using the OpenVMS i m age activa

tor. As mentioned previously, the Alpha AXP image
also in c l u de; a global storage area to hold the s i m u
lated Alpha A X P mach i n e state.

Alpha AXP Na til'e Serv ices

A l pha AXP n a tive ser

vices is a special operating system s he l l , part of
tion) a nd part of which is i nc l u d e d in the AU D jack
lowest -level support for hardware exception han

Callable Man nequin Alpha Simulator

Cal lable

d l ing and the OpenVMS conditio n - han d l ing fac i l i ty.

Ma n nequ i n , the Alpha AX!' i nstruc t i o n set s i m u l a

While AlJD u l ti m ately supported frame-based con

tor, is esse n t i a l l y a subset of the Mannequin si mu

d it i o n han d l in g w i t h i n the Alpha AXP im age, i nter

lator

operation of appl i c a t i o n exce ptions between the

descri bed

earl ier.

In

particu lar,

Cal lable

M a n n e q u i n omits the user i n terface and Alpha fu'\ P
machine stare. I nstead , the AUD debugger suppl ies
the user i nterface. A lso, sto rage fo r the A l p h a AXP

Alpha AXP ami VA X domains was not suppo rted .
li,4X jacketing

Serl 'ices

VAX jacketing serv ices is

machine stare is separately l i n ked i n to the AUD

VAX code that supports the abi l it y to write jackets

env i ro n me n t to m a k e this i n formation globa l ly

that pass c o ntrol back and fo rth between VAX and

accessible. Cal l able Mannequin does ret a i n the

Alpha AXP code. The mechanics for accompl ishing

microcode-assist fea ture.

this are d iscussed i n t he .Jac keting section.

AUD Debugger

The Al lD debugger is a m o d ified

version of DEBUG -32, the user-mode debug u t i l i t y

AUf) Linkage A natvzer

The A I .A is a speci a l i zed

compi ler t h a t reads a special i zed jacket description

on t h e OpenVMS VAX opera t i ng system. T h e AUD

la nguage. This language describes how cal ls in

debugger provides most of the same features of

one domain are to be transformed i n to cal ls in the

DEBUG-:)2

A

co nfiguration

DEBl l ( ; - :)2 u t i l i t y to use a n

option

a l lows

internal.

the

other doma i n on a rou tine-by-rou t i n e , parameter

low- level

by-parameter basis. The o u t p u t from the ALA is

remote debugger in terface to i n te rface w i t h a fo r

an Al pha A XP object modu le and a l i nker options

eign target. (Th is capab i l i t y was origi n a l l y devel

con trol file, both used to link the Alpha AXP i m age,

opecl for use in other products such as VA XELN

and a VAX object m o d u le . The A l p h a AX P object

Ada.) We developed new code to join DEBlJG-:)2 ami

m o d u l e provides a transfer vector i n to the Alpha

Ma nnequin using t h is interface. As a resu l t , the AlJD

AXP procedu res. The l i n k er options con trol file

debugger works d i rectly w i t h VAX code, i n the

provides symbol defi nitions i n a n e ncoded for m to

usual m a n ner, a n d works with Alpha AXP code by

manage cal ls from the Alpha AX!' i m age to the m a i n

passing com m a nds to the Cal lable M a nn eq u i n simu

VAX i m age, which i s l i n ked later. T h e VA X object

l atOr to set brea kpoints, exa m i n e i nstructions, exe

mod u le contains a table that encodes the j ac keting

cute code, etc.

descripti o n .

A UD /Jnker

The AliD l i nker i s a variant of the

Selected VAX jackets

Selected VAX jackets a re A LA

Alph a A X P cross l i n ker that reads A lpha AXP object

jacket ing files (in both source and compi led fo rms)

modu les as i n p u t and produces an OpenVtvlS VA X

h>r ca l l i ng common VA X fac i l. i ties from Alpha AXI'

1 86

11!1. 4 No. 4

SjJecial /sslle 1')92

Digital Tee/m ica/ journal

Using Simulation to Deuelop and Po rt Softwa re

coue . Jackets are provided fo r Open VMS system ser
vices, the C run-time library, anu some parts of the
gene ral-purpose, run-time l i brary (LIHRTL). The
DECwinuows group also suppl ied jacket defi n i t ion
files for use by other groups. AUD users are able to
su pplement these fil es as needed by creating and
comp i ling their own jacketing descriptions fo r
other VA X facil i ties.
Figure 3 shows the main steps in build ing an AUD
envi ronment. The uppermost sequence shows the
compi l a t ion and l i n king of the Al pha AXP com po
nents, wh ich results in the creation of the Alpha
AXP image. The central sequence shows the compi
lat ion of t he jacket descriptions, which res u l ts i n
the creation o f components that are incluued i n
both the Al pha AXP a n d the VAX im ages. The lower
rows of Figure 3 show the compi l ation of the VAX

ALPHA AXP
PART OF
A P P L I CATION
PROGRAM

�

ALPHA AXP

COMPILER

r-

ALPHA AXP
OBJECTS

part of an appl ication and its I i n king with the AUD
manager to create the VAX main i mage. \Vhen the
mixed VA X and Alpha AXP appl ication is executed,
these i mages are combined in memory with
Cal l able Mannequ i n , the AUD debugger, and other
shareable i m ages. This relationship is i l l ustrated in
Figure 4 .

jacketing
Jacketing is the key fea ture that a l lows VAX and
Alpha AXP interoperability, i . e . , gives a p rocessor
the appearance of being able to execute both VAX
and Alpha AJ(P instructions. Although the details of
jacketing are int ricate, the resu lt is si mple and e l e
gant. Calls can be made freely back and fo rth
between VAX com piled code and Alpha A X P com
piled code, without any special compi lation modes

�

ALPHA AXP
LINKER

ALPHA AXP
JACKET
OBJECTS

JACKET
DESCR IPTIONS

r-

L1

VAX PART OF
APPLICATION
PROGRAM

r-

VAX
COMPILER

r-

ENVIRONMENT
MANAGER

r-

VAX
COMPI LER

r-

Figure 3

1-

VAX

LOADER

VAX
JACKET
OBJECTS

Vul. 4 No. 4

ALPHA AXP
IMAGE

i
l

JACKET
COMPILER

n
VAX
LINKER

Digital Tecbuicaljourual

r-

VAX
OBJECTS

VAX
OBJECTS

L1
r--

r-

VAX
IMAGE

DEBUG
IMAGE

CALLABLE
MANNEQUIN
IMAGE

-

VAX

MEMORY

r-

f----

1-----

Creating an A UD AjJjJlication

Special issue

] ') <)2

1 87

Alpha AXP Architecture and Systems

ALPHA AXP
LINK

VAX
LINK

l
I
I
I
I

ALPHA AXP
COMPONENTS
ALPHA AXP
COMPONENT SERVICES
ALPHA AXP
MACHINE STATE

t
AUD AND JACKETING
TABLES

VAX COM PONENTS

I
I
I
--I

CALLABLE MAN N E Q U I N

I
I --I
I
I

AUD DEBUGGER

OTH ER I MAGES

MAIN I MAGE

Figure 4

on either side. The Al J D support is fu l ly rec ursive

I
I

SHAREABLE LIBR A R I ES

A UD Process

ancl reentrant.

I

Components

an A l p ha A X P rou ti n e . According to the VA X a rchi
tecture, the first 16 bits of a rou tine comprise a

Static cal ls from VAX to Alpha AXP code are

mask that encodes the registers to be p reserved as

directed to d u m my e n try points in the object mod
ule procl uced by the ALA comp i ler. Each ent ry point

u nused and requ i red to be 0: if one of these bits is

is simply a n in struction that loads a poin ter to the

set at t he time of a ca l l, then a hardware except i o n

part of the cal l . 13its 12 and 13 of this mask Jre

jacket i ng description table for tbe target Alpha A XI'

res u l ts. Accord ing t o the OpenVMS A X P software

procedure, fol lowed by a transfer into common

architecture, an Alpba A X P p rocedure address is

jac ket i nterpretation code.

actua l ly the address of a p rocedure descriptor,

Cal l s from Al pha AXP code to VAX code use

w h ich is a data structure and not the actual Alpha

the fac t that the Cal lable Manneq u i n component
stops and ret u rn s control to the r\l ! D environment

f\ X P code. By design, hits 12 and 1 3 of this data
structure must be set to 1 .

when it detects a n instruction that transfers control
out of the Alpha AXP i mage . In t h is case., the appar

VAX exec u tion of J VA X CALL instruction that
attempts to transfer to a n Alpha A X I' procedu re

e n t address is an encoded i nteger (created by t h e

res ults in an exception. A special AUD excertion

ALA), wbose high fo ur b i t s m a k e i t l o o k I i k e a n i l le

hand ler i n tercepts the exception, determines if the

gal add ress (in the VA X reserved S l space) and

i l legal entry mask i s caused by a reference i n to an

w hose remaining hits are a two- level in dex ( i . e . , 12

Alpha AXP i mage, and if so, calls i nto the Al J D jac ket
ing routines to reformat the call frame. This mecha

bits of fac i l i t y code and 16 bits of offset) i nto the
jacket description table for t he target VA X p roce
d u re. This two- level scheme was chosen to allow
jacket descriptions for differen t shared l i brary fac i l

nism a lso works for hand l i ng asynchronous system
traps (ASTs) from the O penVMS VAX opera t i ng
system to Alpha AXP code.

i t ies to be p rerared and compi led i ndependently.

For compu ted c a l l s from Alpha A X P code, com

The facility code is a n u m be r normally a l ready asso

pi led code ca l l s an Alpha AXP r u n - time l ibrary rou

ciated with that facil i t y by software conve n t i o n for

tine to perform the comparable b i t 13 rest (u nder

other pu rroses.

simu lation). I f hit 1 3 of the targe t location is set t o 1 ,

determined address. such a s an address given in a

then simu lated execu tion c o n t i nues and an A l pha
ro-Aipha call is carried o u t. Otherwise, con tro l

When a rou tine is called using a dynami c a l l y
fu nction vari a b l e , a property of the VA X and Alpha

trans fers to

A X P arch i tectures is exploited to determi ne dynam

which terminates simu lation and performs jacket

ically whether the target rou tine is a VAX routine or

ing back to the VAX target procedu re.

1 88

l·r>l.

Xo. 4

a

spec i a l VAX code en try point in AUD,

Special Issue 1'.!')2

Digital Tee/mica/ jou rnal

Using Simulation to Deuelop and Port Sojtware

Basic Opera tion

suppl ies w h e n i t sets up a VA X- to-Alpha c a l l ( i . e . , an

To start exec u t i ng a m i xed appl icat i o n , the AUD

a d d ress i n the reserved

e n v i ronment first pe rforms several i n i t i a l iza t i o n

space), the a d d ress is i n terpreted as a re turn trans

Sl

part of the VA X address

steps. l n part icu lar, Al J O s c a n s a l l the i mages loaded

fer. Otherwise, AliD i n i t iates a new Al pha-to-VAX

in process m e mory to ident ify the Alpha A)( p i mage

cal l .
For a re turn opera t i o n , the AL I D code copies the

(only one was a l l owed and supported).
Some AU D o p t i o n s are set t h ro u gh the use of

retu rn value o r val ues from the Alpha A X P registers

O r e nVMS logical n a mes, which are i n te rrogated

and passes them back to the VA X code. A VA X ret u rn

du r i ng i m age i n i t i a l iza t i o n . These options i nc l u d e

i n struction is t h e n executed to resu me exe c u t i o n

•

of the cal l ing VAX cod e .

Selecti ng Alpha A.XP stack size

F o r a c a l l opera t i o n , the VA X cocle fe tches the

•

Enabl i ng del ivery of ASTs to Alpha A X P rou t i nes

•

Disabl i ng the n o r m a l Alpha AXP stack consistency checks

•
•

•

Alpha AXP parameters and b u i l d s a VA X argu ment
J ist, which is t h en used to ca l l the target VA X rou
t i n e . When the VA X rou tine returns, the contents of
t he resu lt registers are copied to the corres ponding

Disabl ing u n a l igned me mO!)' reference messages

Alpha A X !' machine state locations, and Man nequ i n
i s restarted to res u m e execu t i n g A l pha A X P code.

Enabling AlJD i n i t i a l ization tracing

Despite some l i m i t at ions ( e . g . , o n l y one Al pha
image and no exce p t i o n hand l ing across the VAX to

D isabling i nteger overflow chec k i ng

Alpha
Debugging combi ned VA X and Alpha A X P code

AXP

d o m a i ns),

gre a t l y

AU D

a ided

the

Ope nV,VIS AXP porting effort. The s i m u l ator p ro

under the AlJ D env i ronment is s i m i l a r to debugging

vided software groups w i t h

n o r m a l VA X code under the DEBLIG-32 OpenVMS

environment i n wh ich to d e b u g their A l p h a AXP

debugger. Basical l y, if the add ress i nvolved in a

code, wel l before ei ther Alpha AXP hardware or the

a

pseudo - A lp h a A X P

debug command is w i t h i n an Alpha AX P i m age,

Ope nV,VIS

then the deb ugger cal l s the Manneq u i n s i m u l a tor to

M a n y O p enVMS A X P groups successfu l l y used AU D

pe rfo r m the command for the Alpha AXP code.

to fac i l itate their porting. i n c l u d ing the Record

AXP

operating system was

avai l ab l e .

Otherwise, the OEBUG-32 debugger i t s e l f performs

Man agement Services (RMS), DECwindows. Forms

t h e com mand for the VA X code, as usual. Alpha AXP

Management System

mach i ne state is kept i n static global storage by

mand u t i l ities, text process i n g u t i l ity

Mannequ i n and t hu s is v i s i b le to the AUD debugger.

and G EM c o m p i l e r back-end groups.

(F;VIS),

various OpenVMS com

(TI'll),

D E BU G ,

ln t he DEBUG symbol t a b le (DST) represe n t a t i o n ,
variables t ha t a r e a l loca ted i n the Al pha AX P regis
ters are desc r i bed as being a l located in the co n-e

The AVDI Facility

" t rick"

The VAX Environment Software Tra nslator (VEST) is

a l lowed AlJ D to hand le the 64 A l p h a A..,'C P registers

an important p a rt of t he i n i t i a l Open VMS AXP offe r

using

i ng.> VES'T' translat es a n OpenVMS VAX exec u t able or

spond i ng
the

global
VA X

state

DST

loca t i o ns.

This

representat i o n ,

wh ich

can

shareable i m age i nto a n Ope nVM.S A.XP im age that

encode o n l y the 16 VA X registers.
Once si m u l ation begins, Mannequ i n conti nues to

can then be execu ted with sup port on an OpenV.viS

s i m u l a te A l pha A..,'C P i n s t r uctions u n t i l it either

AXP syste m. As for other u s e r-mode l ayer software

detects an in structi o n that wou ld transfer control

componen ts,

outside of the Alpha A X P i mage, compl etes a single

i m ages transl ated by VEST as early as possible in a

it was desirable to test VEST and

step request, or detects an error c o n d i t i o n . Upon

s i m u l a t i o n e n viron ment such as Al! D . However,

return i ng to the AU D enviro nment, Mannequ i n sup

AUD cou ld not be used d i rectly to test translated

pl ies status info rm a t i o n that i n d icates the reason

i mages fo r t wo reasons:

s i m u l a tion ended.
For a transfer of contro l from Alpha AXP to VA X

•

code, AU D m u st first determ ine whet her t h e tra ns

Thus, the symbol m a p p i ng protoco l s used by

fer is a return from A.l rha A X P code as a resu lt of a

AUD were extraneous, and the l i nking protoco l s

prior VA X ca l l or a new call from Alpha A X P code to

h a d t o b e completely re pl aced.

VA X code. Al J D is fu l l y ree ntrant, so AUD cannot

make t h i s determination from global state. lf the
target address i s a d istingu ished a d d ress that AUD

Digital Techntca l ]ournal

Vol. 4 No. 4

Special Issue 1992

VES T d irec t l y creates an Alpha AXP i mage. In
effect, VEST is a combined com p i ler and l i n ker.

•

Actual
an

exe cution

Op enVMS

A XP

of a

t ransl ated

system

m a kes

i m age

on

use of the

1 89

Alpha AXP Arc hi tecture and Systems

Tra n s l a ted Image Environment (T I E) . ' The TIE

avai lable dur ing exec u t i o n , si nce t r a n s l a ted code

t i n <: s for transla ted i m ages. I n p a r t i c u l ar, TIE

occupi es differe n t a d d ress space t h a n the origin a l

provides support for VAX complex i ns t ruction

VA X code. Thus, register R 1 '5 is used instead a s an

processi n g, VAX- to-Alpha address m a p pi n g, and

i n - i m age i ndex register.

OpenV,\1 5 VA X exce p t ion hand l i ng. Creat i n g a

The user-mode VAX stack is spl i t i n t o a VAX stack

VAX version of the TIE to use with AUD requ i red

a nd an Alpha and e m u l ated VAX s t a c k . The VA X

i n t i mate i n t e rfaces w i t h the Open VMS VAX oper

stack serv ices both the AU D I enviro n ment and a n y

a t i ng system as wel l as c o m pa t i b i l i ty w i t h A U D .

VAX s y s t e m s e r v i c e s or ru n - t i me l i brary rou t i n e s

Thus, t h e n e e d to d e b u g tran slated i mages l e d to
the creat ion of the A l p h a User-mode Debugging
Environment for Tra n s l a ted Images (AlJDJ). Just as
Cal lable Manneq u i n provi d ed a key b u i l d ing block
fo r Al J D , Al J D in turn provided a key b u i l di ng block
for AUD I . Alpha A X I' software teams and porting
centers used AU D I to port both Digi t a l and third
party translated appl ications prior to the arrival
of Alpha AXP hardware. The porting process was
as fol lows: a VAX a pp l icati o n was translated to
Al pha AXP code by means of the VEST translator;
t h i s code was then run o n a VAX system u s i ng the
AUDI simu lator.
The Al iDI process com ponents shown in F igure 5
i n c l ude the
•

equ ivalent VAX program counter (PC) is not di re c t ly

is a shareable l ibrary that contains support rou

t h a t the t r a n s l a ted i m age m ay cal l . The Alpha ami
em u l ated VA X stack serv ices Alpha AXP a n d trans
l ated code .
Tra nslated i mages co n t a i n c a l l s t o the TIE a s nec
essary t o s i m u late VA X complex i nstructions and
p ro c e d u re c a l l s . Complex i ns t r u c t i o n ro u t i nes are
used to s i m u late VAX i n stru c t i o n s that would o t her
wise

expand

into

excessive

Al pha

AXP

code.

However, s i nce AUDI is run ning on VAX hardware,
comp lex instructions can be executed native on the
VAX hardware .
To i n i t i a l ize t h e AUDI environmen t , the translated
i m age c a l l s an i n i t i a l izat i o n rout ine i n t he TIE by
means of an i n i t ia l ization program section (PSECT).
This rou t i n e determi nes the address range of the
Alpha AXP code and the location of the VA X-to

Ca l lable M a nnequ i n Alpha s i m u l ator

AJpha address m a p p i ng s t r ucture, saves t he cu rrent
Al pha AXP register state, and cal l s Mann equ i n to

•

AUD deb ugger

•

VAX version of the TIE

e n try po i n t . Tra nslat ed code u s es the address m a p

•

Translated VAX code (Alpha AXP code)

p i ng s t r u c t ure to find compu ted branch dest ina

begin exec u t i ng transla ted code at the appropriate

tions on t he fly. Ca l l able M a n n e qu i n then exe c u te

A UDJ Environment

t r a n s l a te d cocle u n t i l it encounters some i n s t r uc

Emu lated VA X state i n AUDI is m a i n t a i nell i n a global

t i o n t h a t wo u l d transfe r control out o f translated

co ntext block. E m u l ated VAX registers RO t h rough

code. The cause o f this transfe r wo u l d be either a

are used exactly as their VAX c o u n terparts.

T I E-based proced ure or complex in struction cal l , or

R 14

The

correspondence between a

translate d a n d

c a l l s to n a t ive VAX routi nes.

l

O R I G I NAL V A X CODE
AND
TRANSLATED VAX CODE
(ALPHA AXP CODE)

TRANSLATED IMAGE

I
I
I

TRANSLATED I MAGE
ENVIRONMENT {TIE)

CALLABLE MANNEQU I N

AUD DEBUGGER

OTHER IMAGES

I

I
I
I

A U D I ENVIRON MEN T

Figure 5

1 90

AUDI Process Components

Vol. 4 No. 4.

Spl!cial lssul! 19').!

D igital Teclmicaljournal

Using Simulation to Develop and Port Software

L i ke

AUD, A l J D !

translated

not fu n c t i o n properly. For o u tgo ing cal ls (trans

a llows in teroperation between

code (Alpha

VAX

AXP

code) and

code. Transla ted code can use existing

VAX

lated

VAX

VA X

code to

VAX

code), routines i n which

a callee modifies its cal ler's stack frame argument

system

does not use

l ist o r return add ress may produce u n p redictable

the jacke t i ng la nguage described in the section The

resu lts. since the au tojacketing may be a l tered or

services and r u n - t i me l ibra ries.
ALID

Fac i l ity. I nstead,

AUDl

AUDI

and the native

VAX

cl isconnected.

a u tomatica l l y jackets

proced u re cal l s between the transl ated

code

VA X

AUDI Example

code. Au tojacketing i ncl u d es

bu i l d i ng proper para meter l ists and c a l l frames for

Figure 6 shows the exec ution of a trans lated im age

the desti nation cal l i ng standard.

under

The fact that

AUDI

does not u s e a jacketing lan

AU D I .

Note

(HELLO_WORLD)

that

both

and the

BASIC:

the

BASIC

image

r u n- t i me l i brary

guage leads to s o me procedure cal I lim i tations.

(BASRTL)

However, n o te that these l i m itations do not appear

used by the AUDI environment cannot be translated

when r u n n i ng translated code o n actual Alpha

under AU D I . Transla t i ng r u n - ti m e l ibraries that Al ! D I

AXP

hardware . For i ncom i ng calls

translated

VAX

code), all

hand lers execu te as
lated

VA X

$

A S T del ivery

VAX

(VA X

itself uses causes a " c i rc ularity in activa t i o n ·· and

code to

and condition

incorrect or no execut i o n .
I n the

code rather than as trans

code. Thus, translated programs m ay

RUN

HE LLO

WORLD

He l lo

Wo r l d

f rom

AUDI

V3 . 0

8085

AXP

i n

28

VAX

There

i ns t ru c t i ons

2 1

CALLx

There

to

returns
were

no

1 9

were

CALLx

rout i nes :

4

5

0

rou t i n es :

28

0

0

Tota l :

32

5

0

used

(28

RET,

0

B locks

T I E- ba sed

were

RSB)

' c omp l e x

MOVC3

C 28 )

8

Instruc t i on

MOV C 5

C 2 C )

8

Inst ruc t i on

MOVTUC

C 2 F )

1

There

were

2

i mages

ca l l

to

contai n i ng

A l pha
A l pha

H E L L O _W O R L D _T V

XO . O

f r om

BASRTL

f rom

BL3 . 3

VEST

these

i ma g e s :

TV

Execu t i on

XO . O

depended

on

-

B L3 . 3

AXP

VEST
of

of

Ma r

DECW$XLIBSHR

M T H R T L_T V

DE CW$TRANSPORT

TI E$SHARE

VAXC RTL

MQN$S HARE

MTHRTL

DECW$DWTLIBSHR

CONVSHR

LBRSHR

SORTSHR

LI BRTL

and

were

AXP
to

code .
Lookups .

reused

7

t i mes .

executed .

code .
code :
Ma r

30

30

1 992

09 : 2 7 : 02

1 992

09 : 1 4 : 1 0

COMMON

LIBRTL

LIBRTL2
DBG S S I S HR

A UDI Emm.pte- Translated Hello World Image

Figure 6

Vu/. 4 ,,.( ,.

wh i c h

AXP

L I B R T L_ T V

Digital Tee/mica/ journal

A l ph a

conver t ed

i nst ruct i ons '

I n s t r uc t i on

ro u t i ne

r e s u me

a l loca ted

2

VAX

to

cond i t i on s

C O E )

1

JMP

VAX

INSQUE

was

J SB

AXP

I n s t r uc t i on

There

example, there a r e 2 H c a l l s

executed .

Lo o k u p s :

F a u l t-On- E x e c u t e

Context

were

H EL LO_WORLD

ro u t i nes, m o s t l i kely those to

S t at i st i c s :

A l pha

Went

VA X

BAS IC

TIE
S t a y ed

to

TV
VAX

Runt i me

A l pha

are translated . R u n - t i m e l ibraries that are

/t

,\jH!cial Issue !')')2

191

Alpha AXP Architecture and Systems

services. There are 2 1 u n i que

Murphy, Scott Robi nson, Larry Woodman, and

CALLx contexts and 7 reused ones. In addition, the

James Woold ridge. Final ly, m u c h of the A DI
information i n this article is taken from work origi

Op enVMS system

example uses fou r d i ffere n t comp lex i nstructions.

n a l l y clone by Scott Robins o n . Other AliDI contribu

Summary

tors i n c lude George Darcy, Mark Herdeg, M a tthew

The software s i m u lators Mannequ i n , ISP, Al ii). ancl

Kirk, Naghmeh Mirghafori, and Mur a r i Srinivasa n .

A! J D I greatly a ided Al pha AXP software porting

ami development efforts. Substantial parts of both
system and a pplication software were s i m u la ted
and ve rified concurrently with hardware devel op
ment.

References
I . R.

When Alpha AXP hardware became avai lable,

most software cou ld be plugged i n s i m ply and ran

Sites, eel . , Alp/Ja Architecture Reference

Man ual (Burlingto n . :VIA: D igita l Press, 1992)
2. C Thac ker, D. Conroy, and L Stewart, " The

exactly as ex pected. The use of t hese simulation

Alpha Demonstration Unit: A High-performa nce

tools saved a year or more from the overa l l A l p h a

M u l t iprocessor fo r Software ami Chip Devel

AX!' sched u l e .

opment." Digital TechnicaiJounwl, vol . 4, no. 4

Acknowledgments
Many people throughou t Digital con tributed to the

( 1992, t h is issue) 'i l-6'i

:). Open VMS

(Ylayn:ml

su ccess of the Alpha AXP s i m u la tors. Hom:1yoon
Andrew Payne, ancl Jon Reeves worked on the ISP
Eric Rasm usse n , and Scott Robinson contributed to

klanual

Corporation,

4. S. Mishra, ''The VA X H800 Microarc h i tecture,"
Digital Teclm icalJournal, vol . L no. 4 (February
1987): 20-:):)

the Manneq u i n si m u lator. The Al l D effort i n c l uclecl
several gro u p s from across D igita l . Their pri mary

Utility

Equ ipmen t

Order No. A A-PQYPA-TK, 1992)

Ak h ia n i , Ray Lanza , Stephan Meier, Steve Morr is,
model . George Da rcy. Mark Herdeg, Kevin Koch,

Delta/XDel ta

Digita l

'i

R. Sites, A. Chern off, M. Kirk, M. Marks, and
S.

Henry Grieb, Mark Herdeg, M ichael lies . .fa mes

Tecbniutl.fournal, vol . 4 , no. 4 ( 1992, this issue):

Jo h nson. Robert Landa u , Maurice Marks. Dennis

137- 1) 2.

1 92

Robinson .

v£,1. 4 .\'n.

4

" Bi nary

Special Issue JV92

Translation,"

D(!{ital

contribu tors were \Va l r e r Arbo, Ronald Brender,

Digital Tech11ical ]ou nwl

Peter F. Conklin

Enrollment Management,
Managing the
Alpha AXP Program
Digital's mult()'ear Alpha AXP program has involved more than two thousand
engineers across many disciplines. Innovative management styles and techniques
were required to deliver this high-quality program on an aggressit'e schedule.
The Alpha AXP Program Office used a four-point methodology for management:
( I) establisb an appropriately large shared vision, (2) delegate completely and
elicit specific commitments; (3) inspect rigorous�)� providing supportive feed
back; (4) acknowledge euery cu:lmnce, learning as the program progresses.
We consciously used each project event to propel progress and gain momentum.
Digital delivered the Alpha AXP program on schedule with industry-leadership
capabilities.

Introduction
The program to develop the Alpha A X P systems
has been the l argest i n Digital's histo ry and one
of the largest i n the computer i ndustry. D u ring
the cou rse of the program, the Alpha JL'(P Pro
gram Office developed a model that provided the
tools necessary to manage the progra m . At t imes,
t h is paper may seem to imply that the program
team developed the tools and then used them in
a p u re form. In practice, the team deve loped these
approaches based on many years of experience and
on the management theories of exp e rts; we a lso
learned and a p r lied these lessons as we m anaged
the program .
AI though the posi r ive effects of timely del ivery
and high qual ity are particu larly noticeable resu lts
of such a l arge program , Digital has al so used the
tool s to good effect on s m a l ler p rojects. Moreover,
teams within the Alpha AXP program used the tools
recursively, project by project. The author's experi
ence is that this management m odel is applicable to
projects of nearly any size.
The d iscussion that fol lows briefly defines the
scope of the program and exp l a i ns why tradi t io n a l
methods were i nappropriate for m anaging the
development of such a complex product set in a
short t i me period. The E n ro l l ment Ma nagement
Model and the concept of cusps-a key element of
the model-are then defined and c larified th rough

Digital Technical]our11al

Vol. 4 No. 4

Special Issue 1992

discussion of the model 's evo l u tion d u ring the
Alpha A.XP Program .

Size of the Alpha AXP Program
Digita l's Alpha A X P program encompassed the
design of a world-leadership m icroprocessor ch ip,
a new 64-bit system architecture, m u ltiple hard
ware systems (from p erso n a l compu ters to m ain
frames), m u l tiple operating systems, and hundreds
of software products l ayered on these systems. The
development of the first-generati o n products
extended over seve ral years and involved more than
two thousand hardware, software, and systems
engineers at its peak. D igital ma naged the overal l
development program from a Program Office
staffed by eight professionals.
Across Digital worldwide, the Alpha A X P pro
gram development spanned m o re than 22 software
enginee r i ng groups ami 10 hardware enginee ring
groups. The hardware effort i nclud ed the sem icon
d uctor design group and groups for each of the
hardware systems p l atforms. The software efforts
encompassed fou r opera t i ng systems groups, and
groups design i ng m igration tools, network sys
tems, compilers, databases, i n tegration frame
works, and applications . Some groups peaked at
more than 150 development engi neers plus sup
porting staff. Many also contracted with suppl iers
both within and outside D i gitaL

1 93

I

Alpha AXP Program Management

PE RSONAL
PUBLIC

Inappropriate Organizational Approaches
I m plementing such a broad , com p l ex program pre
s e n ted not o n l y technological chal l enges b u t a man
agement c h a l lenge as w e l l . The Program Office
the refore co nsidered a n d re j ected a n u m be r o f tra
d i t i onal organizational a p proaches. 1
In the c l assic organ izational model, a h i e rarchi

I N S PECTION
SUPPORT

ca l , o r l in e , organ i zation i s fo rmed , cont a i n i ng a l l
the p rima r y i m p lementers The p roblem with t h is
approach to l a rge programs is that it ta kes to o long
to fo rm the organ izati o n . Staffing the rea ms a n d
establ ishing operat i o n a l proced u res take l o nger

REVIEW
E N C O U RAGEMENT

TRUST
ACCOUNTABILITY
(TAS K-OWNER-DATE)

than the m a r ket w i n dow and available tecllllo logy
a l low. The res u l t is gra n d visions and projects d e l iv

Figure I

ered years behind sched u l e . Further, " temporary"
organ i zations must be folded back i n to t h e ma i n 
stream at the e n d of the program. The management
goa l of the Al p h a A X P p rogram was to keep ex per
tise concentrated to ach ieve synergy across manv
projects within a part i c u l a r discipl ine z
An

a l ternative

a p proach

is

to

form

sm a l l

ent repren eur i a l teams and chal lenge them t o wo rk
lo ng hours to achieve the goa ls. This wo rks wel l in
sm a l l projects s u i t able fo r " sku n k works." The origi
n a l design work was condu cted i n t h is fash i o n .
Howe ve r, w h e n t h is approach i s a p pl ied to l a rge
programs, the res u l t is that team members b u rn o u t
without

achieving

the

aggressive

schedu les

d e m a nd ed . Man agement then becomes frustrat ed
and t r ies again with d i ffe rent teams. but the resu lts
are no bet ter.
The Program Office establ i shed the A l p ha A X P
program a s a n i n tegra tion o f project teams that
wou ld re m a i n w i t h i n the existing l i n e orga ni za
tions. Thus, fo r example, each hard ware and soft
ware p roject re sided wit h i n its fu nction a l group
(semiconductors, servers, OpenV,vi S , I J N I X . compil
ers, database, CPU d eve lopment, networ ks, e t c . ) .
The Program Office i n tegrated the work of t h e i n d i
v i d u a l project teams, wh ich provided t h e a d d i 
t i o n a l advan tage of program res i l ience i n the face of
fu nctional group reorgan izations.

The Enrollment Management Model
The Enro l l ment Management Model (Figure 1 ) for
the Alp h a AXP program com prises four stages.
Vis i o n - En r o l l m e n t
Com m i t ment- Delegation
Inspection - S u p port
Acknm.vledgme nt-Learning

1 94

The

En ml!m ent Jlllcm agement ;1!/ode/

model

in

this

fo rm

was developed

by

the au thor. Some e lements are de rived from man
agement semi nars a n d from consu ltants' recom

mendations. The partic u l a r fo rms used fo r vision.
c o m m i tment, a n d acknowledgment emerged d u r
i ng the

Al pha

A X !'

p rogra m .

The

i n spect i o n 

s u p p o r t stage w a s d e velo ped b y the au thor d u r i ng
m a n y years of project m anagement and reviews.
Two concepts are key to i m p l e m e n t i n g t h i s
m o d e l fo r l arge programs. F i rst, the Program Office,
which has a l ready been m e n t ione d , pro\' ides the
necessary cohe s i o n , program vision, and i n spec
tion

structu res,

w h i le a l l owing the

s k i l l s and

re s o u rces to rem a i n within their n a tu ra l o rga n i za
tions. Moreover, t he office lends consistency ac ross
t h e program and encou rages each contri b u t i n g
group to hold to i t s c o m m i t m e n ts. The sm a l l Alpha
A X P Program Offic e , made u p of a d i verse group of
p roduct and opera t ions m a n agers. h a d no for m a l
au thority (not even bu dget a u t hori ty); s o it exerted
i n fluence o n l y t h rough rigorous enro l l m e n t and
delegation ou tl ined by t he ma nagement model .
The second k e y concept is the project "cusp,"
wh ich is a critical event that p ropels ch ange. Cusps
are fu rther defined in the sections I n spection
Support and Using Project Cusps below.

Vision-Enrollment
The Program Office uses vision to e n ro l l the related
groups in the goa l s of the progr a m . For exa m pl e ,
t h e v i s i o n can b e t h e top- leve l busi ness goals and
customer neecls.

For subord i nate

projects,

the

vision can be the objectives of the l a rger project. I n
a l l cases, the enro l lment happens o n l y w hen the
go a l s are set i n the context of t h e aud ience (the
project team). In p a r t i c u l a r, the Program Office is
most effect ive when i t expresses the program's

v'tl/. 1 .\'o. 4

.\j;ecial lssue !')'Jl

Digital Tecbuical journal

Enrollment JV!anagem.ent, Managing the Alpha AXP Pmgram

vision in the terms and language of the group being
enrol led . The vision has to be large enough to
encompass a l l the requ i red com mitments and the
u l t im ate resu lts.

Commitment-Delegation
As the manager of a project develops plans, he or
she delegates t he tasks to sub-groups and sol i cits
specifi c comm itments to content and sche d u le _;
Since these com m itments are made within the con
text of the larger vision, the subordi nate c o m m i t
ments become qu i te strong for sub-project
members. A key e lement of the delegation process
is the expl icit specification of t he resu l ts such that
they are measurable and identified with a n individ
ual owner. The owner is a single individual empow
ered by the comm i t ti ng gro u p a nd held
accountable for the del iverable. ' An important
point here is that the term "owner" does not neces
sarily refer to the p e rson who actua l l y does the
wo rk . The owner is responsible and therefore
accountable for getting the work done on rime. In
our particular program , the Program Office had to
clarify and reinfo rce this d istinction carefu l ly as
part of the enrollment stage.

Inspection-Support
The project m anager trusts in the comm itments
made and continual ly inspects the p roject to ensure
del ivery on sched u l e . This inspection strictly takes
the for m of supportive feedback, thereby encourag
ing people to disclose risks before they become
problems. Whenever the projected resu l ts are at
risk of fal l ing short of the commitment, the project
manager declares a project "cusp."
The term "cusp'' is adapted here from Gleick to
describe the potential turning points, or critical
events, i n a project.> (Other terms in conventional
parlance include "gotchas," setbacks, crises, turning
poi nts, project breakdowns, and " c a l ls to action."
The managers used these terms during the p rogram.
For our ru rposes, we adopt the term cusp as a n
emotiona l l y neutral term. I t i s i mportant that at any
point in the project the term used be one that gives
an opening fo r the possibi lity of making a difference
and for moving the project forward . ) At the point of
a cusp, everyone is ready to embrace change
because it fu rthers the overa l l program objectives.
The m a nagement team col Ia borated to take
advantage of cusps to propel project m o mentum
toward the establ ished goa l . Examples of cusps i n
the A l p h a AXP program are presented throughout
this paper to demonstrate their integral value in the

Digital Technical jounwl

Vul. 4 No.

4

.vJecial lssue

1991

appl ication of the Enrol l ment Ma nagement Model
ami t l1e role they p l ayed in the creation of the
m o del itself.

Acknowledgment-Learning
A t each step of the project, the Program Office
acknowledges progress both personally and pub1 icly. For each event, the management team repeat
ed l y asks what was learned a nd how managers and
the team can do even better next time. Teams are
frequently coached to improve their methods for
better resu lts.

Using the Model
I n principle, the Program Office used the E nr o l l
ment Management Model in each component proj
ect. Of course in practice, not a l l groups used this
methodology. Early i n the program , only a few
groups signed u p . As the Alpha A..'\ P Program Office
began organizing the overall progra m , we started
for m a l izing the methodology. As noted above, we
learned extensively as events progressed . \Ve fou nd
few useful manuals applicable to runn ing such a
large program effective ly. I nstead , the Program
.
Office deve loped many of the tools "on the job,'
learning as the project unfolded .'' This paper exag
gerates a pure m odel rather than presenting its
incremental development. To balance the p i cture,
we show some of the pitfalls and side paths.
Most project managers followed the Enrol lment
Management Model either by instinct (experience)
or by example. In several instances, they form a l ly
reached outside for training i n runn ing p rojects
of t h i s complexity. Depending o n the size of the
project or sub-project, ma nagers used the model
with varying degrees of rigor. For example, the
l arger projects and the program overal l used fo rmal
i nspection m ee ti ngs and reviews. Subordi nate
projects were free to usc formal or i nformal inspec
tion processes. The program ream inspected
each group's i nspection processes to ensure that
there would not be any u nfortu nate m anagement
surprises.

Using Project Cusps
As described earl ier, cusps are critical project
events, or crises. Conventional project manage
ment concentrates on rigorous planning to avoid
such crises. The Program Office took the opposite
approach: We strove to understand the critical
events and m ilestones and used these cusps to
increase project momentum, as Figure 2 i l lu strates.
As the project approached each cusp, the Program

1 9')

Alpha A.XP Program Management

*

3. It is now cost-effective to place more than 4 giga
bytes of main memory on a system; hence 32-bi t
add ressing i s insufficient.

BUSINESS AS USUAL

CUSP

Figu-re 2

2. N i neteen n i nety-two i s the first year in w h ic h
m icroprocessors have achieved over 1 0 0 MIPS
(m il lion instru ctions per second) of comp uting.

Cusps as a Way to Change Directions

Office dealt with the event promptly to ensure that
the project con tinued to move toward the overarch
ing goal. In other words, the managers did not
develop a plan j ust to follow the plan. I nstead, they
developed a plan to u nderstand the overall project
flow and used the m ilestones and other events as
opportun ities to adjust the project velocity to keep
moving toward the goa l . 7 In m any cases, we gener
ated a cusp to propel the necessary change (for
example, by c reating a scl1edu le crisis). In other
cases, we took advantage of a cusp to make a neces
sary change.
As the management team became comfortable
with using project cusps c o nstru ctively, the
Program Office actively sol i cited more of them.
These i ncreased the velocity and resulting m o men
tum of the program , thereby achieving a " s l i ngshot"
effect. The Program Office used each cusp to
acknowledge progress. As the team acknowledged
more and more progress, the program 's momentum
moved from very low to break-even, and finally i nto
high gear.

Vision-Enrollment Stage:
Magnitude of the Program's Vision
The visi on for a program or project becomes the
u l t i m ate goa l or deliverable. Thus, the Alpha AXP
Program Manager's first task was to establ ish a
vision shared by a l l groups that wou l d contribute to
the progra m . This vision had to be large enough to
encompass all the work.

Alpha A XP Systems as
Fifth-generation Computing

4. Network i ng technology now al lows the con
struction of networks with over 100-megabit
throughput.
5. Cos t-effective

storage systems now exceed
the many-gigabyte range a n d are approach ing
terabytes.

These compu t i ng systems will i nclude large
a mounts of parallel ism as compared with classical
designs. The levels o f performance and connec
tivity finally al low comp u t i ng to rea lize greater
h u m an productiv ity: mobile, highly inte-ractive

compu ting that suppo-rts group wo-rk with algo
-rithms that in telligently analyze, simu late, and
syn thesize in support of a wide variety of human
endeavors. The application of this technology qual
ifies as the fifth generati o n of computing 8 9
The program vision for Alpha AXP systems, as
shown in Figure 3, is to be the first fam ily of systems
to implement the technology and appl ications fo r
the fifth generation of compu t i ng . This fam ily i s
fully compatible across a l l members n o w and w i l l
b e i n to future generations, ensuring t h a t appl i ca
tion binaqr programs will ru n unch a nged . Wi th no
comprom ise to future perform ance, the i nitial fam
i ly members also m a i ntain a h igh degree of com
patib i l ity with cu rrent systems to a l l ow easy
m igration for customers as they beg i n to require
this technology. Delivering a fam ily of h igh-qu a l i ty
systems in a t imely fashion reestablishes D igital's
reputation for technology and systems leadership.

UJ
(.)
z
m ;

S .n .le J::a rd;·!ctre ?lat .ore

Eng ] i 1< h only

Bl iss , Ao.s0.mblct· , Debuq , L i c:cose M9mt Faci ! i " y ,
( TPu , COOF· MLHnt Syste.
�. . Modt- 1 0 �uml Sys t�· ,
Per o·lr.ance Code M.iJa lyzc t , L.-J ·Jguac::e. Ser. s i r i v •- Editot ,
V i g i t a Tes:: :·1gr) , Compn-.�1!c Document '\rcr� · "" ect:t.!"e ,
!.WCne Phase r r ask o • ·- �· < , OF"C.-��nc:o\·:,; c · .,.., ': via !..;';
Foru:un .

C,

Ci1SE �oo l s

Sot···-:et·ge

S � age

2:

Commerc i a l :Jevelopmen
Second h · rdware pla

Sy:

ft•J1T' ;

In e rnu c ional vers ions

t ern

l o l l o•.-1 3

monrh>-

) ,1

e1

P.'-. G-.!.. , C+ + , AD.'\ , CDD :l.epcs _ t:w; , !-Ji, ,
Lhre>ads - rt ::. , R?C , GKS , 'hiCS , !'orrs :-:qrrt S·;.·r�:r . QECfon�::o ,
F ' !t= Cache , r.z..Jxset . D� :..: _ :c-� V-!"S (t:. � · .
� .0 , �: =.c . q�e�in ) ,
?emoL� S'/ S� em �·�ar�aqc.r , ;-\L·
i! _ ba:r .,., , CDA .. ... i:e ,
COBOC., ,

DECr:et

IV end node GE;..;� a :to DEC'f

TCP / 1 r . p;.,TH\·.'ORKS , Li,Tm s t er , i<.BS.
Stage

3:

Technical

?obusl Sys t <·rJ

Open Sys • em ;

nco·.�.- .

•'.X' 'ls . om;

Symrnet r i r Nu l t ... - t'rocess

' nq

Lb.c , l--u .&. , JSer- '.•tr ·
;:)' '·:S , :=-.Ci·�. , !J:•.:..s O!:" eq: .•:.�aler: .. , : :::. •,,:.._ .
X . 2 � c e.=;s , .:..LL - I P. - 1 � 1 .�. �·:/ :,�opor::L.lQ
sc,,ge ( :

Co:T�lle! t Clal RODt.iSL S
yc· •'1'1
."'-1 ha Cl u s te-rs ; I cernc�L i<•·
,: imrt l t aneou sly

al vers .on.;

;:e.-: &I c:1 Pr:n� , al : Sy .• ..,� int egrated
'JECr.et. V !'ot..:: _ng �ode , ;,;· .; ac�ess
S�age 5 :

.J�Cnet '.J er:d r:ocie ,

tE

e.�sed

. rOO:cJCt .; ,

T CJ'1. act on Sys te:•.
Tra nsi:lct i on r,:onitor . E'>cPC t!'1rcads

Figure 5

d ivert

the

promiser away

Tbe Single-page Plan: All E.xtmctji·om the Straw Horse Plan
ful fi l l ing the

program a nd shared our sense of sched u le u rgency.

promise. Thus, managers Jearn to inspect regu l a rly

from

Sudden ly, we were shocked by a memo stating

the progress of groups on whose comm i tments

that a critical project's sched ule had sl ipped sev
eral m o n t hs. Since v i r tu a l l y every other project

they depend .
The model, therefore, incorporates this tradi

depended upon it, this sched ule sl i p could easily

tional, essential project m anagement practice. Its

have led ro a program d isaster. Instead, we used the

inclusion was prompted by another project crisis,
described below.

Fourth Cusp: Project Slips Motivate
Formal Operational Inspection
The Program Office knew that i t was working with

event to i nstitute a regu l a r o perational inspect i o n .

Often, i nstituting such regu lar reviews is d ifficult
and genera l ly resisted by the reviewees. In this
case, every group could see the danger of c o n t i nu
ing without regular inspections and readily agreed
to this new process.

h ighly motivated reams. O n the basis of the earlier

The Program Office adopted the term " i nspec

planning wor k , we assumed that they were a l l

tion," rather than " review," because we have fou nd

t ightly focused on t h e objectives o f the Al pha A XI'

t h i s term to be neu tral or positive. In the past.

200

Vol.

4 ,\u. -i

.\jl�cirrl lssue

!')').!

D(�ital Tecbnica/ journal

Enrollment Management, }J!fanaging the Alpha AXP Prog ram
m ilestones i s at the top, s o o n e c a n readily see any

reviews had been imposed by line management ami
tended to encourage the reviewees to cover up

repetitive slips. The emphasis is on critical path

issues u n t i l i t was too l ate to recover. I n contrast,

events completed last month and those coming up

the program manager, operating u nder the Program

next m o n t h . A t the bottom are l isted those issues

Office model. had no l i ne au thori ty and set up the

that have been resolved and issues being opened ,

monthly operational i nspections i n an open and

with clearly indicated ownership and due elates.

supportive environment. The presenters were the
designated project managers from each develop

Operational Excellence

ment group. The Program Office encouraged a l l

To ensu re t ha t every project implemented the

presenters to bring i n t heir risks and problems
before i t was too l ate to address them effectively.

ciple of operational excellence across the AJ p ha

We used the single-page for mat aga i n , as shown i n

AXP program. The office consisten t ly recogn ized

F igu re 6 . Note that the simple, visual h istory of a l l

teams that accomplished their resu I ts on time and

PROUE

strategies, the Program Office establ ished the prin

ALPHA/VMS
n.prL 8 , 1992

T:

D!\�P. :

SCHEDULE :
04 : g_
r

Ql 1992
Q2 992
3 1 9 92
Q4 1 992
r·lar J Apr :-�c.y Jun J Ju L i'.ug Sep i Oct Nov Dec
- r -- - r - - - r - - - r - - - r - - - 1 - -- --- r - r - - - 1 --- ! --- r - - - r - - - r - - -

Oct Nov De' Jan Feb

s

8

4

4

B

4

B

4

B

5

I

5

5

6
6

lj

6
6

E

I

E

I

E
E

I
l

u
u

E

S
s
s

I Sep 9 1

I Nov 91
! Jan 9?
llolar �2
! Apr 92

l�i lestones
8
Base Leve� 38 ( Ed ' or , debugger , TIE , base DEC. �t l
BasE: Leve_ 4 ( )'tore DECnel , ut il i t ies , and IJII cLent s l
4
5
Base Leve: 5 (8 4 s• 1pport , TFf, performance )
Base Levc: 6 ( Perfonrcnce & Tapes )
6
I nterr:.al fiel . test & Pi lot Port ing !,c::. iv� t y - F'I'l
I
Internal Lel
test u;;x'late - FT2
;:
F.
Early Suppo!'t ProgrilJl',
F1'3
E:< emal field test
S
Vl . O suhmi : o SSB

OONE
OONE
OONE
!XlNE

PATH EVENTS PAST �iONTH :
Shi pped 3L6 on March 12 - stable on A!X} , Ruby , Cobra , Fla.ra� :1go
Sh . pped BL6 .:l,'lC pm Lnq LoolLt
A hiev 1 FTl ( PPA I code freeze
Rece ived ?. flamingo systems in Varese , ltaly , tor ros-x development
l·J� th SPE ( CSSE ) , del i vered viOl ldw '"de field est support tra ining
F'I'l s t ctb i l i z a t i o n cont. nu i r.g

CRITICAL

ACTIVITIES AUJNG THE CRI'l'ICAL PATH

(NEXT MQ}ITHJ :

Sh�p FTl ; revised ta� eL is Apr 10
Ship FTl ANC por:;; i ng tool k it
Comp l e t e PPA Read�nes
Revieo."
Begin FT2 stabi l i za t ion
ISSUES ! DEPEN ENCIES RESOLVED :
Lamin o SF:l g1 aplucs suppo1 l

tor111rl l ly accelerated J nto

,.. . 0

,

ISSUES ! 9EPE.."l0EJ>JCIES :-JOT RESOLVED :
GE!·� BL24 comp: l e rs needed f01 ESP inLegra t i on : o . :, . . May .5
Rol:ouL support stat ing i s not �n anyone ' s plar: : J . S . , May

D igital Techuical jounwl

Vol 4 No. 4

Figure 6

The Single-Page Review

Special Issue

1<)92

)9

201

Alpha AXP Program Management

p red ictably. We al so usec.J the monthly program

acknowledgment of their wor k . This contrasts with

wide inspections to maintain a publ ished record of

the conven tional m anagement wisdom that it is

progress. Thus, each project was encouraged to

necessary to give frequent m o n etary rewards to

excel operationally and to Jearn from the experi
ences and presentations of the others.

motivate people. Although everyone appreciates
the fi nancial rewards, the biggest motivator is the
profess i o n a l recogn ition that the contributor did

Fourth Cusp Result
The Program Office establ ished m o n thly inspec
tions using a consistent s i ngle-page docu ment to

record perti nent i n form a t i o n .

a

good and necessary job'
The seco nd benefit of the acknmvledgment was
its effect i n creating a sense of momentum through
out a l l the project teams. Repeated ly, peer man
agers wou ld comment that the Alpha A X P team was
m a k i ng significant progress. This in turn gave us a

Acknowledgment-Learning Stage:
Building Momentum

sense of accompl. ishment as wel l . So t he p rogram

Developi ng the v ision and plan resu l ted in a ge n

edgment and a further s l i ngshot effect with recog

era l sense of euphoria. Shortly afterwards, the rea l

nition coming back to the Program Office.

real i zed a double benefit from the original acknmvl

ity of the work ahead descended l i ke a cloud
of despair. A t this point, the primary chal lenge
was to start b u i l d i ng momentum in the progra m .
I n t h e Enrol lment Management M()(l el, buil.d i ng
momentum - the acknowledgment-learning stage
is tigh t l y i ntertwined with the i nspection stage;
char is, events reported d u ri ng i nspections were
usecl to b u i ld m o mentu m . The Program Office rein
fo rced the vision and used momen tum bu ilding to
m in i m ize the time period d ur i ng which the ream
felt desp a i r about rhe \VOrk ahea d .

Fifth Cusp Result
Program-wide, man agers establ ished the norm of
frequent acknowledgment of progress.
As the Alpha A X P program m acle further prog
ress, the Program Office actively sol icited third
party and custo mer i nvolvement. This i nvolvem ent
provided good feedback on progress and had the
effect of rei nt<>rcing the fact that the program was
o n track to meet customer needs. l n some cases, the
project teams al tered the Alpha AX P plans ro better
help ou r customers aclclress thei r busi ness needs.

Fifth Cusp: De:,jJair
Since the overa l l program had such a formidable
goa l , many of the contributing reams became

This further contributed to the cred i b i l i q· and

momentum of the p rogra m as well as the sense of

accompl ishment.

stal led with the m agnitude of the task ahead of
them. This m a n i fested itse l f in the fo rm o f com
ments about the large amount of work, the resu lt
ing potential for sched ule clel ays, and a fea r of
overtime demands. This syndrome is com mon in
any large project, especial ly when comm it ments
are made that involve raking la rge risks. The
approach the program team took was to start recog
n izing each element of progress. As we d istribu ted
announcements of p rogress widely (using Digi t a l 's
worldwide electronic m a i l network), we began to
buil d momentu m a round the Alph a A X !' progra m .

Other groups p icked up on this moment u m and
contribu ted to it t hemselves. 'T'his effect cascaded
throughou t the ent ire program - more groups per
ceived thei r tasks ahead as achievable; rapi d ly each
gro u p wan ted irs own progress acknowledged; and
m o mentum i nc reased .

Sixth Cu�jJ: Broken Dependencies
and Replanning
Like a n y p roject, not every ass u m pt i o n and depen
dency proves to be correct or tota l ly accurate. At
one point, one of the m a j o r Alpha A X P hardware
systems sl ipped its schedule for del ivery of p roto
types to softwa re. After consideri ng a number of

a l ternatives, the operating system group proposed

an a lternate p l a n using a d ifferent h a rdware system
and a changed order o f even ts. They said in their
ma nagement p resentation at the time, "The ques
t i o n is not one of blame. I nstead our goal is to p re
serve the u l tim ate schedule goal of tbe program ,
specifica l ly its volu me ava i labi l i t y date ."

Sixth Cusp Result

The Program Office tl. ·i No. ·1

.\jii!Ciul ls.wl! I'J'J2

Digital Technical journal

Enrollment Management, Managing the Alpha AXP Program

At another point, one group was at risk because i t
needed a critical skil l fo r a week. A (his torical l y)
competing hardware group responded by asking
what sort of resource, and then freely suppl ied the
resource despite its own very tight schedu l e . In the
past, these groups wou l d compete fo r the same
resource w ithou t col l abo rati ng for the common
goo d .

Seventh Cusp: Incomplete Assumptions
and the Needfor the Performance Team

Eighth Cusp Result

Less than ha l f way through the Alpha A X P program ,
the program team rea l ized that some projects'
assumptions were i ncomplete. R ISC system s are
notorious for requiring careful design and tuning to
meet aggressive performance goa ls . Evidence from
a related program at Digital suggested that some
of our system perfo rma nce homework was wea k .
T h e Program Office q u i e t l y asked the approp riate
teams to assign some resources to measure key
components and subsystems of the design. This
confi rmed the program team 's concerns that the
current pla ns were i ncomplete. Quickly, we p u l l ed
together a cross-d iscipl i nary task force to a n a lyze
the info rmation rigorously and to make reco m m e n
dations . These analyses resul ted in changes i n the
arch i tecture, the ch i p design, the systems designs,
and the software. The changes have proved to
i ncrease pe rformance substantia l ly.

Seventh Cusp Result
The program establ ished a perform ance team to
cha nge the design a nd plans as needed.

Eighth Cusp: Prototype Allocation Process
As manufactu ring started to del iver prototypes, the
Program Office fo und that the early manufactur i ng
build rate was lower than planned. This \Vas the
resu l t of normal start-up problems. At the same
time, i n it i a l demand had increased substan t i a l ly.
Neve rthe less, the project a d m i n istrators conti nued
to ship the systems to engi neering and applications
groups in the original order. If this had continued,
dependent software wou ld have been delivered
progressivel y later because of i nadequate testing
cycles. Our i mpact a n a lysis indicated that the Alpha
AXP vol u me ava i l abi l ity wou ld slip by three
monrhs.
The review ream h ighl ighted this problem in a n
early program read i ness review. Trad i t ional ly,
Digital uses read iness reviews to establ ish manufac-

Digital Tecbn ical journal

Vol.

4 No. 4

.\jJecial lssue

turing's readi ness to bu i ld s ystems. The Alpha AXP
Program Office broadened this process and asked
for a progra m -wide readiness rev iew to identify
the "showstopper" risks. As a resu l t , the Program
Office central ized the al location process so that we
cou l d m a i n t a i n the p rototype a l locations i n real
time. The result was to reestab l ish su ffi cient soft
ware test t i me and maint ain momentu m with m i ni
mal p rogram i mpact.

1')92

The program teams decided that prototypes would
be delivered based o n program priorities, not solely
on existing plans.

Ninth Cusp: Needfor Quality Metrics
Each group i n the Alpha A..'\ P program adopted very
h igh standards for the qua l ity of its work. The m a n
age ment team repeated ly fou n d re i nforcement
of Phil Crosby's d i c tu m : "Qua lity is free." 1.1 Resu lts
in group after group showed that early and con
t i nu ous atte nt i o n to qua l i ty resulted in held or
improved schedu les.
However, the program team noticed that we
were not i nsp ecti ng and measu ring progress in
qual ity at the total systems l evel ; customers care
about o n l y the qu al ity of the total resu l t . As the
proj e c ts started i n tegrat ing i n to a total system , the
Program Office established an i ndependent group
to measure overa l l qua l i ty levels. The classic retc
tion to such independently derived qual i ty metrics
is that they are meani ngless. Instea d, since the
program estab l ished the metrics at the moment
when everyone saw the n eed , the reacti o n has
been to focus on the total syste m 's qu a l i t y without
dropp i ng attention o n the ind ividual component
metrics.

Ninth Cusp Result
The program
metrics.

for m a l ized

system-wide

qual ity

Results and Lessons Learned
Digital met exactly the program's overa l l schedu le
to the m onth ( i . e . , date for high-vol u me shi pmen ts),
desp i te numerous setbacks along the vvay. The
Alpha AXP system is meeting the origi n a l per
formance goa l s, and qua l ity is excel lent. Digital's
Board of Directors bas approved the fu l l Alpha AXP
program business plan and the investments neces
sary to capitalize on the Alpha A..-'<1' fam i ly's early

203

Alpha AXP Program Management

successes. In itial reactions from customers have
been favorable . Third parties have com mi t ted
Alpha AXP support for their products in record
numbers.

erables despite having the most complex tasks. For
example, the OpenYMS AXP system group not only
met i ts origina l sched u le but also accelerated num
erous deliverables i n to earlier base levels o r releases.
Figure 7 shows the OpenYMS schedule and actual
elates of ava ilabi l ity; foo tnotes indicate functional
accelerations. The networks group cleliverecl DECnet
on the AXP system an entire base level early. The
database systems group accelerated i t s schedule by
several months and demonstrated p roducts fou r
m onths early a t D igita l 's DECWORLD '92 trade show.
Clearly one of the m ajor lessons was to establish
a consta ncy of purpose and hold to it while con t i n
ually learning and updating the detailed plans. The
si ngJe-page representat i o n of the goals and m aster
plan i s a key element in maintaining this constancy.

What Worked Well
The Program Office in conjunction with the
Enro llment M a nagem ent Model has worked wel l . If
the m anagement tea m h ad fol lowed trad itional
approaches, we wou ld still be getting organized.
Usi ng the m odel, each group has been able to bring
its fu l l capabi l ities to bear as problems have arisen .
The project teams have accepted the i n t roduction
of m u l t iple leve ls of i nspection , ancl other programs
within D igital are copying this aspect of the modeL
Further, the notion of using project cusps creatively
has been a n effective tool tO build momentum .
Final ly., a com mon schedule and inspecti o n d isci
p l ine a l lowed the schedule to become an opportu
n it y to reinforce a shared vision. Th is positive view
contrasts w i t h the conventional interpretation of
a schedule as a burden.
As a resu lt, most groups met very aggressive goa ls
on sched ule. Several groups accelerated their clel iv-

What We Would Do Differently
Looking back, we wou ld have approached the
program differently in two areas. F irst, project
teams would have benefited from broader early
educa tion on project methodology. Several projects
had signi ficant sl ips, causing undue hardship on
other groups. The Program Office shou l d have

SC H EDU L E RE ' ULTS

ALPHA / VM

0 c l os re
m i n ima l l o g i n
B L 1 s n i p - min ima l l og i n
w (1)
RTLs ,
BL2 ' h i p
&
BL3A s h i r - : SAM , l i n k e. r
BL3B shi
pro de e l &
hase

Alpha

8 L4

VMS

BL6

TIE (2 ) ,

ship

-

f unct ionu. l l y c omp l e t e
Ru y c omp l er e ( 5 )

DEC

ee l ) )

{4)

30 ,

1 990

Au

17'

1 991

M

r

20

15,
26,

1 991

Ma y

-l

1 991

Jul

12

Pia

Occ

7'

1 9 () 1

18,
Dec 3 0 ,
Feb 2 1 '
Nov

1 991
1991
1 992

.3 , 1 9 92
May 1 9 9 2

Ap r

F T l / P PA
l

P h ase

Aug

Jun
Jcl
Aug

:.AT

ship

BLS s h ip

ACTUAL

O R I G I NAL

M I L L o i'ONE

1 9 92

30

Aug 2 3
Ct: 1 0
Nov 1 5
Jan

10

Mar

Apr .. o
fvlay 2 0
M y

FT2 / P PA

n/a

F T 3 / E SD ( 6 )

Jul 2 , 1 9 92
n / a l 9 'l 2

Aug

14

') c- t

Oct

26

FT4 / F'.S P
S S B s u bm1 s : s i on

v- . 0

( LRS )

2,

1 9 '? 2

22

Ju 1 8

No t e s :
(:)
(2)
(31

(4)
(5)
161

D E C ·..,r i n

m.• s

(i U - f a t: ' r a s a ed .im es )
BL4 t o BL3B
F !. 1 g r aph i c s su p o r- a c c e l e ra t ed [ r om next ve r s i o n to V1 . 0
pporL for
J t : p - e hardwar�
l t fo rms . c ce l� ta t• d f r o m n e x t
v e rs i on t o Vl . O
F D D I suppo rt a c � E e r a t e d f r om n e x t ve r s 1 o n &
VL . O
T r a n s l a t ed
ECne

Figure

204

I mage Env,;, r o n m e n c

a c c e l e r a :_ c d

7

f r om

Original Open VMS i'vl ilestone and Delivery Dates

Vol. 4 No. 4

:,pecial lssue 1991

D igital Teclmicaljournal

Enrollment Management, Managing the Alpha AXP Program

i ntroduced Ron LaFleur's p roject methodology
sooner and pervas ively. Instead , we waited u n t i l
each group saw the need and t h e n t r i e d to i n t ro
d uce i t . For groups such as the OpenVMS A X P
system group, t h e methodology was i n troduced
early. However, other groups needed (and sti l l
need) this disci pl ine.
Second , the office wou ld have condu cted more
pervasive project inspecti o ns. Several groups were
very late in p roducing schedu les and plans that the
Program Office could understand. The office was
u nable to obta i n their cooperation to hold deta i led
a nd frequent inspections. Eventu a l ly, the Program
Office was invited to set up and participate i n
appropriate i nspections o f sched u l e , process, etc.
However, we should have i nsisted o n these m uch
sooner.

References and Note
1.

R . Waterm a n , T. Peters, and J Phil l ips, "Struc
ture is Not Organization," Business Horizons.
no. 80302 (.June 1980).

2.

C. Savage, Fifth Generation Management
(Bur l i ngton, MA: Digital Press, 1990).

}

Oncken and D. Wass, ·' Management Time:
Who's got the monkey," Ha ruard Business
Review, vol . 18, no. 6 (November 1974): 7'5-79.

4.

M . McMaster ancl J. G rinder, PREOSION:
A New AjJproach to Co mmun ication (Bonny
Doon, CA: Precision Moclels, 1980).

5.

). Gleick, CHAOS: Making a New Science
(New York: Pengui n Books, 1987).

6.

P Senge, Tbe Fifth Discipline: The A rt and
Practice of the Learning Organization (New

Summary
The Alpha AXP program is the most complex pro
gram in Digital's history and has been d e l ivered on
sched ule with h igh quality. The Alpha A X P Program
Office used a rigorous management methodology
to build the p rogra m - le vel teamwork necessary to
accompl ish this breakthrough . The office p roved
the effectiveness of the Enro l lment Managem ent
Model: vision-enrol lment, c o m m i tment-delega
tion, inspection -support, and acknowledgment
learning . Integral to this model and empowering to
the team is to take each cusp head-on and to use
them to increase momentum. The management
team has been learning as the program progressed
and has identified areas n ee d i ng strengthening for
future programs.

York : Doubleday, 1990) .
7.

A. Sche rr, " Managing fo r Breakthroughs in
Productivity;· Human Resource ,uanage 
ment, vo l . 28, no. 3 ( Fa l l 1989): 403 - 424

8.

L.

D-igital Technical jow·nal

Vol. 4 No. 4

Special Issue 1992

Tes l e r, " Networked Computing in the
Scientific A merican (September

1990s:·

1991 ) 86-93.

9.

10.

The five generations of computing are as fol 
lows: 1950s, standa lone; 1 960s, batch; 1970s,
timesharing; 1980s, personal: 1 990s, mobile
distributed.
R. Comerford , " H ow DEC Developed Alpha,"
IEEE Spectntm (.July 1992): 26 -31 .

11.

C . House ami R . Price, "The Return Map:
Tracking Product Teams," Haruard Business
Reuiew, vol . 69, no. 1 ( Janu ary 1991 ) : 92 - 100.

12.

R. La Fleur, "A Seminar i n Project Manage
ment'' (Scituate, ,\1A : Project Management
Assistance Co. , 1990).

13.

P Crosby, Quali(v ls Free: The Art of Making
Quality Certa in (New Yo rk McGraw-H i l. l ,

Acknawledgments
The author thanks the fo l lowing senior managers
fo r demonstrating the i mportance of good manage
ment: Gordon Bel l for architecture and a clear strat
egy; Ken Olsen for demanding s imple, single-page
plans; .Jeff Kal b for operational excel lence; David
Stone for the model o f focusing on the desired
state; Bob Supnik for the paradigm of the Program
Office.
The author also thanks key members of the Alpha
AX P Program Office for their contributions in m a n
aging the program and developing the Enro l l ment
Management Methodology : AJ Avery fo r systems
i n tegration and significant help preparing this
paper; Scott Gordon fo r competitive benchmark
i ng; E l le n Salisbury for p l an n i ng; and Ken Sch u ltz
fo r operations and inspection.

W

1979).

General References
F. Brooks, Tbe Mythical 1l1C11z -month: Essay s on
Software Engineering (Read i ng. .vi A : Addison

Wesley, 1975 ) .
R . Neustadt a n d E . May, Thinking In Time: Tbe uses
of history for decision makers ( New York: Tbe
Free Press, 1986).

205

I

Further Rea dings
Tbe D igital Technica l _lournal
publishes papers that explore
tbe technologicalfoundations
ofDigital's majorproducts. Each
.Journal j(>cuses Oil at least one
product area and presents a
compila tion ofpapers written
by the engineers u:ho deueloped
the product. The contentfor
the Jou rnal is selected by the
journal Aduisoty Board.
Digital engineers ll 'bo would
like to contribute o paper
to the Jo urnal should contact
the editor at RDVAX:.RLAKE.

Topics covered i n previous issues of the
D(({ital Technicaljounwl are as fol l ows:
NVAX-mi croprocessor VAX Sys tems

Vol.

4. No.

3 Summer 191)2, EY-.1884E-Dl'
,

Semiconductor Technologies

v(>f. 4, No 2, .Sj>ring 1992. EY-L521 E-DP
PATHWORKS: PC Integration Software

lir>l. 4, No.

I,

Winter 1992, EY-J 825E-Dl'

Image Process ing, Video Termin als,
and Printer Technologies
Vol.

3, No. 4, Fall 1991, EY-H889E-DP

Availability i n VAXcluster Systems/
Network Performance and Adapters

vb/. 3, No. 3, Summer 11)91, EY-H890E-DP
Fiber Dis tri buted Data I nterface

Vol. 3, No.

2,

Spring 1991. E1'-H876£-DP

Tra nsac t i o n Processing, D atabases,
and Fau l t - tolerant Systems

Vr>l. 3, No.

I,

Winter 1991, EY-F588E-DI'

VAX 9000 Series

Vol. 2, No. 4, Fall 1990, EY-E762E-DP
DECwindows Program
Vr>l.

Compound Docu ment Architecture

Vol.

2,

No. 1, Winter 1990, EY-C196 E-DP

Distribu ted Sys tems

Vol.

I, No.

9,june 1989, EY-C 179E-DP

Stor-age Technology

Vol.

I,

No. 8, FebnUI1J' 1989, EY-C:l66E-DP

CVAX-based Systems

Vol. 1, No. 7, A ugust 1988, EY-6742£-DP
Software Productivity To ols

Vol.

I,

No.

G,

Februtii:J' 1988, EY-8259E-DP

VAXcluster Sys tems

Vol. 1, No. 5, September 1987, EY-R258E-DP
VAX 8800 Family

Vol. 1, No. 4, February 1987, EY-6711 E-DP
Networking Products

Vol. I, No. 3, September 1986, EY- 671 5 E-DP
M icroVAX II Sys tem

Vol.

I,

No. 2, March 198 6, EY- :H.'4 E-DP

VAX 8600 Processor

Vol. 1, No. 1, A ugust 1985, EY-:)4:3 5E-DP
Subscriptions to the Digital Technicaljou mol are
ava ilable on a prepaid basis. The subscription rate
is $ 40.00 for fou r issues ami $ 75.00 for eight issues.
Orders should be sent to Cathy Phi l Ups, Digital
Equ ipment Corporation. NI L0 1 - VI:l68, 146 M a i n
Street, Maynard , MA 01754 -2571 , U.S.A. , Telephone:
(508) 49.3 -2894, FAX: (508) 493-0637 Inqu iries
can be sent electro n ical l y to DTJ@ CRL D EC C:OM.
S u bscriptions must be paid in US. dol lars, and
checks shou ld be made payable to D igital
Equipment Corporation.
S i ngle copies and past issues of t he Digital
Techniculjournal are available fo r $ 16.00 each
from D igital Press, Department EER, 1 Bur l i ngton
Woods D rive, Bu rlington, MA 01830-4597 Single
issues can also be o rdered by c a l l i ng DECd i rect
at J - 800-DIGITAL ( 1 -800 - 344-4825 ).

2, No. 3. Summer 1990. EY-E756E-DP

VAX 6000 Model 400 Sys tem

Vol. 2, No. 2 .SjJring 1990. EY-C197E-Dl'
.

206

Vul. 4 Nu. 4

Special issue 1992

Digital Technical journal

I

Recent Digital US. Patent s

The following patents were recently issued to Digital Equipment Corporation Titles and names supplied
to us by the U.S. Pa tent and Tradenzark Office are reproduced exactly as they appear on the original
published paten t.
1):)27,261

K . L. Kore l l is and R. T. Faranda

Front Face Panel Portion for Enclosu re Doors for a Computer

[) :)27,477

K . L. Kore l l is

Front Panel for a n Integrated Sto rage Assembly fo r Computer
Storage Units

5,092,631

M . G. M. Masnik and
R. C. Ma rtel

Safety Enclosure for Gas Line Fittings

'5,093,628

I. T. Chan

Current-Pu lse In tegrating C ircu i t and Phase-Locked Loop

),093,77'5

W

R . Gru mlmann, R. F
Boucher, and T. Foss u m

M i c rocode Control System for Digital Data Processing System

),094,980

A . Shepela

Method for Providing a Metal-Sem iconductor Contact

),095,441

D. F Hopper, E. G. Fortm i l ler,
S. Kundu, and D. F. Wal l

Rul e Inference and Local i zation d uring Synthesis of Logic
C ircu i t Designs

5,095,460

T. L. Rodeh<:: ffer

Rotating Priority Encoder Operating by Selectively Masking
Input Signals to a F ixed Priority Encoder

'5,095,471

M . D. Sidman

Velocity Estim atOr in a Disk Drive Positioning System

'5,095,613

K. R. Hussi nger and
M. L . Mal lary

Thi n F i l m Head S l ider Fabrication Process

'5,097,370

Y. Hsia

Subambient Pressure Air Bearing Slider t()r D is k Drive

';,097,387

). L. Griffith

C ircu it Chip Package E mploy ing Low Melting Point Sol. der for
Heat Transfer

),097,41 1

P L. Doy le, ). P E l lenberger,
E. 0. jones, D. C Carver,
S. D. Dipirro, B. ]. Gerovac,
W P Armstrong, E. S. Gi bson,
R. E. Shapiro, K . C . Rushforth,
and W C . Roach

Graphics Workstat i o n for Creating Graphics Data Stru cture
\X'hich Are Srored Retrieved and D i sp l 3yed by a Graph ics
Subsystem for Competing Programs

'5,097,436

]. H. Zurawski

H ig h Performance Adder Using Carry Pred iction

').()97,468

E. Earl ie

Test i ng Asynchronous Processes

),099, 367

M . D. Sidman

Method of Automatic Gain Contro l Basis Selection and Method
of H a l f-Track Servo i ng

),099,484

D.

Mu ltiple Bit Error Detection and Correction System Employing
a M o d iJied Reed-Solomon Code I ncorpora ting Address Parity
and Catastrophic fai l u re Detection

'), ()99,48')

W F.

Bruckert, T. D. Bissett,
D. Mazur, ]. Munzer, F lkrnaby,
and ). H . Bhatia

Fau l t To lerant Computer Systems with Fau lt Isolation
and Repair

), 099,517

A. Gupta, W R. Hawe,
M. F. Kem pf, a nd C S. Lee

Frame Status Encoding for Com m u n ication Networl
Source Exif Data: 
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.6
Linearized                      : Yes
XMP Toolkit                     : Adobe XMP Core 5.2-c001 63.139439, 2010/09/27-13:37:26
Create Date                     : 2006:04:07 09:10:06+01:00
Creator Tool                    : Adobe Acrobat 7.05
Modify Date                     : 2013:01:11 01:25:16Z
Metadata Date                   : 2013:01:11 01:25:16Z
Producer                        : Adobe Acrobat 10.1.4 Paper Capture Plug-in with ClearScan
Format                          : application/pdf
Title                           : Digital Technical Journal, Volume 4, Number 4, Special Edition, 1992: Alpha AXP Architecture and Systems
Creator                         : 
Document ID                     : uuid:0b30a695-3121-4725-8ec7-08773db9771f
Instance ID                     : uuid:412ea17d-cc25-45af-b82c-63d3d4093f87
Page Layout                     : SinglePage
Page Mode                       : UseOutlines
Page Count                      : 211

EXIF Metadata provided by EXIF.tools
Digital Technical Journal, Volume 4, Number Special Edition, 1992 Dtj_v04 04_1992 Dtj V04 04

dtj_v04-04_1992 dtj_v04-04_1992

Navigation menu

Versions of this User Manual:

Views

Navigation
