[COMMIT] IMCC gets high level sub call syntax

[Melvin Smith]

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

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.

Cheers,

-Melvin

# Sample 1
.sub _main
.local int i
.local int j
.local string s
i = 7
$I1 = 8
s = "nine"
I0 = _foo(7, 8, "nine")
print "return: "
print I0
print "\n"
end
.end

.sub _foo
.param int i
.param int j
.param string s
print i
print " "
print j
print " "
print s
print "\n"
.pcc_begin_return
.return 10
.pcc_end_return
.end

# Sample 2, multiple return values
.sub _main
.local int i
.local int j
.local string s
i = 7
$I1 = 8
s = "nine"
(I0, I1) = _foo(7, 8, "nine")
print "return: "
print I0
print " "
print I1
print "\n"
end
.end

.sub _foo
.param int i
.param int j
.param string s
print i
print " "
print j
print " "
print s
print "\n"
.pcc_begin_return
.return 10
.return 11
.pcc_end_return
.end

[Jonathan Worthington]

> 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

[Melvin Smith]

At 01:45 AM 11/17/2003 +0000, Jonathan Worthington wrote:
> > 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. :-)

Absolutely, I'll do that.

><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)

You are correct. I was just toying around with variables
and constants and happened to leave that sample
as it was when I last tested it. I'll fix it before I commit it.

><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)

Absolutely correct.

I guess it might not be apparent that I'm phasing stuff in/out little
by little. I can't remove the .pcc* directives right now as that will
break existing compilers, and I don't typically have the time
in one sitting to do a full sweep and implement all the features,
so I try to do my commits at logical stopping points and add
features in digestible quantities.

If I try to implement too much at one time, there is high probability
that I'll either break existing stuff, or get so far down the path,
then someone will submit a huge patch that won't be compatible
and I have to backtrack. I try to sync up daily. That is just my style,
which is why you will see me frequently commit unimplemented stubs or
messy code with FIXME comments all over the place.

>My apologies in advance if I'm way off on any of this stuff.

Nope, you are right on, you're just looking ahead, which is good. :)

-Melvin

[Will Coleda]

My most recent "get tcl working again" error was in fact, the result of
a bad jump, as Leo suggested. Of course, that jump was never made
before, and in trying to track down why I was hitting an error
condition I hadn't before, I realized that I had a few
non-calling-convention subs near where the issue was occurring. In the
process of updating everything to be shiny and use the very latest
calling syntax (so I can then work on tracking down actual bugs
somewhere), I found that the samples listed below both fail with:

7 8 nine
SArray index out of bounds!

the end of parrot -t shows:

PC=105; OP=885 (set_i_ic); ARGS=(I5=7, 10)
PC=108; OP=885 (set_i_ic); ARGS=(I0=-98, 1)
PC=111; OP=885 (set_i_ic); ARGS=(I1=3, 1)
PC=114; OP=885 (set_i_ic); ARGS=(I2=0, 0)
PC=117; OP=885 (set_i_ic); ARGS=(I3=-2, 0)
PC=120; OP=885 (set_i_ic); ARGS=(I4=0, 0)
PC=123; OP=38 (invoke_p); ARGS=(P1=RetContinuation=PMC(0x8bb7d8))
PC=48; OP=1003 (restoretop)
PC=49; OP=801 (shift_i_p); ARGS=(I16=8, P3=SArray=PMC(0x8bb7f0))

Which kind of stops me dead in my tracks, as I'm loathe to put things
back to the old, bulky calling conventions.

Once this gets fixed, I'd be happy to submit a doc patch for
./imcc/docs/calling_conventions to document the syntax.

OOC, any progress on

$P1(arg)

working yet? (where $P1 is a Sub-like PMC?) This would allow me to rid
my code of the "pcc_call" style entirely.

Regards.

--
Will "Coke" Coleda will at coleda
dot com

[Leopold Toetsch]

Will Coleda <wi...@coleda.com> wrote:
> ... I found that the samples listed below both fail with:

Both samples run fine here. Do you have the latest parrot?

leo

[Dan Sugalski]

At 6:59 PM -0500 1/22/04, Will Coleda wrote:
>Which kind of stops me dead in my tracks, as I'm loathe to put
>things back to the old, bulky calling conventions.

Try throwing a prototyped on all the sub declarations (though that
ought not be necessary in the long run) and see if that helps.
Default assumptions of prototypeness have been changing a bit
recently.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Will Coleda]

What the...

I had a parrot that was less than a week old, I thought... but the copy
I grabbed this morning now works fine.

Thanks, Leopold.