parrotcode: Parrot Calling Conventions | |
Contents | Documentation |
docs/pdds/pdd03_calling_conventions.pod - Parrot Calling Conventions
Parrot's inter-routine calling conventions.
$Revision$
This document describes how to pass arguments from registers to subroutines, and how subroutines can extract their parameters into registers for use.
Since Parrot's calling conventions are continuation-based, there is arguably very little difference between a call and a return. Because of this, the conversion rules are the same regardless of whether code is invoking a subroutine or a return continuation.
There are four opcodes involved in parameter and return value propagation:
set_args
,
for passing arguments;set_returns
,
for returning values;get_params
,
for accepting parameters; andget_results
,
for accepting return values.FAQ: Given Parrot's internal use of continuation-passing style ["CPS"], it would be possible to use one pair of opcodes for both call and return, since under CPS returns are calls. And perhaps someday we will have only two opcodes. But for now, certain efficiency hacks are easier with four opcodes.)
The common syntax of these opcodes is:
<set_opcode> "(flags0, flags1, ..., flagsN)", VAL0, VAL1, ... VALN
<get_opcode> "(flags0, flags1, ..., flagsN)", REG0, REG1, ... REGN
The flags string is a literal quoted string denoting a list of zero or more comma-separated integers. The list as a whole may be surrounded by parentheses. Integers may be specified either in decimal, or if prefixed with "0b"/"0x", in binary/hexadecimal. There must be exactly one integer for each value or register given.
For documentation purposes we'll number the bits 0 (low) through 30 (high). Bit 31 (and higher, where available) will not be used.
Each integer in the flag string controls the processing of the corresponding value or register.
These bits of each flag word have common meanings for all argument/ return-value opcodes:
0-1 TYPE
0b00 = I
0b01 = S
0b10 = P
0b11 = N
You can just set these bits (as well as the CONSTANT bit below) to zero as the assembler calculates the correct setting depending on the given arguments.
Just before calling a subroutine with invokecc
or calling a method with <call_methodcc>, use the set_args
opcode to tell Parrot where the subroutine's or method's arguments will come from and how they should be expanded by the target.
Similarly, just before returning from such a subroutine or method, use the set_returns
opcode to tell Parrot where the return values will come from and how to expand them for the caller's use.
These bits of each flag word have these meanings specific to set_args
and set_returns
:
2 CONSTANT
The value is a literal constant, not a register.
(Don't set this bit yourself; the assembler sets this bit
automatically if a constant is given.)
3 FLAT
If this bit is set on a PMC value, then the PMC must be an
aggregate or a scalar containing a reference to an aggregate.
The contents of the aggregate, rather than the aggregate
itself, will be passed.
The meaning of this bit is undefined when applied to integer,
number, and string values.
4 MAYBE_FLAT
If:
(a) this bit is set on a PMC value; and,
(b) the PMC is an aggregate or a scalar containing a reference
to an aggregate; and,
(c) the called function has a slurpy flag on the corresponding
parameter;
then, pretend FLAT bit was set.
XXX - TODO - Determine whether this is really useful.
This description is kind of ad-hoc.
5 (unused)
6 (unused)
7 NAMED
XXX - TODO
As the first opcode in a subroutine that will be called with invokecc
or a method that will be called with <call_methodcc>, use the get_params
opcode to tell Parrot where the subroutine's or method's arguments should be stored and how they should be expanded.
Similarly, just before (yes, before) calling such a subroutine or method, use the get_results
opcode to tell Parrot where the return values should be stored and how to expand them for your use.
NOTE: It should be obvious, but in case it's not: You must name only registers as targets of these opcodes, not constants. (You can't store anything into a constant. That would make it a variable.)
These bits of each flag word have these meanings specific to get_params
and get_results
:
2 (unused)
3 SLURPY (P only)
If this bit is set on a P register, then it will be populated
with an aggregate that will contain all of the remaining values
that have not already been stored in other registers.
All such values will be converted to PMCs according to the
detailed rules below, and those PMCs will be stored into the
new aggregate.
XXX - TODO - If NAMED is not set, the aggregate will be an
Array type (HLL-specific) and the contents will be all
unassigned positional parameters.
XXX - TODO - If NAMED is set, the aggregate will be a Hash type
(HLL-specific) and the contents will be all unassigned named
parameters.
4 (unused)
5 OPTIONAL
If this bit is set on a register for which no value has been
passed, no exception will be raised; rather, the register will
be set to a default value: a Null PMC for P, an empty string
for S, or zero for N or I.
6 OPT_FLAG (I only)
An I register with this bit set is set to one if the
immediately preceding B<OPTIONAL> register received a value;
otherwise, it is set to zero.
6 READONLY (P only)
XXX - PROPOSED ONLY - XXX
If this bit is set on a P register that receives a value,
Parrot will ensure that the final value in the P register
is read-only (i.e. will not permit modification). If the
received value was a mutable PMC, then Parrot will create
and set the register to a read-only PMC wrapper around the
original PMC.
Parrot's algorithm for deciding what is writable may be pretty
simplistic. In initial implementations, it may assume that any
PMC not of a known read-only-wrapper type is mutable.
7 NAMED
XXX - TODO
If too many values are provided to fit into the given target registers, Parrot will throw an exception. Note that if the final target is a P register with FLAT set, then this exception can never occur.
XXX - FIXME - which exception? We really could use an exception subsystem. Oh, wait, that's my job. Never mind. --Chip
If too few values are provided so that some target registers are left unset, this too results in an exception.
Unlike the set_*
opcodes, the get_*
opcodes must perform conversion from one register type to another. Here are the conversion rules:
assign
(standard conversion).set
(pass by reference).assign
ed the given integer.assign
ed the given number.assign
ed the given string.Required features are missing:
Also, PIR should have pretty syntactical sugar around the get and set opcodes, but it doesn't. This document should specify what that looks like, too.
None.
None.
|