> Various people have bugged me about this for a long time so I figured
> it was time, since it was the logical next step in hiding the Parrot
> calling convention implementation details.
>
> I've patched in initial support for IMCC to compile high level sub calls.
>
> 0, 1 and multiple return values are supported, but I didn't add flattening
> support yet as I'm not sure what syntax to use.
>
> The following works:
>
> _foo()
> var = _foo()
> var = _foo(a, b)
> (var1, var2) = _foo(a, b)
> (var1) = _foo(a, b) # redundant but supported
Like the idea of this. Nice! :-)
> Notes:
>
> * Since this is intermediate language, not HL, arguments to the
> subs must be either variables or single constants, NOT expressions.
>
> * Currently this syntax expects the sub name to be an IDENTIFIER.
> I'll add a syntax for calling a sub in a variable and possible
> by name (string constant).
>
> * IMCC will default the subs calls to prototyped for now. Currently
> our calling convention code is a bit broken, but the prototyped
> version works well.
>
> I've attached a couple of working samples.
Please may I suggest/request that you pop them in the imcc/examples
directory? There's very little in there as it stands; it'd be nice to at
least put examples in that demonstrate things that are going into IMCC from
here on. :-)
<snip>
> i = 7
> $I1 = 8
> s = "nine"
> I0 = _foo(7, 8, "nine")
Please can you explain to me why that last line is not:-
I0 = _foo(i, $I1, s)
<snip>
> .pcc_begin_return
> .return 10
> .pcc_end_return
If you're plan is "hiding the Parrot calling convention implementation
details", should that just not be
.begin_return
.return 10
.end_return
Or is there any reason not to do:-
return (10)
My apologies in advance if I'm way off on any of this stuff.
Thanks,
Jonathan
