Партнёры:
Хостинг:
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 iden-
tifier, 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 parame-
ters 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 (%%eesspp), the second
argument is at 4 (%%eesspp), etc. Integer results of 32 bits or
less are returned in %%eeaaxx, 64-bit integer results are
returned in %%eeddxx::%%eeaaxx. Floating point results are returned
in %%sstt((00)).
The code may use registers %%eeaaxx, %%eeccxx and %%eeddxx. 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 conven-
tions described above.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |