[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
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 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
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 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
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
Dan Sugalski writes: > 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. Or perhaps the invocant can go in both P2 and $_[0] (depending on where that happens to be). Luke
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
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