---

1    Introduction

Furthermore, some properties are optional, depending on circumstances. For example, compilers are not obligated to follow the argument list conventions when a procedure and all of its callers are in the same module, have been analyzed by an interprocedural analyzer, or have private interfaces such as language-support routines.

Note

The specifications in this standard are presented in an "as if" manner; that is, all conformant code must behave as if the specifications have been met. This standard is designed so that additional link-time information can be utilized to optimize or even remove instructions in critical code paths and, as such, achieve higher performance levels.

In many cases, significant performance gains can be realized by selective use of nonstandard calls when the safety of such calls is known. Compiler writers are encouraged to make full use of such optimizations, but should make sure that procedures outside the compilation unit can proceed as if the standard were met.

---

1.1    Applicability

---

1.2    Architectural Level

The interfaces, methods, and conventions specified in this document are primarily intended for use by implementors of compilers, debuggers, other run-time tools, run-time libraries, and other base operating system components. These specifications can be, but are not necessarily, appropriate for use by higher-level system and software applications.

Compilers and run-time libraries may provide additional support for these capabilities through interfaces that are more appropriate for compilers and applications. This standard neither prohibits nor requires such additional interfaces.

---

1.3    Goals

The calling standard must be applicable to all intermodule callable interfaces in the native software system. The standard must consider the requirements of important compiled languages, including Ada, BASIC, C, C++, COBOL, FORTRAN, LISP, Pascal, PL/I, and calls to the operating system and library procedures. The needs of other languages that may be supported in the future must be met by the standard or by compatible revisions to it.

The goals of the Digital UNIX calling standard are to:

• Include capabilities specifically for lower-level components (such as assembler routines) that cannot be invoked from the high-level languages.

• Allow the calling program and called procedure to be written in different languages. The standard is designed to reduce the need to use language extensions for mixed-language programs.

• Contribute to the writing of error-free, modular, and maintainable software and promote effective sharing and reuse of software modules.

• Provide the programmer with control over the fixing and reporting of exception conditions and with management of the flow of control when various types of exception conditions occur.

• Add no space or time overhead to procedure calls and returns that do not establish exception handlers. The standard is designed to minimize the time overhead for establishing handlers at the cost of increasing time overhead when exceptions occur.

• Be optimized for newer, more complex compilation techniques, such as interprocedural analysis and link-time code transformations. However, the standard is designed to require no such mechanisms for correctness.

• Provide support for a multilanguage, multithreaded execution environment.

• Provide an efficient mechanism for calling lightweight procedures that do not need or want to pay the overhead of setting up a stack call frame. (Procedures are referred to as lightweight because of their expedient way of saving the call context.)

• Provide for the use of a common calling sequence to invoke lightweight procedures that maintain only a register call frame and heavyweight procedures that maintain a stack call frame. (Procedures that incur costs by storing the call context in memory are referred to as heavyweight.)

  This calling standard is designed to allow a compiler to determine whether to use a stack frame based on the complexity of the procedure being compiled. A recompilation of a called routine that causes a change in stack frame usage should not require a recompilation of its callers.

• Provide condition handling, traceback, and debugging for lightweight procedures that do not have a stack frame.

• Make efficient and effective use of the Alpha hardware architecture.

• Minimize the cost of procedure calls.

• Support a 64-bit address user-mode environment.

---

1.4    Requirements

• All Alpha platforms must be able to implement the standard.

• Non-Digital compiler writers must be able to implement the standard.

• The standard must not require any complex compilation techniques (such as link-time code movement) for correctness.

---

1.5    Definitions

address

A 64-bit value used to denote a position in memory.

argument list

A vector of quadword entries that represents a procedure parameter list and possibly a function value.

bound procedure

A type of procedure that requires knowledge at run time of a dynamically determined larger enclosing scope to execute correctly.

call frame

The body of information that a procedure must save to allow it to return properly to its caller. A call frame can exist on the stack or in registers. Optionally, a call frame can contain additional information required by the called procedure.

condition

See exception condition.

descriptor

A mechanism for passing parameters, where the address of the descriptor is an entry in the argument list. The descriptor contains the parameter's address, data type, and size as well as additional information needed to describe fully the data passed.

exception condition

