On Sep-21, Leopold Toetsch wrote:
> Steve Fink <[EMAIL PROTECTED]> wrote:
> > That would make it fun to track register usage.
> 
> And here is the problem with all these shortcuts.

But any one of these instructions could be treated by IMCC as
potentially reading from and writing to all PMC registers, except when
generated by IMCC itself for handling the calling conventions.

> Anyway, we should first finalize return conventions (it was proposed
> these to be symmetric to calling conventions).

It seems like there was widespread agreement to that proposal. Dan?

> Then finish pcc.c.

What's needed?

> Then we need code from HLL to see, how efficient (or not) parameter
> passing does look like.

I've been trying to implement A6 for languages/perl6. My first cut was
to have all calls, prototyped or not, take three parameters: an array
of all the positional args, an array of all named parameters with
statically-known names, and a hash of all remaining named params. I
have that version working for basic stuff, but it is obviously not
what Dan intended. f($a,$b) does not pass $a in P5 and $b in P6;
instead, it passes Array($a,$b) in P5, Array() in P6, and Hash() in
P7. (And it disagrees with the Perl6 builtin functions, which means I
can't use the same prototypes for builtins and user functions, which
is a mess.)

So I have many Perl6 examples of function calls that I have been
working off of, but none of them are particularly non-obvious. If it
helps, here's a list off the top of my head, not including any named
arguments:

Calls:
  f($a)
  f($a,$b)
  f([EMAIL PROTECTED])
  f($a,[EMAIL PROTECTED])
  f($a,[EMAIL PROTECTED],$c)
  f([EMAIL PROTECTED],[EMAIL PROTECTED])
  f([EMAIL PROTECTED],@b)

Prototypes:
  sub f($a)
  sub f(int $a)
  sub f([EMAIL PROTECTED])
  sub f($a,[EMAIL PROTECTED])
  sub f($a,?$b)
  sub f($a,?$b,[EMAIL PROTECTED])

Those calls should be considered in both prototyped and non-prototyped contexts.

> Then we can think of some higher level ops to {de,}construct argument
> arrays.

Well, I'd also like to know what the IMCC syntax will look like for
dynamically-sized lists of arguments and parameters, independent of
how they are implemented. (If I just had that, I could hack together
some horrible nasty implementation that would get thrown away, but in
the meantime would allow me to proceed with the A6 stuff.)

Reply via email to