NAME

inline − in-line procedure call expander

SYNOPSIS

/usr/lib/inline [ −w ] [ −v ] [ −o outputfile ] [ −i inlinefile ] ... [ cpu-option ] [ fpu-option ] filename...

DESCRIPTION

inline expands assembly language calls in the indicated source files into copies of the corresponding procedure bodies obtained from an inlinefile specified with the −i option.  If no inlinefile is specified, the source files are simply concatenated and written to the standard output.  If no source files are specified, the input is read from the standard input. 

Inline itself is little more than a sed script.  Almost all of the benefit produced is derived from subsequent peephole optimization. 

OPTIONS

−w Display warnings for duplicate definitions on the standard error. 

−v Verbose.  Display the names of routines that were actually in-line expanded in the sourcefile on the standard error. 

−o outputfile
write output to the indicated file; standard output by default.

−i inlinefile
Read in-line code templates from inlinefile.

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.  (argsize is optional).   Calls to the named routine are replaced by the code in the in-line template. 

These forms are similar to .inline, with the addition of a CPU or FPU specification.  The template is only expanded if the specified target system matches the value of the target CPU or FPU type, as determined by the command-line options, or if none were given, by the type of the host system. 

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 Solbourne Systems

In-line 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.  See FILES, below, for examples. 

In-line templates must conform to standard Solbourne 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 Solbourne compilers are guaranteed to work.  Binary encodings of instructions are not supported. 

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 the instruction following an expanded ’call’ is inserted by inline before the expanded code to preserve the semantics of the call’s delay slot. 

FILES

/usr/lib/inline in-line procedure call expander

WARNING

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

Solbourne Computer, Inc.  —  23 September 1987