Below inline attached is a scheme for an abstraction layer around
calling conventions.

Comments welcome,
leo

[ CALL.txt 4K ]
Parrot Calling Conventions

1) Rational

Calling conventions and opcodes (and of course the semantics of these)
define the ABI of the Parrot VM. Any change in the ABI creates
incompatibilities and the need to rewrite compilers that target
Parrot.

The current calling conventions as laid in stone in pdd03 [1] are IMHO
limited and suboptimal. I've already shown with the cachegrind
analysis of the fib benchmark[2] that we just can't keep the scheme in
the long run for performance reasons. Further: the current calling
scheme doesn't cope with MMD as argument ordering isn't provided:

  foo(int i, float v)

and

  foo(float v, int i)

end up with the same call signature setup *I2 := I4 := 1",

Finally the current scheme doesn't cope with any of the fancy call
stuff like named arguments, default values, scalar vs list context,
and what not. For HLL interoperbility Parrot should provide a scheme
that has at least some common denominator to support major target
languages.

Some of my arguments are of course related to performance and
optimzation, which we shouldn't consider much until we have a complete
Parrot VM. But changing the ABI can't be done much later as too much
existing code is impacted.

To get around this problem I propose an abstraction layer around the
calling scheme.

2) Proposal

2.1) @ARGS

@ARGS is a pseudo-array (hash, object) that handles call arguments and
return values.  It allows indexed and named access to arguments in a
straight forward manner:

   $I0 = @ARGS[0]     # get 1st argument as plain int
   set I16, @ARGS[0]  # same, PASM
   $P0 = @ARGS[1]     # get 2nd arg as PMC

This replaces the current scheme of addressing arguments:

   $I0 = I5           # 1st arg in I5
   $P0 = P5           # 2nd arg in P5

This should work of course the other way too:

  @ARGS[0] = 42       # set first return value
                      # or sub param to pass in

or

  push @ARGS, 42

We probably need two of these: one for the current incoming arguments
and one for outgoing arguments per call. Return values can arrive in
the @ARGS of the call. So it's more likely called @IN_ARGS and
@OUT_ARGS or some such.

2.2) named access of arguments:

  $P0 = @ARGS['a']    # get argument named 'a'

2.3) @ARGS methods and attributes

@ARGS provides all array-ish access methods:

  argv = elements @ARGS     # get argument count
  @ARGS = 4                 # want to pass 4 args to sub

All necessary introspection and functionality can be implemented with
existing opcodes or syntax:

  $I0 = typeof @ARGS[2]     # get type ID of 3rd argument
  $P0 = @ARGS."__ro"(3)     # get 4th argument as read-only (COW) copy

  @ARGS."__push"($P0)       # set next call arg
  @ARGS."__push_flatten(a)  # flatten "a" and add to outgoing args

  @ARGS."__set_default("a", $P0) # set default value for arg named "a"

and so on.

2.4.) variadic arguments (perl @_, Python *a)

The @ARGS array can directly map to an @_ array:

  @ARGS = argv

or:

  @ARGS[2] = argv           # ($a, $b, *@c)

2.5) return context

Yesterdays conversation on IRC (yes!) has clearly shown that the
current calling conventions are lacking information about scalar vs
list vs void context.

  sub foo { want.List ?? (1,2,3) :: 1 }   # or some such

This information could also be attached to @ARGS. E.g.

  @ARGS."return_list"(1)

3) implementation idea

For each call we've to allocate a context structure with a new
register frame. As shown in [3] this can be done effectively with a
sliding register window and variable sized call frames. An overall
layout of a call frame could look like:

   +---------+-----------+-----------+-----------+
   | context | in @ARGS  | registers | out @ARGS |
   +---------+-----------+-----------+-----------+

But actually it doesn't really matter now. With the abstraction we can
do it as we like and optimize it like hell later.

4) Conclusion

The @ARGS abstraction hides all the nasty call stuff inside a
consistent interface, which is easily extensible and not as limited as
the current layout in pdd03. Changing the ABI later isn't really a
good idea, an abstraction like this should be defined ASAP to provide
all freedom for the implementaion.

The attributes, methods, and semantics of @ARGS (or a similar
abstraction) should be consolidated by the various HLL folks, so that
we eventually have a consistent usable cross-language call interface
that just works.

leo

[1] docs/pdds/pdd03_calling_conventions.pod

[2] Subject: "Why is the fib benchmark still slow - part 1"

    NB: part 2 would have been the argument/return value copying
        between register frames (src/sub.c:copy_regs())

[3] Subject: "[Summary] Register stacks again"
    Subject: "[PROPOSAL] for a new calling scheme"

Would it be possible to attach it to the continuation?  Then in the
course of tail-calling the information continues to be available just
where it's needed.

leo

One can also think of {scalar, list, ...} context as the continuation's
signature...

leo

regards,
  Roger

[1]  If not implemented via "tailcall", it would use an additional stack
     frame, but the semantics would otherwise be identical.

-- Roger Hale

                                        -- Bob

regards,
  Roger