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 PDF.
Page Count: 211

DownloadDigital Technical Journal, Volume 4, Number Special Edition, 1992 Dtj_v04-04_1992 Dtj V04-04
Open PDF In BrowserView 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'

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

Navigation menu