[Digital logo]
[HR]

Migrating an Application from OpenVMS VAX to OpenVMS Alpha

Previous | Contents

There is no formal support for writing OpenVMS VAX device drivers in C. For example, OpenVMS VAX does not provide .h files for internal OpenVMS (lib) data structures.

The Step 2 driver interface has increased the differences between OpenVMS Alpha and OpenVMS VAX device drivers. Device driver source files written in VAX MACRO or BLISS can be kept common between OpenVMS Alpha and VAX through the use of conditional compilation and user-written macros.

The advisability of this approach depends greatly on the nature of the individual driver. (As of OpenVMS Version 7.0, the difference is even greater due to the 64-bit support.) It is possible that in future versions of OpenVMS Alpha, the I/O subsystem will continue to evolve in directions that will have an impact on device drivers. This could increase the differences between OpenVMS Alpha and VAX device drivers and add more complexity to common driver sources. For this reason, a fully common driver source file approach might not be advisable for the long term.

Depending on the individual driver, it might be advisable to partition the driver into a common module and an architecture-specific one. For example, if one were writing a device driver that does disk compression, then the compression algorithm could readily be isolated into an architecture independent module. One could also avoid operating-system-specific data structures in such common modules with the intent of having some common modules across various types of operating systems; for example, OpenVMS, Windows NT, and Digital UNIX.

For more information about writing new OpenVMS Alpha device drivers, refer to Writing OpenVMS Alpha Device Drivers in C.

1.3 Migration Process

The process for converting your VAX programs to run on an Alpha system includes the following stages:

  1. Evaluate the code to be migrated:
  2. Write a migration plan.
  3. Set up the migration environment.
  4. Migrate your application.
  5. Debug and test the migrated application.
  6. Integrate the migrated software into a software system.

    There are a number of tools and Digital services available to help you migrate your applications to OpenVMS Alpha. These tools are described in the context of the process described in this manual. The migration services are summarized in Section 1.5.

    1.4 Migration Paths

    There are two ways to convert a program to run on an Alpha system:

    These two methods are shown in Figure 1-1. Section 2.2 discusses factors to consider when choosing a migration method.

    Figure 1-1 Methods for Moving VAX Applications to an Alpha System

    Recompiling and Relinking

    The most effective way to convert a program from OpenVMS VAX to OpenVMS Alpha is to recompile the source code using a native Alpha compiler (such as DEC C or DEC Fortran) and then use the OpenVMS Linker to relink the resulting object files and any required shareable images. This method produces a native Alpha image that takes full advantage of the speed of the Alpha system.

    Translating

    Despite differences between VAX and Alpha systems, you can run most user-mode VAX images without error on an Alpha system by using the VAX Environment Software Translator (VEST), which is part of the DECmigrate for OpenVMS Alpha layered product. For a list of exceptions, see Section 2.3. This process provides a higher degree of VAX compatibility than recompiling the sources, but since the translated image does not provide the same high performance as a recompiled image, translation is used primarily as a safety net when recompiling is impossible or impractical. For example, translation is used in the following situations:

    VEST translates the VAX binary image file into a native Alpha image that runs under the Translated Image Environment (TIE) on an Alpha system. (TIE is a shareable image that is part of OpenVMS Alpha.) Translation does not involve running a VAX image under emulation or interpretation (with certain limited exceptions). Instead, the new Alpha image contains Alpha instructions that perform operations identical to those performed by the instructions in the original VAX image.

    A translated image should run as fast on an Alpha system as the original image runs on a VAX system. However, since the translated image does not benefit from the optimizing compilers that take full advantage of the Alpha architecture, it will typically run only about 25 to 40 percent as fast as a native Alpha image. Major causes of this reduced performance are unaligned data and extensive use of complex VAX instructions.

    For more information on image translation and VEST, see Section 3.2.2.1 and DECmigrate for OpenVMS AXP Systems Translating Images.

    Mixing Native Alpha and Translated Images

    You can mix migration methods among the individual images that comprise an application. An application can also be partially translated as one stage in a migration: this allows the application to run and to be tested on Alpha hardware before being completely recompiled. For more information about interoperability of native Alpha and translated VAX images within an application, see Section 2.7.2.

    1.5 Migration Support from Digital

    Digital offers a variety of services to help you migrate your applications to OpenVMS Alpha.

    Digital customizes the level of service to meet your needs. The VAX to Alpha migration services available include the following:

    To determine which services are appropriate for you, contact a Digital support representative or authorized reseller, or Digital Custom Systems at 800-344-4825.

    1.5.1 Migration Assessment Service

    The Migration Assessment service assesses the VAX system and application environment to be migrated to the Alpha platform. The objectives of the migration are reviewed and a complete current state configuration is completed. The desired end state is determined and risks and constraints are identified. Finally, several migration scenarios are developed.

    1.5.2 Application Migration Detailed Analysis and Design Service

    The Application Migration Detailed Analysis and Design service does a detailed analysis of an in-house developed application, creating a report of all VAX dependencies within all modules and recommendations as to what modifications should be made to migrate the application to Alpha. Acceptance criteria is specified for performance and functionality.

    1.5.3 System Migration Detailed Analysis and Design Service

    The System Migration Detailed Analysis and Design service performs a detailed analysis of the current system environment which includes hardware, software (Digital and third party, excluding in-house developed applications) and network components. The best tools and migration methods are determined and a project plan, which maps the steps from the current to the future state, is created.

    1.5.4 Application Migration Service

    The Application Migration service migrates an in-house developed application from an OpenVMS VAX platform to an Alpha platform. Each code module is either recompiled or translated depending on source code availability. VAX dependencies are removed beforehand. Finally the entire application is relinked and tested on the Alpha platform. The application is then deployed on the target system(s).

    1.5.5 System Migration Service

    The System Migration service migrates an OpenVMS system (single node or cluster) from the VAX platform to the Alpha platform. The customer's system availability and performance requirements are reviewed and acceptance testing methodology and criteria are determined.

    Chapter 2
    Selecting a Migration Method

    Evaluating your application identifies the work to be done and allows you to plan the rest of the migration.

    The evaluation process has three main stages:

    1. General inventory, including identifying dependencies on other software
    2. Source analysis to identify coding practices that affect migration
    3. Selection of a migration method: rebuilding from source code or translating
    When you have completed these steps, you will have the information necessary to write an effective migration plan.

    2.1 Taking Inventory

    The first step in evaluating an application for migration is to determine exactly what has to be migrated. This includes not only the application itself, but everything that the application requires in order to run properly. To begin evaluating your application, identify and locate the following items:

    Many of these items have already been migrated to OpenVMS Alpha, for example:

    You will be responsible for migrating your application and your development environment, including build procedures and testing suites.

    2.2 How to Select a Migration Method

    When you have completed the inventory of your application, you must decide how to migrate each part of it: by recompiling and relinking or by translating. The large majority of applications can be migrated just by recompiling and relinking them. If your application runs only in user mode and is written in a standard high-level language, it is probably in this category. For the major exceptions, see Section 2.4.

    The remainder of this chapter discusses how to choose a migration method for the relatively few applications that require more work to migrate. To make this decision, you will need to know which methods are possible for each part of the application, and how much work will be required for each method.

    Note

    The following process assumes that you will recompile your application if possible, and use translation only for parts that cannot be recompiled or as a temporary measure in the course of your migration.

    The following sections outline a process for choosing a migration method. This process includes the following steps:

    1. Determine which of the two migration methods is possible.
      Under most conditions, you can either recompile and relink your program or translate the VAX image. Section 2.3 describes cases where only one migration method is available.
    2. Identify architectural dependencies that affect recompilation.
      Even if your application is generally suitable to be recompiled, it may contain code that depends on features of the VAX architecture that are incompatible with the Alpha architecture.
      Section 2.4 discusses these dependencies and provides information that allows you to identify them and to begin to estimate the type and amount of work required to accommodate any dependencies you find.
      Section 2.6 describes tools and methods you can use to help answer the questions that come up in evaluating your application.
    3. Decide whether to recompile or translate.
      After you have evaluated your application, you must decide which migration method to use. Section 2.7 describes how to make the decision by balancing the advantages and disadvantages of each method.
      If you cannot recompile and relink your program, or if the VAX image uses features specific to the VAX architecture, you may wish to translate that image. Section 2.7.1 describes ways to increase the compatibility and performance of translated images.

    Figure 2-1 Migrating a Program

    As shown in Figure 2-1, the evaluation process consists of a series of questions and some tasks you can perform to help answer those questions. Digital provides a number of tools that you can use to help answer the questions; these tools are described at the relevant points in the process.

    2.3 Which Migration Methods are Possible?

    In most cases, you can either recompile and relink, or translate your application. However, depending on the design of your application, only one of the two migration paths may be available to you:

    2.4 Coding Practices That Affect Recompilation

    Many applications, especially those that use only standard coding practices or are written with portability in mind, will migrate from OpenVMS VAX to OpenVMS Alpha with little or no trouble. However, recompiling an application that depends on VAX specific features that are incompatible with the Alpha architecture will require modifying your source code. Typical incompatibilities include use of the following:

    If none of these incompatibilities is present in your application, the rest of this chapter does not apply to you.

    2.4.1 VAX MACRO Assembly Language

    On Alpha systems, VAX MACRO is not the assembly language, but just another compiled language. However, unlike the high-level language Alpha compilers, the VAX MACRO--32 Compiler for OpenVMS Alpha does not produce highly optimized code in all cases. Digital strongly recommends that you use the VAX MACRO--32 Compiler for OpenVMS Alpha only as a migration aid, not for writing new code.

    Many of the reasons for using assembly language on a VAX system are no longer relevant on Alpha systems, for example:

    For more information on migrating MACRO code, see Porting VAX MACRO Code to OpenVMS Alpha.

    2.4.2 Privileged Code

    VAX code that executes in inner access mode (kernel, executive, or supervisor mode) or that references system space is more likely to use coding practices dependent on the VAX architecture or to refer to VAX data cells that do not exist on OpenVMS Alpha. Such code will not migrate to an Alpha system without change. These programs will require recoding, recompiling, and relinking.

    Code in this category includes:

    For assistance in migrating inner-mode code that refers to the OpenVMS executive, contact a Digital support representative.

    2.4.3 Features Specific to the VAX Architecture

    To achieve its high performance, the Alpha architecture differs significantly from the VAX architecture. Software developers who have become accustomed to writing code that relies on certain aspects of the VAX architecture must be aware of architectural dependencies in their code in order to transport it successfully to an Alpha system.

    Common architectural dependencies, along with ways to identify them and actions you can take to eliminate them, are described briefly in the following sections. For a detailed discussion of ways to identify and eliminate these dependencies, see Chapters 4 to 8.

    2.5 Identifying Dependencies on the VAX Architecture in Your Application

    Even if your application recompiles successfully with a compiler that generates native Alpha code, it may still contain subtle dependencies on the VAX architecture. The OpenVMS Alpha operating system has been designed to provide a high degree of compatibility with OpenVMS VAX; however, the fundamental differences between the VAX and Alpha architectures can create problems for applications that depend on certain VAX architectural features. The following sections highlight areas of your application you should examine.

    2.5.1 Data Alignment

    Data is naturally aligned when its address is an integral multiple of the size of the data in bytes. For example, a longword is naturally aligned at any address that is a multiple of 4, and a quadword is naturally aligned at any address that is a multiple of 8. A structure is naturally aligned when all its members are naturally aligned.

    Accessing data that is not naturally aligned in memory incurs a significant performance penalty both on VAX and on Alpha systems. On VAX systems, most languages align data on the next available byte boundary by default, because the VAX architecture provides hardware support that minimizes the performance penalty in referencing unaligned data. On Alpha systems, however, the default is to align each data item naturally, so Alpha, like other typical RISC architectures, does not provide hardware support to minimize the performance degradation from using unaligned data. As a result, references to naturally aligned data on Alpha systems are 10 to 100 times faster than references to unaligned data.

    Alpha compilers automatically correct most potential alignment problems and flag others.

    Finding the Problem

    To find instances of unaligned data, you can use the following methods:

    Eliminating the Problem

    To eliminate unaligned data, you will be able to use one or more of the following methods:

    Note

    Software that is converted to natural alignment may be incompatible with other software that is running translated on a VAX system in the same OpenVMS Cluster environment or over a network; for example:
    • An existing file format may specify records with unaligned data.
    • A translated image may pass unaligned data to, or expect it from, a native image.
    In such cases, you will have to adapt all parts of the application to expect the same type of data, either aligned or unaligned.

    Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]

    [HR] 

      6459P001.HTM
  OSSG Documentation
  22-NOV-1996 13:07:03.79

    Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

    Legal