invoke
Steve Fink
implicitly operates on P0. I know that P0 is the correct register to
use according to pdd03, but I dislike having it be implicit. The user
is required to set the rest of the pdd03 conventions up manually, so I
don't see any need for invoke to be different. And it makes it much
more clear what registers are being used if you have to pass in a PMC
as an argument.
So would anyone mind if I eliminated the zero-arg invoke op in favor
of a one-arg invoke that takes a single PMC? (I may also have
situations where I don't need to follow pdd03, and it would be more
convenient to use a different register.)
Leopold Toetsch
> The invoke op is bothering me -- namely, it disturbs me that it
> implicitly operates on P0. I know that P0 is the correct register to
> use according to pdd03, but I dislike having it be implicit. The user
> is required to set the rest of the pdd03 conventions up manually, so I
> don't see any need for invoke to be different. And it makes it much
> more clear what registers are being used if you have to pass in a PMC
> as an argument.
Sean O'Rourke proposed a long time ago, that with should have
B<invoke_p> too. The current B<invoke> is fine for pdd03 only (where
(almost) all other P registers might be parameters, but for calling
Subs, compiled code, coroutines and so on, there is really no need, to
not be able to select the object, which should get invoke'd.
> So would anyone mind if I eliminated the zero-arg invoke op in favor
> of a one-arg invoke that takes a single PMC? (I may also have
> situations where I don't need to follow pdd03, and it would be more
> convenient to use a different register.)
Yep. At least add B<invoke Px>.
leo
Dan Sugalski
>The invoke op is bothering me -- namely, it disturbs me that it
>implicitly operates on P0. I know that P0 is the correct register to
>use according to pdd03, but I dislike having it be implicit. The user
>is required to set the rest of the pdd03 conventions up manually, so I
>don't see any need for invoke to be different.
It isn't, though. You have to set up P0 just like all the other
registers you're using. It's not like invoke makes you specify them
either. (Though I could certainly see a case for a version that takes
counts as parameters and sets up the I registers appropriately, for
speed reasons)
>And it makes it much
>more clear what registers are being used if you have to pass in a PMC
>as an argument.
>
>So would anyone mind if I eliminated the zero-arg invoke op in favor
>of a one-arg invoke that takes a single PMC? (I may also have
>situations where I don't need to follow pdd03, and it would be more
>convenient to use a different register.)
Leave the zero-arg version in there, since the common case will be
invoking routines that are conforming to the calling conventions, and
thus have all the registers set up per PDD03. I fully expect anything
with even a minimal amount of self-introspection will be rummaging
around in that sub object, so having it in a fixed location will be
the right thing.
I'm OK with a one-arg version, as long as it's made explicit in the
docs that code that uses it makes no guarantees about the state of
any of the registers.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Steve Fink
> Steve Fink wrote:
>
> >So would anyone mind if I eliminated the zero-arg invoke op in favor
> >of a one-arg invoke that takes a single PMC? (I may also have
> >situations where I don't need to follow pdd03, and it would be more
> >convenient to use a different register.)
>
> Yep. At least add B<invoke Px>.
Ok, done.
Leopold Toetsch
> Ok, done.
Good.
One minor note - and it is my fault to haven't documented that in the
first place - I did revert all the other changes, they are necessary for
pbc2c compiled code.
Of course, it would be better, to have another set of macros, that
state: "This offset ought to be a real PBC offset".
leo
Steve Fink
>
> Good.
> One minor note - and it is my fault to haven't documented that in the
> first place - I did revert all the other changes, they are necessary for
> pbc2c compiled code.
> Of course, it would be better, to have another set of macros, that
> state: "This offset ought to be a real PBC offset".
Oops, sorry, I didn't mean to commit that part until I figured out
what was going on.
I think I kind of have a grasp on what's going on, now. So I've
attached two possible patches. The first just implements a new macro
OP_SIZE that can be used to calculate relative offsets. The second
goes further, and replaces expr_offset() for the pbc2c version so that
it computes start_code-relative offsets. Nothing appears to be using
the current version, which would only work for constant offsets
anyway. (The second also includes the OP_SIZE macro, but doesn't use
it -- so apply one or the other.)
I feel that my grasp of the situation is tenuous enough that I don't
want to commit the second without someone checking it over, and the
first isn't needed if the second is applied.
I also noticed that rx.ops doesn't look like it'll work with pbc2c
because it uses 'goto OFFSET' in a macro, and
Parrot::OpTrans::Compiled needs to know the relative PC of the current
instruction.
And finally, jsr seems to be broken with pbc2c (and maybe other cores,
I don't know.)
Steve Fink
> At 10:20 AM -0800 2/20/03, Steve Fink wrote:
> >The invoke op is bothering me -- namely, it disturbs me that it
> >implicitly operates on P0. I know that P0 is the correct register to
> >use according to pdd03, but I dislike having it be implicit. The user
> >is required to set the rest of the pdd03 conventions up manually, so I
> >don't see any need for invoke to be different.
>
> It isn't, though. You have to set up P0 just like all the other
> registers you're using. It's not like invoke makes you specify them
> either. (Though I could certainly see a case for a version that takes
> counts as parameters and sets up the I registers appropriately, for
> speed reasons)
I suppose that's true, if you really are doing full externally-visible
(pdd03-compliant) invoke() calls. But if you're doing internal stuff,
then it starts to matter what things are part of the invoke()
interface, and what things are purely (calling) convention.
At the moment, Sub.pmc's invoke() really only looks at P0. Will it
eventually use all of pdd03's registers, or will some of that always
be handled by the callee? I don't really know the fundamental
motivation underlying 'invoke', so I can't guess the answer to this.
I suppose if invoke is going to be used for multiple dispatch, then it
really will use everything -- register counts, return type, the actual
parameters, etc.
> I'm OK with a one-arg version, as long as it's made explicit in the
> docs that code that uses it makes no guarantees about the state of
> any of the registers.
> --
I'll need the answer to the previous question before I can write those
docs.
Leopold Toetsch
> On Feb-23, Leopold Toetsch wrote:
>
> I think I kind of have a grasp on what's going on, now. So I've
> attached two possible patches.
I'm currently on the imcc stuff and could have a more detailed look at
both patches after. But I think, both have the same effect on generated
code - and while the 2. seems to address the issue at the root of the
problems, you could just commit it.
leo
Steve Fink
Committed.