User`s guide

Preparing to Port Macro-32 Code

1.5 Identifying Nonportable VAX MACRO Coding Practices

BRx label+offset

• Moving an opcode to a location, usually the stack or a data area, as shown

in the following example. This practice indicates either generated or

self-modifying code and will require redesign as indicated in Section 3.2.2:

MOVB #OP$_opcode,(Rx)

MOVZBL #OP$_opcode,(Rx)

• Jumping across modules. Because of architectural requirements, the compiler

must handle jumps across modules as JSBs. Therefore, external branch

targets as in the following example must be declared with the .JSB_ENTRY

directive (see Section 2.3.3):

JMP G^external_routine

1.6 Establishing Useful Coding Conventions

Section 1.3 describes a recommended process for porting VAX MACRO code

to OpenVMS Alpha or OpenVMS I64. Although this process might provide a

mechanism for porting code efﬁciently, it cannot by itself guarantee that the

porting effort will be consistent among the engineers who are performing the

porting, or will be intelligible to the engineers who will later need to debug and

test ported code. To ensure that the porting effort proceeds uniformly and that its

effects on source code are well documented, an engineering group should establish

coding conventions that are relevant to the goals of the effort.

Naturally, any methodology an engineering group adopts should be shaped by

that group’s development environment, including those procedures the group

follows for tool management, source code control, common code, and testing. The

coding conventions an engineering group should evaluate include:

• Establishing VAX MACRO source modules that are common to OpenVMS

VAX and OpenVMS Alpha or OpenVMS I64 systems (see Section 1.7)

• Providing clear and consistent register declarations in the compiler’s

entry-point directives (see Section 2.3)

1.7 Maintaining Common Sources

When designing a VAX MACRO code porting effort, consider the beneﬁts

of maintaining common sources for OpenVMS VAX, OpenVMS Alpha, and

OpenVMS I64 systems. It is advantageous to an engineering group to have only

one copy of its sources to maintain and enhance, and common sources help ensure

common user interfaces. However, if you ﬁnd that you are conditionalizing so

much source code that it is no longer intelligible, take steps to restructure the

code into architecture-speciﬁc and architecture-independent pieces. If the number

of these pieces becomes unmanageable, create separate architecture-speciﬁc

modules.

1–8 Preparing to Port Macro-32 Code