An exceptional condition in the current hardware and/or software state that should be noted or fixed. The existence of this condition causes an interrupt in program flow and forces execution of out-of-line code. Such an event may be caused by exceptional hardware states (for example, arithmetic overflows or memory access control violations) or by actions performed by software (for example, subscript range checking, assertion checking, or asynchronous notification of one thread by another).

While the normal control flow is interrupted by an exception, the program flow is said to be in the active state.

exception handler

A procedure designed to handle exception conditions when they occur during the execution of a thread.

function

A procedure that returns a single value in accordance with the standard conventions for value returning. Additional values are returned by means of the argument list.

hardware exception

A category of exceptions that directly reflects an exception condition in the current hardware state that should be noted or fixed by the software. Hardware exceptions can occur synchronously or asynchronously with respect to the normal program flow.

image

A collection of compiled modules that are combined by a linker into a form that can be loaded for execution.

immediate value

A mechanism for passing input parameters where the actual value is provided in the argument list entry by the calling program.

language support procedure

A procedure called implicitly to implement higher-level language constructs. Such procedures are not intended to be explicitly called from a user program.

library procedure

A procedure explicitly called using the equivalent of a call statement or function reference. Such procedures are usually language-dependent.

natural alignment

An attribute of certain data types that refers to the placement of the data so that the lowest addressed byte has an address that is a multiple of the size of the data in bytes. Natural alignment of an aggregate data type generally refers to an alignment in which all members of the aggregate are naturally aligned. This standard defines five natural alignments:

• byte - Any byte address

• word - Any byte address that is a multiple of 2

• longword - Any byte address that is a multiple of 4

• quadword - Any byte address that is a multiple of 8

• octaword - Any byte address that is a multiple of 16

procedure

A closed sequence of instructions that is entered from and returns control to the calling program.

procedure descriptor

A set of information about the properties of a procedure. This information is contained in data structures at run time to enable exception handling and unwinding to function properly.

procedure value

An address value that represents a procedure value. This value is the address of the first instruction of the procedure to be executed.

process

An address space containing at least one thread of execution. Selected security and quota checks are performed on a per-process basis.

This standard applies to the execution of multiple threads within a process. (An operating system that only provides a single thread of execution per process is considered a special case of a multithreaded system; that is, one where the maximum number of threads per process is 1.)

reference

A mechanism for passing parameters, where the calling program provides the parameter's address in the argument list.

sharable image

An image that can be shared by multiple processes. On Digital UNIX, a single copy of the image can be included simultaneously at different addresses in multiple using processes. Such an image is said to be position-independent.

signal

A POSIX-defined concept used to cause out-of-line execution of code.

standard call

A transfer of control to a procedure by any means that presents the called procedure with the environment defined by this standard and does not place additional restrictions, not defined in this standard, on the called procedure.

standard conforming procedure

A procedure that adheres to all the relevant rules set forth in the Digital UNIX calling standard.

thread, or thread of execution

An entity scheduled for execution on a processor. In language terms, a thread is a computational entity utilized by a program unit such as a task, procedure, or loop. All threads executing within the same process share the same address space and other process context, but have unique per-thread hardware contexts that include machine registers such as program counters, process status, and stack pointers. This standard applies only to threads that execute within the context of a user-mode process and are scheduled on one or more processors according to software priority. All subsequent uses of the term thread in this standard refer only to these user-mode process threads.

thread-safe code

A property of code compiled in such a way as to ensure that it will execute properly when run in a threaded environment. Thread-safe code usually adds extra instructions to do certain run-time checks and requires that thread-local storage be accessed in a particular way.

undefined

Operations or behavior for which there is no directing algorithm used across all implementations that support the Digital UNIX calling standard. Such operations may or may not be well defined for a single implementation, but remain undefined with reference to this standard. The actions of undefined operations may not be required by standard-conforming procedures.

unpredictable

Any results of an operation that cannot be guaranteed across all operating system implementations of the Alpha architecture calling standard. Regardless of whether these results are well-defined for a specific implementation of the Alpha calling standard, they remain unpredictable with reference to all implementations of the standard.

Therefore, all results caused by operations defined in the Digital UNIX implementation of the calling standard, but not specified as part of the calling standard are considered unpredictable. Standard-conforming procedures cannot depend on unpredictable results.