[RESEND] Re: pdd03 and method calls
[ I think this still needs some clarification ] Leopold Toetsch [EMAIL PROTECTED] wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At 10:42 PM +0100 12/17/03, Leopold Toetsch wrote: While playing with calling threaded subs, I came along a thing which I think might be suboptimal: pdd03 states that the method PMC should go into P2. This doesn't really play with Perl5 - Perl6 interoperbility IMHO. Perl5 methods are plain subs, where the first param is the object. PDD 03 states that the *object* goes in P2. Yep, typo - sorry. This works out just fine with perl 5 style method calls, where the argument list doesn't distinguish the object other than by position. What happens is that when a perl 5 sub is called, @_ is a combination of P2 if it's non-NULL, and the remaining PMC registers. It's slightly more work for the perl 5 code generator to handle the check, but other than that it shouldn't be a problem. That seems to indicate, that we have to expose the whole parameter passing to HLLs and that Perl5 (and probably other languages) can't use the builtin PIR shortcuts (or we have to provide both schemes depending on some pragma directive). Additionally to the test: isnull P2, no_object# must be set to NULL on non-method calls we would need 2 code paths: For leaf subs[1], one can use registers as is, one would need rearanging the param regs. And as outlined by Juergen it doesn't fit very well for calling NCI PMC class methods: We would need another signature letter to denote the object. That's of course all doable but is adding assymmetry to method calls, which I don't like much. [1] these just use P5..Pn as passed in. leo leo
Re: pdd03 and method calls
Dan Sugalski [EMAIL PROTECTED] wrote: At 10:42 PM +0100 12/17/03, Leopold Toetsch wrote: While playing with calling threaded subs, I came along a thing which I think might be suboptimal: pdd03 states that the method PMC should go into P2. This doesn't really play with Perl5 - Perl6 interoperbility IMHO. Perl5 methods are plain subs, where the first param is the object. PDD 03 states that the *object* goes in P2. Yep, typo - sorry. This works out just fine with perl 5 style method calls, where the argument list doesn't distinguish the object other than by position. What happens is that when a perl 5 sub is called, @_ is a combination of P2 if it's non-NULL, and the remaining PMC registers. It's slightly more work for the perl 5 code generator to handle the check, but other than that it shouldn't be a problem. That seems to indicate, that we have to expose the whole parameter passing to HLLs and that Perl5 (and probably other languages) can't use the builtin PIR shortcuts (or we have to provide both schemes depending on some pragma directive). Additionally to the test: isnull P2, no_object # must be set to NULL on non-method calls we would need 2 code paths: For leaf subs[1], one can use registers as is, one would need rearanging the param regs. And as outlined by Juergen it doesn't fit very well for calling NCI PMC class methods: We would need another signature letter to denote the object. That's of course all doable but is adding assymmetry to method calls, which I don't like much. [1] these just use P5..Pn as passed in. leo
Re: pdd03 and method calls
At 12:44 PM -0500 12/18/03, Melvin Smith wrote:
At 10:42 PM 12/17/2003 +0100, Leopold Toetsch wrote:
While playing with calling threaded subs, I came along a thing
which I think might be suboptimal:
pdd03 states that the method PMC should go into P2. This doesn't
really play with Perl5 - Perl6 interoperbility IMHO. Perl5
methods are plain subs, where the first param is the object. I
dunno, if Ponie will ever use ParrotClass/ParrotObject, but I'm
sure, that calling Perl6 methods should work (and vv). So me thinks
that the method PMC should be the first PMC argument living in P5.
sub meth {
my ($self, $arg1) = @_;
#P5P6
...
Comments?
Makes sense to me for non-prototyped methods.
How 'bout:
Non-prototyped: pass object in P5 array with rest of arguments
Prototyped: pass in P2 as in current spec
Nope. The object is a special thing, and as such needs a special
place. Both Python and Ruby treat it differently at the language
level, and Parrot needs to treat it specially at the low level to do
proper method dispatching. I'd rather it stay where it is, off on the
side.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: pdd03 and method calls
At 7:38 PM +0100 12/18/03, Juergen Boemmels wrote: Dan Sugalski [EMAIL PROTECTED] writes: PDD 03 states that the *object* goes in P2. This works out just fine with perl 5 style method calls, where the argument list doesn't distinguish the object other than by position. What happens is that when a perl 5 sub is called, @_ is a combination of P2 if it's non-NULL, and the remaining PMC registers. It's slightly more work for the perl 5 code generator to handle the check, but other than that it shouldn't be a problem. It is missing from PDD03 that P2 must be set to NULL in case of a normal subroutine call. Fixed. Should be checked in, or will be soon. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: pdd03 and method calls
At 10:42 PM +0100 12/17/03, Leopold Toetsch wrote: While playing with calling threaded subs, I came along a thing which I think might be suboptimal: pdd03 states that the method PMC should go into P2. This doesn't really play with Perl5 - Perl6 interoperbility IMHO. Perl5 methods are plain subs, where the first param is the object. PDD 03 states that the *object* goes in P2. This works out just fine with perl 5 style method calls, where the argument list doesn't distinguish the object other than by position. What happens is that when a perl 5 sub is called, @_ is a combination of P2 if it's non-NULL, and the remaining PMC registers. It's slightly more work for the perl 5 code generator to handle the check, but other than that it shouldn't be a problem. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: pdd03 and method calls
Leopold Toetsch [EMAIL PROTECTED] writes:
While playing with calling threaded subs, I came along a thing which I
think might be suboptimal:
pdd03 states that the method PMC should go into P2. This doesn't
really play with Perl5 - Perl6 interoperbility IMHO. Perl5 methods
are plain subs, where the first param is the object. I dunno, if Ponie
will ever use ParrotClass/ParrotObject, but I'm sure, that calling
Perl6 methods should work (and vv). So me thinks that the method PMC
should be the first PMC argument living in P5.
When I was experimenting with native methods in ParrotIO.pmc i had
also the problem that there was no way to put the P2 register to the
argument list. I don't know if this changed since then, but I had
put the object to P5.
sub meth {
my ($self, $arg1) = @_;
#P5P6
...
This makes a method-call and a sub-call more symetric. Both a method
object and a sub object are called via
invokecc P0
and returned with
invoke P1
the difference between them is currently that a method will use one more
register for the data transfer: P2
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: pdd03 and method calls
Dan Sugalski [EMAIL PROTECTED] writes: PDD 03 states that the *object* goes in P2. This works out just fine with perl 5 style method calls, where the argument list doesn't distinguish the object other than by position. What happens is that when a perl 5 sub is called, @_ is a combination of P2 if it's non-NULL, and the remaining PMC registers. It's slightly more work for the perl 5 code generator to handle the check, but other than that it shouldn't be a problem. It is missing from PDD03 that P2 must be set to NULL in case of a normal subroutine call. Otherwise P2 can contain everything and the called function has no way to decide if the data is valid. An other possibility would be to let invoke set P2 to null, but I don't like the idea of having more sideeffects in invoke. This also makes it impossible to write callmeth as: find_method P0, P2, S0 invoke P0 bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: pdd03 and method calls
At 10:42 PM 12/17/2003 +0100, Leopold Toetsch wrote:
While playing with calling threaded subs, I came along a thing which I
think might be suboptimal:
pdd03 states that the method PMC should go into P2. This doesn't really
play with Perl5 - Perl6 interoperbility IMHO. Perl5 methods are plain
subs, where the first param is the object. I dunno, if Ponie will ever use
ParrotClass/ParrotObject, but I'm sure, that calling Perl6 methods should
work (and vv). So me thinks that the method PMC should be the first PMC
argument living in P5.
sub meth {
my ($self, $arg1) = @_;
#P5P6
...
Comments?
Makes sense to me for non-prototyped methods.
How 'bout:
Non-prototyped: pass object in P5 array with rest of arguments
Prototyped: pass in P2 as in current spec
-Melvin
pdd03 and method calls
While playing with calling threaded subs, I came along a thing which I
think might be suboptimal:
pdd03 states that the method PMC should go into P2. This doesn't really
play with Perl5 - Perl6 interoperbility IMHO. Perl5 methods are plain
subs, where the first param is the object. I dunno, if Ponie will ever
use ParrotClass/ParrotObject, but I'm sure, that calling Perl6 methods
should work (and vv). So me thinks that the method PMC should be the
first PMC argument living in P5.
sub meth {
my ($self, $arg1) = @_;
#P5P6
...
Comments?
leo
