Man Page 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 iden-
     tifier,  with  argsize  as  the  total size of the routine's
     arguments,  in  bytes.   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(3c)
     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.

     Templates do not need ret or retl instructions,  and  should
     not include them.

     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 (%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.

  Compatibility Issues
     The value of argsize is ignored but the argument  should  be
     included  for compatibility with compiler versions predating
     the Sun WorkShop[tm] 5.0 compilers.

SEE ALSO:

     See the web page at http://www.sun.com/sparc/vis/  for  more
     information about the UltraSPARC[tm] VIS[tm] Instruction Set
     and the Vis Software Developer's Kit (VDSK).

WARNING

     inline does not check for violations of the  coding  conven-
     tions described above.