|
|
|
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.
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 on Sun-4 systems). Calls to the named routine are replaced
by the code in the in-line template.
For Sun-2 and Sun-3 systems, the following additional forms are recognized:
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.
In-line 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.
Results are returned in d0 or d0/d1.
The following registers may be used as temporaries: registers a0, a1, d0, and d1 on the MC68010 and MC68020; registers fp0 and fp1 on the MC68881; registers fpa0 through fpa3 on the Sun Floating-Point Accelerator. No other registers may be used.
The template must delete exactly argsize bytes from the stack. This is to enable inline to deal with autoincrement and autodecrement addressing modes, which in turn are used by c2 to delimit the lifetimes of stack temporaries.
The stack must not underflow the level of the last argument.
Use jcc branch mnemonics instead of bcc. The bcc ops are span limited and will fail if retargeted to a label whose span overflows the branch displacement field.
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 Sun-4 systems, the instruction following an expanded 'call' is inserted by inline before the expanded code to preserve the semantics of the call's delay slot.
|
|
|
Created by unroff & hp-tools. © somebody (See intro for details). All Rights Reserved. Last modified 11/5/97