VMS Help  —  MACRO  MACRO Compiler Directives
    You can use certain arguments to these directives to indicate
    register sets. You express a register set by listing the
    registers, separated by commas, within angle brackets. For
    example:

    <R1,R2,R3>

    If only one register is in the set, no angle brackets are needed.
    For example:

    R1

1  –  .BRANCH LIKELY

    Instructs the compiler that the following branch will likely be
    taken.

    Format

      .BRANCH_LIKELY

    There are no parameters for this directive.

1.1  –  Description

    The Alpha hardware predicts that forward conditional branches
    are not taken and that backwards conditional branches are taken.
    Based on the Alpha architecture, those assumptions are built into
    the compiler and influences the code generated for conditional
    branches.

    When .BRANCH_LIKELY precedes a forward conditional branch, the
    compiler will change the conditional branch and reorder the code
    such that the unlikely path will be a forward branch instead of
    the likely branch.

    The Itanium architecture includes branch prediction explicitly on
    each branch instruction. However, the compiler will still reorder
    the code to conform to the assumption that forward branches are
    not taken and backward branches are taken. The compiler will set
    the branch prediction flags as appropriate.

1.2  –  Example

  MOVL (R0),R1
  .BRANCH_LIKELY
  BNEQ    10$
    .
    .
    .
  10$

      The compiler will move the code between the BNEQ instruction
      and label 10$ to the end of the module, and change the BNEQ 10$
      to a BEQL to the moved code. It will then continue immediately
      following the BEQL instruction with generation of the code
      starting at label 10$.

2  –  .BRANCH UNLIKELY

    Instructs the compiler that the following branch will likely
    not be taken. Therefore, the compiler generates code that
    incorporates that assumption.

    Format

      .BRANCH_UNLIKELY

    There are no parameters for this directive.

2.1  –  Description

    See the description of the .BRANCH_LIKELY directive for the
    assumptions used by the compiler when predicting branches.

    On OpenVMS I64 systems, when .BRANCH_UNLIKELY precedes a
    conditional backwards branch, the compiler will use the
    appropriate branch prediction flags on the generated Itanium
    instruction.

    .BRANCH_UNLIKELY has no effect if it precedes a conditional
    forwards branch.

2.2  –  Example

  MOVL    #QUEUE,R0         ;Get queue header
  10$:    MOVL    (R0),R0   ;Get entry from queue
          BEQL    20$       ;Forward branch assumed unlikely
          .
          .                 ;Process queue entry
          .
          TSTL    (R0)      ;More than one entry (known to be unlikely)
          .BRANCH_UNLIKELY
          BNEQ    10$       ;This branch made into forward
  20$:                      ;conditional branch

      The .BRANCH_UNLIKELY directive is used here because the Alpha
      hardware would predict a backward branch to 10$ as likely to be
      taken. The programmer knows it is a rare case, so the directive
      is used to change the branch to a forward branch, which is
      predicted not taken.

3  –  .CALL ENTRY

    Declares the entry point of a called routine to the compiler.
    This entry declaration will save and restore the full 64 bits of
    any registers (except R0 and R1) that are modified by the routine
    and are not declared as scratch or output.

    Format

      .CALL_ENTRY  [max_args=number] [,home_args=TRUE|FALSE]

                   [,quad_args=TRUE|FALSE] [,input] [,output]

                   [,scratch] [,preserve] [,label]

3.1  –  Parameters

 max_args=number

    Maximum number of arguments the called procedure expects. The
    compiler uses this value as the number of longwords it allocates
    in the fixed temporary region of the stack frame, if the argument
    list must be homed. If homing is not necessary, the max_args
    count is not required. The compiler flags procedure entry
    points, where max_args has not been specified, that require homed
    argument lists.

    Note that, for .CALL_ENTRY routines in which max_args exceeds
    14, the compiler uses the received argument count, or max_args,
    whichever is smaller, when homing the argument list.

 home_args=TRUE|FALSE

    Indication to the compiler that the called procedure's argument
    list should or should not be homed. The home_args argument
    overrides the compiler's default logic for determining the
    circumstances under which an argument list must be homed.

 quad_args=TRUE|FALSE

    Indication to the compiler that the called procedure's argument
    list will have quadword references.

 input=<>

    Register set that indicates those registers from which the
    routine receives input values.

    This register set informs the compiler that the registers
    specified have meaningful values at routine entry and are
    unavailable for use as temporary registers even before the first
    compiler-detected use of the registers. Specifying registers in
    this register set affects compiler temporary register usage in
    this case:

    o  If you are explicitly using any of the Alpha or Itanium
       registers (R13 and above).

    In either of these cases, if you do not specify a register that
    is being used as input in the input argument, the compiler may
    use the register as a temporary register, corrupting the input
    value.

    This register set has no effect on the compiler's default
    register preservation behavior.

 output=<>

    Register set that indicates those registers to which the routine
    assigns values that are returned to the routine's caller.
    Registers included in this register set are not saved and
    restored by the compiler, even if they are modified by the
    routine.

    This register set also informs the compiler that the registers
    specified have meaningful values at routine exit and are
    unavailable for use as temporary registers even after the last
    compiler-detected use of the registers. Specifying registers in
    this register set affects compiler temporary register usage in
    this case:

    o  If you are explicitly using any of the Alpha or Itanium
       registers (R13 and above).

    In either of these cases, if you do not specify a register that
    is being used as output in the output argument, the compiler may
    use the register as a temporary register, corrupting the output
    value.

 scratch=<>

    Register set that indicates registers that are used within the
    routine but which should not be saved and restored at routine
    entry and exit. The caller of the routine does not expect to
    receive output values nor does it expect the registers to be
    preserved. Registers included in this register set are not saved
    and restored by the compiler, even if they are modified by the
    routine.

    On OpenVMS I64 systems, the compiler will not use these registers
    as temporary registers.

 preserve=<>

    Register set that indicates those registers that should be
    preserved over the routine call. This should include only those
    registers that are modified and whose full 64-bit contents should
    be saved and restored.

    This register set causes registers to be preserved whether or
    not they would have been preserved automatically by the compiler.
    Note that because R0 and R1 are scratch registers, by calling
    standard definition, the compiler never saves and restores them
    unless you specify them in this register set. Registers R16 and
    above are not allowed.

    This register set overrides the output and scratch register sets.
    If you specify a register both in the preserve register set and
    in the output or scratch register sets, the compiler will report
    the warning:

    %AMAC-W-REGDECCON, register declaration conflict in routine A

 label=name

    Optionally specify a label as in a VAX MACRO .ENTRY directive.
    This can be used if a module is to be common between OpenVMS
    VAX and OpenVMS Alpha or OpenVMS I64, if the OpenVMS VAX version
    needs to reference the entry with a .MASK directive, and if the
    OpenVMS Alpha or OpenVMS I64 version needs to use one or more
    of the special .CALL_ENTRY parameters. When the label parameter
    is specified and the symbol VAX is defined, an .ENTRY directive
    is used. If the symbol VAX is not defined, it creates the label
    and does a normal .CALL_ENTRY. Note that label is not the first
    parameter. Therefore, you cannot simply replace .ENTRY with
    .CALL_ENTRY. You must use the label parameter declaration.

4  –  .CALL LINKAGE

    OpenVMS I64 only.

    Associates a named or anonymous linkage with a routine name. When
    the compiler sees a CALLS, CALLG, JSB, BSBB, or BSBW instruction
    with the routine name as the target, it will use the associated
    linkage to decide which registers need to be saved and restored
    around the call.

    Format

      .CALL_LINKAGE  routine_name [,linkage_name] [,input] [,output]

                     [,scratch] [,preserve]

4.1  –  Parameters

 routine_name

    The name of a routine to be associated with the linkage.

 linkage_name =

    The name of a linkage previously defined with the .DEFINE_LINKAGE
    directive. If you specify a linkage_name, you cannot specify an
    input, output, scratch, or preserve parameter.

 input=<>

    Register set that indicates those registers from which the
    routine_name receives input values. This parameter is for
    documentation purposes only.

    If you specify an input register set, you cannot specify a
    linkage_name.

 output=<>

    Register set that indicates those registers to which the routine_
    name assigns values that are returned to the routine's caller.
    Registers included in this register set are not saved and
    restored around the call.

    If you specify an output register set, you cannot specify a
    linkage_name.

 scratch=<>

    Register set that indicates registers that are used within the
    routine.

    If you specify a scratch register set, you cannot specify a
    linkage_name.

 preserve=<>

    Register set that indicates those registers which the routine_
    name will preserve. Registers included in this register set are
    not saved and restored around a call to the routine, since the
    called routine will perform that task.

    If you specify a preserve register set, you cannot specify a
    linkage_name.

5  –  .DEFINE LINKAGE

    OpenVMS I64 only.

    Defines a named linkage that can be used with subsequent .CALL_
    LINKAGE or .USE_LINKAGE directives.

    Format

      .DEFINE_LINKAGE  linkage_name [,input] [,output] [,scratch]

                       [,preserve]

5.1  –  Parameters

 linkage_name

    The name of a linkage to be defined.

 input=<>

    Register set that indicates those registers from which a routine
    with this linkage receives input values. This parameter is for
    documentation purposes only.

 output=<>

    Register set that indicates those registers to which a routine
    with this linkage assigns values that are returned to the
    routine's caller. Registers included in this register set are
    not saved and restored around the call.

 scratch=<>

    Register set that indicates registers that are used within a
    routine with this linkage. This parameter is for documentation
    purposes only.

 preserve=<>

    Register set that indicates those registers which a routine with
    this linkage will preserve. Registers included in this register
    set are not saved and restored around a call to the routine,
    since the called routine will perform that task.

6  –  .DISABLE

    Disables compiler features over a range of source code.

    Format

      .DISABLE  argument-list

6.1  –  Parameters

 argument-list

    You can use one or more of the symbolic arguments listed in the
    following table:

    Option      Description

    DEBUG       Excludes local symbol table information in the object
                file for use with the debugger.
    FLAGGING    Deactivates compiler flagging.
    GLOBAL      Disables the assumption that undefined symbols are
                external symbols.
    OVERFLOW    Deactivates production of overflow trap code for the
                following opcodes: ADDx, ADWC, INCx, ADAWI, SUBx,
                SBWC, DECx, MNEGx, MULx, CVTxy (where x is greater
                than y, for example CVTLB), AOBxx, ACBL, and SOBxx.
    QUADWORD    Disables support for quadword literal and address
                expressions.
    SUPPRESSION Stops the listing of unreferenced symbols in the
                symbol table.
    TRACEBACK   Stops providing traceback information to the
                debugger.

7  –  .ENABLE

    Enables compiler features over a range of source code.

    Format

      .ENABLE  argument-list

7.1  –  Parameters

 argument-list

    You can use one or more of the symbolic arguments listed in the
    following table:

    Option      Description

    DEBUG       Includes local symbol table information in the
                object file for use with the debugger. For this
                to take effect, you must compile with /DEBUG or
                /ENABLE=DEBUG.
    FLAGGING    Activates compiler flagging.
    GLOBAL      Assumes undefined symbols are external symbols.
    OVERFLOW    Activates production of overflow trap code for the
                following opcodes: ADDx, ADWC, INCx, ADAWI, SUBx,
                SBWC, DECx, MNEGx, MULx, CVTxy (where x is greater
                than y, for example CVTLB), AOBxx, ACBL, and SOBxx.
    QUADWORD    Provides support for quadword literal and address
                expressions.
    SUPPRESSION Provides a listing of unreferenced symbols in the
                symbol table.
    TRACEBACK   Provides traceback information to the debugger. For
                this to take effect, you must compile with /DEBUG or
                /ENABLE=TRACEBACK.

8  –  .GLOBAL LABEL

    Declares a global label in a routine that is not an entry point
    to the routine.

    Format

      Label: .GLOBAL_LABEL

    There are no parameters for this directive.

8.1  –  Description

    The .GLOBAL_LABEL directive declares a global label within a
    routine that is not a routine entry point. Unless declared with
    .GLOBAL_LABEL, global labels in code (specified with "::") are
    assumed to be entry point labels, which require declaration. If
    they are not declared, they are flagged as errors.

    The compiler also allows the address of a global label to be
    stored (for instance, by means of  PUSHAL instruction). (The
    compiler flags as an error any attempt to store a label that has
    not been declared as a global label or an entry point.)

    By using the .GLOBAL_LABEL directive, you are acknowledging that
    the stored code address will not be the target of a CALL or JSB
    instruction. Global labels must appear inside routine boundaries.

    Labels declared with the .GLOBAL_LABEL directive can be used as
    the newpc argument in calls to the $UNWIND (Unwind Call Stack)
    system service because it allows the address of the label to be
    stored.

    However, there is no provision in the compiler to automatically
    adjust the stack pointer at such labels to remove arguments
    passed on the stack or compensate for stack alignment. If
    the call stack is unwound back to an alternate PC in the
    calling routine, the stack may still contain arguments and
    alignment bytes, and any stack-based references that expect this
    adjustment to the caller's original stack depth (which happened
    automatically on VAX) will be incorrect.

    Code that contains labels declared with this directive that are
    to be used as alternate PC targets for $UNWIND must be examined
    carefully to ensure correct behavior, with particular emphasis on
    any references based on the stack pointer.

9  –  .JSB ENTRY

    Declares the entry point of a JSB routine to the compiler. This
    entry declaration will save and restore the full 64 bits of any
    registers (except R0 and R1) that are modified by the routine and
    are not declared as scratch or output. See also .JSB32_ENTRY.

    Format

      .JSB_ENTRY  [input] [,output] [,scratch] [,preserve]

9.1  –  Parameters

 input=<>

    Register set that indicates those registers from which the
    routine receives input values.

    This register set informs the compiler that the registers
    specified have meaningful values at routine entry and are
    unavailable for use as temporary registers even before the first
    compiler-detected use of the registers. Specifying registers in
    this register set affects compiler temporary register usage in
    this case:

    o  If you are explicitly using any of the Alpha or Itanium
       registers (R13 and above).

    In either of these cases, if you do not specify a register that
    is being used as input in the input argument, the compiler may
    use the register as a temporary register, corrupting the input
    value.

    This register set has no effect on the compiler's default
    register preservation behavior. If you are not using the VAXREGS
    optimization switch or any of the Alpha registers, the input mask
    is used only to document your routine.

 output=<>

    Register set that indicates those registers to which the routine
    assigns values that are returned to the routine's caller.
    Registers included in this register set are not saved and
    restored by the compiler, even if they are modified by the
    routine.

    This register set also informs the compiler that the registers
    specified have meaningful values at routine exit and are
    unavailable for use as temporary registers even after the last
    compiler-detected use of the registers. Specifying registers in
    this register set affects compiler temporary register usage in
    this case:

    o  If you are explicitly using any of the Alpha or Itanium
       registers (R13 and above).

    In either of these cases, if you do not specify a register that
    is being used as output in the output argument, the compiler may
    use the register as a temporary register, corrupting the output
    value.

 scratch=<>

    Register set that indicates registers that are used within the
    routine but which should not be saved and restored at routine
    entry and exit. The caller of the routine does not expect to
    receive output values nor does it expect the registers to be
    preserved. Registers included in this register set are not saved
    and restored by the compiler, even if they are modified by the
    routine.

    On OpenVMS I64 systems, the compiler will not use these registers
    as temporary registers.

 preserve=<>

    Register set that indicates those registers that should be
    preserved over the routine call. This should include only those
    registers that are modified and whose full 64-bit contents should
    be saved and restored.

    This register set causes registers to be preserved whether or
    not they would have been preserved automatically by the compiler.
    Note that because R0 and R1 are scratch registers, by calling
    standard definition, the compiler never saves and restores them
    unless you specify them in this register set.

    This register set overrides the output and scratch register sets.
    If you specify a register both in the preserve register set and
    in the output or scratch register sets, the compiler will report
    the following warning:

    %AMAC-W-REGDECCON, register declaration conflict in routine A

10  –  .JSB32 ENTRY

    Declares the entry point of a JSB routine to the compiler. This
    directive does not preserve any VAX register values (R2 through
    R12) unless the PRESERVE parameter is specified. The routine
    itself may save and restore registers by pushing them on the
    stack, but this will not preserve the upper 32 bits of the
    registers. See also .JSB_ENTRY.

                                 WARNING

       The .JSB32_ENTRY directive can be a great time-saver if you
       are sure that you can use it. If you use .JSB32_ENTRY in a
       situation where the upper 32 bits of a register are being
       used, it may cause very obscure and difficult-to-track bugs
       by corrupting a 64-bit value that may be several calling
       levels above the offending routine.

       .JSB32_ENTRY should never be used in an AST routine,
       condition handler, or any other code that can be executed
       asynchronously.

    Format

      .JSB32_ENTRY  [input] [,output] [,scratch] [,preserve]

