=head1 NAME

IMCC - calling conventions

=head1 VERSION

=over 4

=item 0.1 intital proposal

=back

=head1 OVERVIEW

This document describes subroutine calling conventions.

=head1 DESCRIPTION

A imcc does register allocation, it has to track the life span of
variables. This includes the (possible) data flow in and out of
subroutines.

=head1 Stack calling conventions

Arguments are B<save>d in reverse order onto the user stack:

   .arg y	# save args in reversed order
   .arg x
   call _foo	#(r, s) = _foo(x,y)
   .local int r
   .local int s
   .result s	# restore results in reversed order
   .result r	# [1]

and return values are B<restore>d in reversed order from there.

The subroutine is responsible for preserving registers.

 .sub _foo		# sub foo(int a, int b)
   saveall
   .param int a
   .param int b
   ...

   .return pl		# return (pl, mi)
   .return mi		# [1]
   restoreall
   ret
 .end

[1] or vice versa?

=head1 Parrot calling conventions (NCI)

Proposed syntax:

  $P0 = load_lib "libname"
  $P1 = dlfunc $P0, "funcname", "signature"
  .nciarg z	# I5
  .nciarg y	# I6
  .nciarg x	# I7
  ncicall $P1	# r = funcname(x, y, z)
  .nciresult r

This prepares parameters like described in
pdd03_calling_conventions.pod, saves the registers and invokes the
function.


=head1 Parrot calling conventions (Method calls)

TBD.

=head1 Namespaces and lexicals

 - Should imcc keep track of pad opcodes?
 - Should imcc even emit such opcodes from e.g. .local directives?

=head1 FILES

F<imcc.y>, F<t/syn/bsr.t>

=head1 AUTHOR

Leopold Toetsch <lt@toetsch.at>