1. Porting OpenVMS and Applications to the Itanium™ Processor Family
Gaitan D’Antoni
Clair Grant
OpenVMS Engineering
September, 2003

2. HP OpenVMS Industry Standard 64 HP OpenVMS I64

3. Future releases providing continued enhancement & support
hp OpenVMS Roadmap 02 03 04 05
Sell at least until 2006; support at least until 2011
HP AlphaServer
EV68
EV7
EV79
Itanium®-based HP server
Itanium® 2 processor
Madison
Itanium®-based
system upgrades
Itanium®-based
system upgrades
HP OpenVMS Alpha
Version Version Version
hp OpenVMS I64 V8.2 (2004)
(3rd Release Production Quality)
& hp OpenVMS Alpha V8.2
With an installed base of 400,000 systems, OpenVMS remains important to the new HP. The core of the OpenVMS strategy and roadmap is unchanged. We plan to continue delivering enhancements to OpenVMS to support future AlphaServer systems based on EV7 and EV79, and will continue to sell OpenVMS on AlphaServer systems, at least until 2006, with ongoing support for at least 5 years after that, or until 2011.
In addition, OpenVMS is being ported to Itanium, thus providing a stable and long-term path for customers. This port is already well underway, with target availability for early developers in 2003, and a full production version in We are also working very closely with our ISV software partners and our goal is to have 100% of our existing partners port to Itanium.
We are committed to enable customers to move on their own schedule and to make the transition as seamless as possible. Existing OpenVMS applications will run on the new servers with little or no modification. To help facilitate this, we will provide source compatibility for OpenVMS applications, and where sources are not available, binary compatibility as well.
Boot Jan ‘03
OpenVMS I64 E8.0 H103
Eval. Release
OpenVMS I64 E8.1 H Eval. Release
HP OpenVMS
Industry Standard 64
Future releases providing continued enhancement & support
Platform transition period
November 24, 2018

4. hp OpenVMS Industry Standard 64 (I64) Release Roadmap
1st Boot on i2000 system, January 31, :31 PM EST
Boot on rx2600 system (First Ship platform), March 17, 2003
H103: hp OpenVMS I64 E8.0 “Mako” Evaluation Release Audience: Selected ISVs and Partners
OpenVMS Itanium Operating System, Monitor Utility
Networks: DECnet Phase IV, TCP/IP
Development Tools: Cross Linker, Cross Librarian, Native Debugger
Cross Compilers: C, C++, BLISS, FORTRAN, IMACRO
First Ship
New for May 2003:
Boot on rx2600 is included on this slide. This system is the supported platform for the OpenVMS I64 Version E8.0 “Mako” Evaluation Release.
The goal for the E8.0 evaluation release is to work very closely with a limited number of the strategic partners and software developers to start porting their applications for a broad spectrum of the OpenVMS solutions in the market.
For those anxious to get their hands on an evaluation release, it is planned to be generally available as a “beta” Software Developers Kit. Details on the pricing, availability and ordering information will be posted on the OpenVMS Web Site, VMS users groups, and in various newsletters… Stay tuned!
H203: hp OpenVMS I64 E8.1 “Jaws” Evaluation Release Audience: Key ISVs, Partners, Early Adopters Limited cluster functionality (4 nodes)
Native Compilers: C, C++, BLISS, FORTRAN, IMACRO, Pascal, BASIC, COBOL Additional Language Support: JAVA
Additional Layered Products…Networks, Data Serving, Security, eBusiness Integration, Application Development
Internal releases
External releases
Production
Quality
HP OpenVMS I64 V8.2
November 24, 2018

5. January 31 Boot is Old News
We’ve been busy since then
rx2600 and zx2000 have been booted (McKinley chip)
Most of the base OS is running
November 24, 2018

6. Porting Goals
Provide an operating system environment, development tools, and documentation to make porting as easy as possible
Full port of the Operating System, Runtime Libraries, development tools and most layered products
Recompile, relink, requalify
Use our experiences porting the operating system to make it easier for others to port their applications
Internal layered product groups, partners, and customers
November 24, 2018

7. Porting Philosophy
This is not a “bug for bug compatible” coding exercise. We are doing much, much more.
First, we are not just porting to the Itanium® architecture; we are making OpenVMS more portable.
Second, we are improving code maintainability (and sometimes performance) by replacing VAX assembler code when appropriate.
Third, we are making the system more open to the possibility of exchanging code with other systems, especially analysis tools. (This has already helped us debug our own new code.)
November 24, 2018

8. Big Challenges for the Base OS
No Alpha Console
Booting
Device Discovery
Interrupts
TLB miss handler
No Alpha PALcode
VAX Queue Instructions
VAX Registers
IPL and mode change
Different primitives in CPU
Register Conventions
Exception Handling
Atomic Instructions
Process Context
Plus, we decided to change
calling standard
object language
image format
November 24, 2018

9. It’s All in the SoftwareFW HW SW
OpenVMS
Console
Application
VAX
OpenVMS
Application
Alpha
Console
PALcode
OpenVMS
Console
Application
Itanium®
Processor
The goal of the internal Layered Product Kit is to provide enough of a system that key layered product groups can port and test their code. We will then have a system which a few ISVs and partners will be able to use to port and test their code. The ISV Update Kit will provide more base OS capabilities and a few more ISVs and partners will participate. The full customer release will be a complete VMS system with a large number of key ISVs already qualified for IPF.
The Boot Contest. Go to and enter the ‘first boot on IPF contest’.
November 24, 2018

10. Console Intel-architected boot environment
In the FAT partition
VMS_LOADER.EFI
IPB.EXE
Operating system interface to ACPI data
Boot drivers for SCSI and IDE (DVD in progress)
VMS uses standard PAL/SAL console interfaces to get
Translation buffer info
Clock frequency
Machine Check Vectors ….
November 24, 2018

11. Alpha PALcode Replacement
The following are all managed in the PAL on Alpha; VMS does the work on Itanium
VAX queue instructions (compilers generate OS calls)
VAX internal processor registers
AST and software interrupt support
IPL
Swap context
November 24, 2018

12. CPU Primitives Different register conventions More registers
R8/return status; R12/stack pointer
Compilers do the translation
More registers
IMACRO automatically replaces LDL/STC sequences
Memory fence replaces memory barrier
Compilers have builtins for most functions
November 24, 2018

13. Calling Standard Intel Calling Standard plus VMS extensions
Different register conventions
Unwind data
Affected areas
Exception handling
Signaling
Compilers
LINKER
Debuggers
Non-standard routine calls
Swap context
Kernel Processes enhanced to provide “context-aware” routines for all modes – converted DCL, DECnet, XQP, RMS,……
November 24, 2018

14. Lines of Code Perspective
New
Recompile
OpenVMS on Itanium®-based systems
Porting effort is very focused on a few areas of the system.
November 24, 2018

15. How’s It Going? ‘Boot Contest’ on i2000 Boot on rx2600
Scheduled: 12 weeks to boot (given “good” linked images)
Actual: 10 weeks (Jan. 31, 2003)
Boot on rx2600
Scheduled: 6 weeks
Actual: 6 weeks and 1 day (Mar. 17, 2003)
The effort and difficulty have been about as expected
No huge surprises
New Calling Standard and Object Language at least 50% of the project
November 24, 2018

16. Recent Milestones March 28 - first baselevel to compiler groups
May 6 - first baselevel to layered product groups
June 30 - V8.0 to selected customers
November 24, 2018

17. Porting Applications

18. Latest/Next Releases on Alpha Platform
Alpha Compiler Plans
Bug Fixes
Latest/Next Releases on Alpha Platform
Compaq C V6.5, C++ V6.5 – Released Feb 2002
Fortran V7.5 – Released Feb 2002
Compaq Basic V1.5 – Released May 2002
Compaq Pascal V5.9 – Planned release – H2 2003
HP COBOL V2.8 – Released December 2002
Java Beta released April, 2003
Product release scheduled for June, 2003
These are the release plans for the next versions of compilers on OpenVMS Alpha. This is important because a number of these compilers will be ported to the Itanium® architecture.
November 24, 2018

19. Itanium® Compiler Plans (1 of 3)
CPQ C
Itanium® architecture implementations of OpenVMS CPQ C V6.5 compiler
Use for recompile/relink/requalify
GEM backend code generator
Will be available starting with the initial OpenVMS release
C Dialect Support in C++ Compiler
Will include some features from CPQ C but may require source code changes
Compiler for moving forward
Intel® backend code generator
We plan to make this available with a future release of OpenVMS
The current Compaq C compiler will be ported to the Itanium® architecture. The Compaq specific extensions (i.e. /STANDARD=VAXC) to the C compiler will be available on the Itanium® architecture so any code that is dependent on these extensions can be compiled without requiring any source code modifications. on the Intel® based compilers.
The purpose of porting the existing Compaq C compiler to the Itanium® architecture is to allow developers to quickly and easily port their existing C applications to the Itanium® architecture. The use of this compiler will minimize the amount of source code that needs to be changed while porting applications. However, in order to achieve the best possible runtime performance and in order to fully take advantage of the capabilities of the Itanium processors, Compaq recommends that the Intel based C/C++ compiler be used.
November 24, 2018

20. Itanium® Compiler Plans (2 of 3)
Based on the same front end compiler technology as Compaq C++
Use for recompile/relink/requalify
Intel® backend code generator
COBOL, BASIC, PASCAL, BLISS
Itanium® architecture implementations of the current OpenVMS compilers
GEM backend code generator
Java
Itanium® architecture implementation of J2SE V1.4.1
The Intel C/C++ compiler will be made available on OpenVMS on the Itanium® architecture. This is a single compiler that will compile either C or C++ code. Some of the VAXC extensions from the Compaq C compiler will be added to the Intel based C/C++ compiler. Details about the specific extensions will be forthcoming in a future article.
The Compaq PASCAL, MACRO, BLISS, BASIC and COBOL compilers will be ported to the Itanium® architecture.
November 24, 2018

21. Itanium® Compiler Plans (3 of 3)
FORTRAN
Itanium® architecture implementation of the current OpenVMS Fortran 90 compiler
GEM backend code generator
Our plan is to replace GEM with the Intel® backend code generator in a future release in order to take advantage of enhancements in processor chip technology
IMACRO
Compiles ported VAX Macro-32 code for Itanium® architecture
Itanium® architecture equivalent of AMACRO
ADA
We will provide an Ada-95 compiler
We will not port the existing Ada-83 compiler
The JAVA™ JDK will be ported to the Itanium® architecture.
The current Compaq FORTRAN compiler will be ported to the Itanium® architecture. The current GEM back end code generator may be replaced with the Intel® back end code generator but the existing compiler functionality will remain the same.
November 24, 2018

22. Binary Translator
Will translate Alpha OpenVMS binary images and libraries linked under all OpenVMS versions from 6.2 to current version
Will translate a VESTed image that was translated by DECmigrate from a VAX binary image
Will translate images written in C, C++, FORTRAN or COBOL
Do we need to translate images written in BASIC and Pascal???
Restrictions: Alpha binary code
Only user-mode apps
Non privileged instruction
No self-modifying code
No sys. Memory space reference
No user-written system services
No applications written in PL/1due to lack of PL/1 Runtime Library
No Ada applications
The binary translator will translate any images that was linked under OpenVMS V6.2 and later. The purpose of the translator is to provide you with a way to get your Alpha images for which you no longer have the sources, onto the Itanium® architecture.
November 24, 2018

23. Itanium® architecture and OpenVMS Clusters
host-to-host
LAN interconnects
10/100 and Gigabit
OpenVMS on
Itanium®
architecture
OpenVMS on AlphaServers
LAN for Host-to- Host Comm.
Fibre Channel Storage
FC Switch
HSG/HSV
Star Coupler
shared storage
Fibre Channel
HSJ
CI storage
Served from
Alpha to Itanium
CI Storage
November 24, 2018

24. So, what’s different? (1 of 4)
Calling Standard
publicly available today at
Intel® calling standard with OpenVMS modifications
No frame pointer (FP)
Multiple stacks
only 4 preserved registers across calls
All OpenVMS provided tools will “know” about these changes
Your code that “knows” about the Alpha standard will almost certainly need to change
We will be changing to the Intel calling standard with a few modification needed for OpenVMS.
November 24, 2018

25. So, what’s different? (2 of 4)
Object file format
ELF/DWARF industry standards plus our extensions
ELF - Executable and Linkable Format, Itanium® Architecture object code, images, etc.
DWARF - Debugging and traceback information (embedded in ELF).
All OpenVMS provided tools will “know” about these changes
User written code that “knows” the object file format may have to change
We will be publishing these specifications in the near future
We will be using the industry standard ELF for object and image file formats and using DWARF for debugging and traceback information.
November 24, 2018

26. So, what’s different? (3 of 4)
Floating point data types
Itanium® architecture supports IEEE float only
All compilers that currently support F, D, G, S, T, and X (S and T are native IEEE formats) will continue to do so on Itanium® architecture
IEEE will be the default
HP will update the appropriate Runtime Libraries to add IEEE interfaces where needed
White Paper with technical details about the differences between VAX Float and IEEE Float is available at
The Itanium® architecture only supports the IEEE floating point format. Alpha supported the six formats listed here. All compilers ported from Alpha to the Itanium® architecture will retain support for the floating point formats. I.e. if a compiler supports G float on Alpha, that same compiler will support G float on Itanium. We will do the necessary work in the compiler to provide this support.
A whitepaper with specific details of how this will be implemented is in the works.
Let us know if you have any concerns about the different floating point formats.
November 24, 2018

27. So, what’s different? (4 of 4)
Source Code that May Need to Change
Architecture Specific code
All Alpha assembler code must be rewritten
Conditionalized code
Build command files
$ if .not. Alpha ! Assumes VAX
Application source code
#ifndef (alpha) // Assumes VAX
C asm code
We will be providing a new Porting Guide with details
If you have architecture specific code, I.e. code that “knows” the number of registers in a context switch or knows details about the machine architecture, then you will probably have to make modifications to this code. This is code that is usually written in Alpha assembler language.
If you have build command files or C/C++ code that assumes it’s running on either a VAX or an Alpha you may have to make changes to the code if you’re moving it to the Itanium® architecture.
We believe most of the existing BUILTIN functions will be provided in the ported compilers but if there are Alpha specific BUILTINs that don’t make sense on the Itanium® architecture then you may have to make changes to your code to rewrite those.
November 24, 2018

28. For further Information about OpenVMS on Itanium
OpenVMS on the Itanium® Architecture Web Sites
General OpenVMS on Itanium information
Layered products schedules
Layered products plans (products that either will not be ported or are under review)
OpenVMS Partner plans
November 24, 2018

29. November 24, 2018