10.1  –  Parameters

 input=<>

    Register set that indicates those registers from which the
    routine receives input values.

    For the .JSB32_ENTRY directive, this register set is used only to
    document your code.

 output=<>

    Register set that indicates those registers to which the routine
    assigns values that are returned to the routine's caller.

    For the .JSB32_ENTRY directive, this register set is used only to
    document your code.

 scratch=<>

    Register set that indicates registers that are used within the
    routine but which should not be saved and restored at routine
    entry and exit. The caller of the routine does not expect to
    receive output values nor does it expect the registers to be
    preserved.

    Because R2 through R12 are not preserved by default, their
    inclusion in the scratch is for documentation purposes only.

 preserve=<>

    Register set that indicates those registers that should be
    preserved over the routine call. This should include only those
    registers that are modified and whose full 64-bit contents should
    be saved and restored.

    This register set causes registers to be preserved by the
    compiler. By default, no registers are preserved by the .JSB32_
    ENTRY directive.

    This register set overrides the output and scratch register sets.
    If you specify a register both in the preserve register set and
    in the output or scratch register sets, the compiler will report
    the warning:

    %AMAC-W-REGDECCON, register declaration conflict in routine A

10.2  –  Description

    The .JSB32_ENTRY directive is an alternative way of declaring a
    JSB entry point. It is designed to streamline the declaration of
    VAX MACRO routines that operate within a well-defined, bounded
    application environment, such as that of a single application
    or a self-contained subsystem. For any routine declared with the
    .JSB32_ENTRY directive, the compiler does not automatically save
    or restore any VAX registers (R2 through R12), therefore leaving
    the current 32-bit operation untouched. When you use the .JSB32_
    ENTRY directive to declare a JSB entry point, you are responsible
    for declaring and saving registers which must be preserved.

    If the externally visible entry points of a subsystem can be
    called from the 64-bit environment, those entry points should
    not be declared with .JSB32_ENTRY. Instead, .JSB_ENTRY (or .CALL_
    ENTRY) should be used so that the full 64-bit register values are
    saved, if necessary.

11  –  .PRESERVE

    Directs the compiler to generate special OpenVMS Alpha or OpenVMS
    I64 code throughout a module for all VAX MACRO instructions that
    rely on VAX guarantees of operation atomicity or granularity.

    Format

      .[NO]PRESERVE  argument-list

11.1  –  Parameters

 argument-list

    One or more of the symbolic arguments listed in the following
    table:

    Option         Description

    GRANULARITY    Preserves the rules of VAX granularity of writes.
                   Specifying .PRESERVE=GRANULARITY causes the
                   compiler to use Alpha Load-locked and Store-
                   conditional instruction sequences or the Itanium
                   compare-exchange (cmpxchg) instruction in code it
                   generates for VAX instructions that perform byte,
                   word, or unaligned longword writes.
    ATOMICITY      Preserves atomicity of VAX modify operations.
                   Specifying .PRESERVE=ATOMICITY causes the
                   compiler to use Alpha Load-locked and Store-
                   conditional instruction sequences or the Itanium
                   compare-exchange (cmpxchg) instruction in code
                   it generates for VAX instructions with modify
                   operands.

11.2  –  Description

    The .PRESERVE and .NOPRESERVE directives cause the compiler to
    generate special Alpha assembly code for VAX MACRO instructions,
    within portions of the source module, that rely on VAX guarantees
    of operation atomicity or granularity.

    Use of .PRESERVE or .NOPRESERVE without specifying GRANULARITY
    or ATOMICITY will affect both options. When preservation of
    both granularity and atomicity is enabled, and the compiler
    encounters a VAX coding construct that requires both granularity
    and atomicity guarantees, it enforces atomicity over granularity.

    Alternatively, you can use the /PRESERVE and /NOPRESERVE compiler
    qualifiers to affect the atomicity and granularity in generated
    code throughout an entire MACRO source module, though this is not
    recommended, because the overhead of the extra code where it is
    not needed can slow the program down considerably.

    Atomicity is guaranteed for multiprocessing systems as well as
    uniprocessing systems when you specify .PRESERVE ATOMICITY.

    When the .PRESERVE directive is present, you can use the /RETRY_
    COUNT qualifier on the command line to control the number of
    times the compiler-generated code retries a granular or atomic
    update.

                                 WARNING

       If .PRESERVE ATOMICITY is turned on, any unaligned data
       references will result in a fatal reserved operand fault.

       If .PRESERVE GRANULARITY is turned on, unaligned word
       references to addresses assumed aligned will also cause a
       fatal reserved operand fault.

11.3  –  Example

  INCW 1(R0)

      This instruction, when compiled with .PRESERVE GRANULARITY,
      retries the insertion of the new word value, if it is
      interrupted. However, when compiled with .PRESERVE ATOMICITY,
      it will also refetch the initial value and increment it, if
      interrupted. If both options are specified, it will do the
      latter.

12  –  .SET REGISTERS

    This directive allows you to override the compiler's alignment
    assumptions, and also allows implicit reads/writes of registers
    to be declared.

    Format

      .SET_REGISTERS  argument-list

12.1  –  Parameters

 argument-list

    One or more of the arguments listed in the following table. For
    each argument, you can specify one or more registers:

    Option       Description

    aligned=<>   Declares one or more registers to be aligned on
                 longword boundaries.
    unaligned=<> Declares one or more registers to be unaligned.
                 Because this is an explicit declaration, this
                 unaligned condition will not produce a fault at
                 run time.
    read=<>      Declares one or more registers, which otherwise the
                 compiler could not detect as input registers, to be
                 read.
    written=<>   Declares one or more registers, which otherwise the
                 compiler could not detect as output registers, to be
                 written to.

12.2  –  Description

    The aligned and unaligned qualifiers to this directive allow
    you to override the compiler's alignment assumptions. Using the
    directive for this purpose in certain cases can produce more
    efficient code.

    The read and written qualifiers to this directive allow implicit
    reads and writes of registers to be declared. They are generally
    used to declare the register usage of called routines and are
    useful for documenting your program.

    With one exception, the .SET_REGISTERS directive remains in
    effect (ensuring proper alignment processing) until the routine
    ends, unless you change the value in the register. The exception
    can occur under certain conditions when a flow path joins the
    code following a .SET_REGISTERS directive.

    The following example illustrates such an exception. R2 is
    declared aligned, and at a subsequent label, 10$, which is
    before the next write access to the register, a flow path joins
    the code. R2 will be treated as unaligned following the label,
    because it is unaligned from the other path.

            INCL R2          ; R2 is now unaligned
             .
             .
             .
            BLBC R0, 10$
             .
             .
             .
            MOVL R5, R2
            .SET_REGISTERS ALIGNED=R2
            MOVL R0, 4(R2)
      10$:  MOVL 4(R2), R3   ; R2 considered unaligned
                             ; due to BLBC branch

12.3  –  Examples

    1.DIVL R0,R1

      .SET_REGISTERS ALIGNED=R1
      MOVL     8(R1), R2          ; Compiler will use aligned load.

      In this example, the compiler would normally consider R1
      unaligned after the division. Any memory references using R1 as
      a base register (until it is changed again) would use unaligned
      load/stores. If it is known that the actual value will always
      be aligned, performance could be improved by adding a .SET_
      REGISTERS directive, as shown.

    2.MOV1     4(R0), R1          ;Stored memory addresses assumed

      .SET_REGISTERS UNALIGNED=R1 ;aligned so explicitly set it un-
      MOVL     4(R1), R2          ;aligned to avoid run-time fault.

      In this example, R1 would be considered longword aligned after
      the MOVL. If it is actually unaligned, an alignment fault would
      occur on memory reference that follows at run time. To prevent
      this, the .SET_REGISTERS directive can be used, as shown.

    3..SET_REGISTERS READ=<R3,R4>, WRITTEN=R5

      JSB     DO_SOMETHING_USEFUL

      In this example, the read/written attributes are used to
      explicitly declare register uses which the compiler cannot
      detect. R3 and R4 are input registers to the JSB target
      routine, and R5 is an output register. This is particularly
      useful if the routine containing this JSB does not use these
      registers itself, or if the SET_REGISTERS directive and JSB
      are embedded in a macro. When compiled with /FLAG=HINTS,
      routines which use the macro would then have R3 and R4 listed
      as possible input registers, even if they are not used in that
      routine.

