[Digital logo]
[HR]

Migrating an Application from OpenVMS VAX to OpenVMS Alpha

Previous | Contents

If the use of the /G_FLOATING qualifier conflicts with a double-precision attribute specified in the source program or module, an error occurs. Routines and compilation units between which double-precision quantities are passed should not mix floating-point formats. Not all OpenVMS VAX processors support the G_floating data types.

See also the description of the /FLOAT qualifier, which is the preferred method for specifying the floating-point format to the compiler. The /FLOAT qualifier also allows you to select the IEEE floating-point format, which is supported only on Alpha systems.

11.5.6.3 OVERLAID Attribute

The OVERLAID attribute indicates how storage should be allocated for variables declared within a compilation unit. If you specify OVERLAID on a compilation unit, the variables declared at program or module level (unless they have the STATIC or PSECT attribute) overlay the storage of static variables in all other overlaid compilation units.

This attribute is intended for use only with programs that use the decommitted separate compilation facility provided by VAX Pascal Version 1.0.

Appendix A
Application Evaluation Checklist

This checklist is based on one used by Digital to evaluate applications for OpenVMS Alpha.

Comments in brackets following a question are intended to help clarify the purpose of that question.

Application Evaluation Checklist

Development History and Plans
1. Does the application currently run on other operating systems or hardware architectures? [] YES [] NO
If yes, does the application currently run on a RISC system? [] YES [] NO
[If so, it will be easier to migrate to OpenVMS Alpha.]
2. What are your plans for the application after migration?
a. No further development [] YES [] NO
b. Maintenance releases only [] YES [] NO
c. Additional or changed functionality [] YES [] NO
d. Maintain separate VAX and Alpha sources [] YES [] NO
[If you answer YES to a, you may wish to consider translating the application. A YES response to b or c should give you reason to evaluate the benefits of recompiling and relinking your application, although translation is still possible. If you intend to maintain separate VAX and Alpha sources, as indicated by a YES to d, you may need to consider interoperability and consistency issues, especially if the different versions of the application can access the same database.]
External Dependencies
3. What is the system configuration (CPUs, memory, disks) required to set up a development environment for the application?
[This will help you plan for the resources needed for migration.]
4. What is the system configuration (CPUs, memory, disks) required to set up a typical user environment for the application, including installation verification procedures, regression tests, benchmarks, or workloads?
[This will help you determine whether your entire environment is available on OpenVMS Alpha.]
5. Does the application rely on any special hardware? [] YES [] NO
[This will help you determine whether the hardware is available on OpenVMS Alpha, and whether the application includes hardware-specific code.]
6. a. What version of OpenVMS does your application currently run on?
b. Does the application run on OpenVMS VAX Version 7.1? [] YES [] NO
c. Does the application use features that are not available on OpenVMS Alpha? [] YES [] NO
[The migration base for OpenVMS Alpha is OpenVMS VAX Version 7.1. If you answer YES to c, your application may use features that are not yet supported on OpenVMS Alpha, or be linked against an OpenVMS RTL or other shareable image that is incompatible with the current version of OpenVMS Alpha.]
7. Does the application require layered products to run?
a. From Digital: (other than compiler RTLs) [] YES [] NO
b. From third parties: [] YES [] NO
[If you answer YES to a and are uncertain whether the Digital layered products are yet available for OpenVMS Alpha, check with a Digital support representative. If you answer YES to b, check with your third-party product supplier.]
Composition of the Application
8. How large is your application?
How many modules?
How many lines or kilobytes of code?
How much disk space is required?
[This will help you "size" the effort and the resources required for migration.]
9. a. Do you have access to all source files that make up your application? [] YES [] NO
b. If you are considering using Digital Services, will it be possible to give Digital access to these source files and build procedures? [] YES [] NO
[If you answer YES to a, translation may be your only migration option for the files with missing sources. A YES answer to b allows you to take advantage of a greater range of Digital migration services.]
10. a. What languages is the application written in? (If multiple languages are used, give the percentages of each.)
[If the compilers are not yet available, you must translate or rewrite in a different language.]
b. If you use VAX MACRO, what are your specific reasons?
c. Could the function of the VAX MACRO code be performed by a high-level-language compiler or a system service (such as $GETJPI for retrieving process names)? [] YES [] NO
[Digital does not recommend the use of VAX MACRO or the MACRO--64 Assembler for OpenVMS Alpha in Alpha applications. You may be able to replace assembly-language code in certain user-mode applications by a call to an OpenVMS system service that did not exist when the application was first written.]
11. a. Do you have regression tests for the application? [] YES [] NO
b. If yes, do they require DEC Test Manager? [] YES [] NO
[If you answer YES to a, you should consider migrating those regression tests. The DEC Test Manager is not available at the initial release of OpenVMS Alpha. Contact a Digital support representative if your regression tests depend on this product.]
Dependencies on the VAX Architecture
12. a. Does the application use the H_floating data types? [] YES [] NO
b. Does the application use the D_floating data types? [] YES [] NO
c. If the application uses D_floating, does it require 56 bits of precision (16 decimal digits) or would 53 bits (15 decimal digits) suffice? [] 56 bits [] 53 bits
[If you answer YES to a, you must either translate your application to obtain H_floating compatibility, or convert the data to G_floating, S_floating, or T_floating format. If you answer YES to b, you must either translate the application to obtain full 56-bit VAX precision D_floating compatibility, accept the 53-bit precision D_floating format provided by Alpha systems, or convert the data to G_floating, S_floating, or T_floating format.]
13. a. Does the application use large amounts of data or data structures? [] YES [] NO
b. Is the data byte, word, or longword aligned? [] YES [] NO
[If you answer YES to a, but NO to b, you should consider aligning your data naturally to achieve optimal Alpha performance. You must align data naturally if the data is in a global section shared among a number of processes, or is shared between a main program and an AST.]
14. Does the application make assumptions about how compilers align data (that is, does the application assume that data structures are: packed, aligned naturally, aligned on longwords, and so forth)? [] YES [] NO
[If you answer YES, you should consider portability and interoperability issues resulting from differences in compiler behavior, both on the Alpha platform and between the VAX and Alpha platforms. Be aware that compiler defaults for data alignment vary, as do compiler switches for forcing alignment. Typically, VAX systems default to a packed style alignment, whereas Alpha compilers default to natural alignment where possible.]
15. a. Does the application assume a 512-byte page size? [] YES [] NO
b. Does the application assume that a memory page is the same size as a disk block? [] YES [] NO
[If you answer YES to a, you should be prepared to adapt the application to accommodate the Alpha page size, which is much larger than 512 bytes and varies from system to system. Avoid hardcoded references to the page size; rather, use memory management system services and RTL routines wherever possible. If you answer YES to b, you should examine all calls to the $CRMPSC and $MGBLSC system services that map disk sections to memory and remove these assumptions.]
16. Does the application call OpenVMS system services? [] YES [] NO
Specifically, services that:
a. Create or map global sections (such as $CRMPSC, $MGBLSC, $UPDSEC) [] YES [] NO
b. Modify the working set (such as $LCKPAG, $LKWSET) [] YES [] NO
c. Manipulate virtual addresses (such as $CRETVA, $DELTVA) [] YES [] NO
[If you answer YES to any of these, you may need to examine your code to determine that it specifies the required input parameters correctly.]
17. a. Does the application use multiple, cooperating processes? [] YES [] NO
If so:
b. How many processes?
c. What interprocess communication method is used?
[] $CRMPSC [] Mailboxes [] SCS [] Other
[] DLM [] SHM, IPC [] SMG$ [] STR$
d. If you use global sections ($CRMPSC) to share data with other processes, how is data access synchronized?
[This will help you determine whether you will need to use explicit synchronization, and the level of effort required to guarantee synchronization among the parts of your application. Use of a high-level synchronization method generally allows you to migrate an application most easily.]
18. Does the application currently run in a multiprocessor (SMP) environment? [] YES [] NO
[If you answer YES, it is likely that your application already uses adequate interprocess synchronization methods.]
19. Does the application use AST (asynchronous system trap) mechanisms? [] YES [] NO
[If you answer YES, you should determine whether the AST and main process share access to data in process space. If so, you may need to explicitly synchronize such accesses.]
20. a. Does the application contain condition handlers? [] YES [] NO
b. Does the application rely on immediate reporting of arithmetic exceptions? [] YES [] NO
[The Alpha architecture does not provide immediate reporting of arithmetic exceptions. If your handler attempts to fix the condition and restart the instruction sequence that led to the exception, you will need to alter the handler.]
21. Does the application run in privileged mode or link against SYS.STB? [] YES [] NO
If so, why?
[If your application links against the OpenVMS executive or runs in privileged mode, you must rewrite it for it to work as a native Alpha image.]
22. Do you write your own device drivers? [] YES [] NO
[User-written device drivers are not supported in the initial release of OpenVMS Alpha. Contact a Digital support representative if you need this feature.]
23. Does the application use connect-to-interrupt mechanisms? [] YES [] NO
If yes, with what functionality?
[Connect-to-interrupt is not supported on OpenVMS Alpha systems. Contact a Digital support representative if you need this feature.]
24. Does the application create or modify machine instructions? [] YES [] NO
[Guaranteeing correct execution of instructions written to the instruction stream requires great care on OpenVMS Alpha.]
25. What parts of the application are most sensitive to performance? I/O, floating point, memory, realtime (that is, interrupt latency, and so on).
[This will help you determine how to prioritize work on the various parts of your application and allow Digital to plan performance enhancements that are most meaningful to customers.]


alignment: See natural alignment.

atomic instruction: An instruction that consists of one or more discrete operations that are handled by the hardware as a single operation, without interruption.

atomic operation: An operation that cannot be interrupted by other system events, such as an AST (asynchronous system trap) service routine; an atomic operation appears to other processes to be a single operation. Once an atomic operation starts, it always completes without interruption.

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

[HR] 

  6459P015.HTM
  OSSG Documentation
  22-NOV-1996 13:07:27.84

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal