inline(1)

NAME
inline - in-line procedure call expander

DESCRIPTION

Assembly language calls are inlined from the indicated source files into copies of the corresponding procedure bodies obtained from an inline file by specifying the inline file on the command line.

Inline files have a suffix of .il,

    for example: % CC foo.il hello.c

Inlining is done by code generator (cg).

USAGE
Each inlinefile contains one or more labeled assembly language templates of the form:
    inline-directive
    instructions
    ...
    .end

where the instructions constitute an in-line expansion of the named routine. An inline-directive is a command of the form:

    .inline identifier, argsize

This declares a block of code for the routine named by identifier, with argsize bytes of arguments. Calls to the named routine are replaced by the code in the in-line template.

Multiple templates are permitted; matching templates after the first are ignored. Duplicate templates may be placed in order of decreasing performance of the corresponding hardware; thus the most efficient usable version will be selected.

  Coding Conventions for all Sun Systems
Inline templates should be coded as expansions of C-compatible procedure calls, with the difference that the return address cannot be depended upon to be in the expected place, since no call instruction will have been executed.

Inline templates must conform to standard Sun parameter passing and register usage conventions, as detailed below. They must not call routines that violate these conventions; for example, assembly language routines such as setjmp(3V) may cause problems.

Registers other than the ones mentioned below must not be used or set.

Branch instructions in an in-line template may only transfer to numeric labels (1f, 2b, and so on) defined within the in-line template. No other control transfers are allowed.

Only opcodes and addressing modes generated by Sun compilers are guaranteed to work. Binary encodings of instructions are not supported.

  Coding Conventions for SPARC Systems
Arguments are passed in registers %o0-%o5, followed by memory locations starting at [%sp+0x5c]. %sp is guaranteed to be 64-bit aligned. The contents of %o7 are undefined, since no call instruction will have been executed.

Results are returned in %o0 or %f0/%f1.

Registers %o0-%o5 and %f0-%f31 may be used as temporaries.

Integral and single-precision floating-point arguments are 32-bit aligned.

Double-precision floating-point arguments are guaranteed to be 64-bit aligned if their offsets are multiples of 8.

Each control-transfer instruction (branches and calls) must be immediately followed by a nop.

Call instructions must include an extra (final) argument which indicates the number of registers used to pass parameters to the called routine.

Note that for SPARC systems, the instruction following an expanded 'call' is deleted.

  Coding Conventions for x86 Systems
Arguments are passed on the stack. Since no call instruction was issued, the first argument is at (%esp), the second argument is at 4 (%esp), etc. Integer results of 32 bits or less are returned in %eax, 64-bit integer results are returned in %edx:%eax. Floating point results are returned in %st(0).

The code may use registers %eax, %ecx and %edx. The values in any other registers must be preserved. The floating point stack will be empty at the start of the inline expansion template, and must be empty (except for a returned floating point value) at the end.

WARNING
inline does not check for violations of the coding conventions described above.