13  –  .SYMBOL ALIGNMENT

    This directive associates an alignment attribute with a symbol
    definition for a register offset. You can use this directive
    when you know the alignment of the base register. This attribute
    guarantees to the compiler that the base register has the same
    alignment, which enables the compiler to generate optimal code.

    Format

      .SYMBOL_ALIGNMENT  argument-list

13.1  –  Parameters

 argument-list

    One of the arguments listed in the following table:

    Option  Description

    long    Declares longword alignment for any symbol that you
            declare after this directive.
    quad    Declares quadword alignment for any symbol that you
            declare after this directive.
    none    Turns off the alignment specified by the preceding
            .SYMBOL_ALIGNMENT directive.

13.2  –  Description

    The .SYMBOL_ALIGNMENT directive is used to associate an alignment
    attribute with the fields in a structure when you know the base
    alignment. It is used in pairs. The first .SYMBOL_ALIGNMENT
    directive associates either longword (long) or quadword (quad)
    alignment with the symbol or symbols that follow. The second
    directive, .SYMBOL_ALIGNMENT none, turns it off.

    Any time a reference is made with a symbol with an alignment
    attribute, the base register of that reference, in effect,
    inherits the symbol's alignment. The compiler also resets the
    base register's alignment to longword for subsequent alignment
    tracking. This alignment guarantee enables the compiler to
    produce more efficient code sequences.

13.3  –  Example

  OFFSET1 = 4
  .SYMBOL_ALIGNMENT LONG
  OFFSET2 = 8
  OFFSET3 = 12
  .SYMBOL_ALIGNMENT QUAD
  OFFSET4 = 16
  .SYMBOL_ALIGNMENT NONE
  OFFSET5 = 20
      .
      .
      .
  CLR1 OFFSET2(R8)
      .
      .
      .
  MOVL R2, OFFSET4(R6)

      For OFFSET1 and OFFSET5, the compiler will use only its
      tracking information for deciding if Rn in OFFSET1(Rn) is
      aligned or not. For the other references, the base register
      will be treated as longword (OFFSET2 and OFFSET3) or quadword
      (OFFSET4) aligned.

      After each use of OFFSET2 or OFFSET4, the base register in the
      reference is reset to longword alignment. In this example, the
      alignment of R8 and R6 will be reset to longword, although the
      reference to OFFSET4 will use the stronger quadword alignment.

14  –  .USE LINKAGE

    OpenVMS I64 only.

    Establishes a temporary named or anonymous linkage that will
    be used by the compiler for the next CALLS, CALLG, JSB, BSBB,
    or BSBW instruction processed in lexical order. This directive
    is used when the target of the next CALLS, CALLG, JSB, BSBB,
    or BSBW instruction is not a name, but a run-time value (for
    example, CALLS #0, (R6)). When the compiler sees the next
    CALLS, CALLG, JSB, BSBB, or BSBW instruction, it will use the
    associated linkage to decide which registers need to be saved and
    restored around the call. After the instruction is processed, the
    temporary linkage is reset to null.

    Format

      .USE_LINKAGE  [linkage_name] [,input] [,output] [,scratch]

                    [,preserve]

14.1  –  Parameters

 linkage_name

    The name of a linkage previously defined with the .DEFINE_LINKAGE
    directive. If you specify a linkage_name, you cannot specify an
    input, output, scratch or preserve clause.

 input=<>

    Register set that indicates those registers from which the
    routine called by the next CALLS, CALLG, JSB, BSBB, or BSBW
    instruction receives input values.

 output=<>

    Register set that indicates those registers to which the routine
    called by the next CALLS, CALLG, JSB, BSBB, or BSBW instruction
    assigns values that are returned to the routine's caller.
    Registers included in this register set are not saved and
    restored around the call.

 scratch=<>

    Register set that indicates registers that are used within the
    routine called by the next CALLS, CALLG, JSB, BSBB, or BSBW
    instruction. This parameter is for documentation purposes only.

 preserve=<>

    Register set that indicates those registers which the routine
    called by the next CALLS, CALLG, JSB, BSBB, or BSBW instruction
    will preserve. Registers included in this register set are not
    saved and restored around a call to the routine, since the called
    routine will perform that task.
Close Help