this would be great -- i'm currently pulling the return values of my called subs directly out of I5, and it would be nice to have that bit taken care of for me, especially if calling conventions change somewhere down the line (but i certainly hope they don't). :)
On Wed, 27 Oct 2004, Leopold Toetsch wrote: > Parrot_call() runs a Parrot subroutine, but it takes PMC arguments only > and provides no return value.
> If no one hollers, I'll replace this function with a more flexible set > of functions that are wrappers to the *runops* functions in src/inter_run.c:
> this would be great -- i'm currently pulling the return values of my > called subs directly out of I5, and it would be nice to have that bit > taken care of for me, especially if calling conventions change somewhere > down the line (but i certainly hope they don't). :)
Calling conventions don't change. But trying the get I5 or such from a void function will not work anymore, because arguments and return values are copied now.
E.g. when you have a sub that ends with:
set P5, 100 # ret value set I0, 0 # non-prototyped set I3, 0 # no return value invoke P1 # return
On Wed, 27 Oct 2004, Leopold Toetsch wrote: > E.g. when you have a sub that ends with:
> set P5, 100 # ret value > set I0, 0 # non-prototyped > set I3, 0 # no return value > invoke P1 # return
> then P5 will not be passed to the caller.
right. but i'm explicitly using .pcc_begin_return/.return/.pcc_end_return to return values from subs run with Parrot_call. my C code then retrieves the return value from I5, which is where the return integer value would be copied. your changes would save me from having to fetch directly from I5, but until those changes are made, is this the "right way" to be doing this?
Jeff Horwitz wrote: > On Wed, 27 Oct 2004, Leopold Toetsch wrote:
>>E.g. when you have a sub that ends with:
>> set P5, 100 # ret value >> set I0, 0 # non-prototyped >> set I3, 0 # no return value >> invoke P1 # return
>>then P5 will not be passed to the caller.
> right. but i'm explicitly using .pcc_begin_return/.return/.pcc_end_return > to return values from subs run with Parrot_call. my C code then > retrieves the return value from I5, which is where the return integer > value would be copied. your changes would save me from having to fetch > directly from I5, but until those changes are made, is this the "right > way" to be doing this?
Yep that's ok. If the sub indicates an return value it is and will be availabe, in your case as REG_INT(5) in C.
Leopold Toetsch wrote: > Parrot_call() runs a Parrot subroutine, but it takes PMC arguments only > and provides no return value.
> If no one hollers, I'll replace this function with a more flexible set > of functions that are wrappers to the *runops* functions in > src/inter_run.c:
|
