Calling conventions
Dan Sugalski
gotten to the point where it's obvious that we're not going to get
anywhere. So, this is what we're going to do:
1) The changes I proposed are going in. We get arg counts for I/S/N
registers if they're used. Everyone can cope. (You may, if you
choose, whine about it for a bit--that's OK, if somewhat unbecoming)
2) I'm adding in an alternate, link-time, non-overridable subroutine
call sequence. This is for routines which may not change in any way
at runtime. They may or may not be sub-PMC based. Probably not. This
will cause some issues with perl/python/ruby code that would choose
to manipulate the subs, but there are ways around it, and people can
cope.
3) We're going to add some metadata (virtually to start) to note
library versions, sub signatures, and whatnot so we've some chance of
catching signature errors (which usually indicate a deeper versioning
problem) at link and, hopefully, runtime.
Not much more to say about #1 than "I disagree", and I think we've
dealt with that problem.
#2 will introduce, I think, a:
call X, Y
op, where X is the start of the bytecode to call and Y is the
bytecode segment header, or something like that. *NOTE THAT THIS IS
NOT SET IN STONE!* or mud even. I'm fine with a completely different
format. Anyway, X and Y are resolved at link time which, for us, is
bytecode load time. (Unless we bring in a linker. Maybe for V2)
Since these are essentially addresses which are resolved at link time
there's no way that they can be overridden, which is arguably a Bad
Thing. Certainly will get in the way of folks looking to do exactly
that. Well... too bad. Wrap the non-overridable version in an
overridable version and be done with it.
#3 is going to be important so we can have signatures that we can
reliably mark as non-overridable (though I suppose just properties on
the sub PMCs that the compiler can note is OK. Still, we need to
define those), floor values for library versions so people can note
breaks in compatibility, signatures on functions and subs, *versions*
on subs and functions (potentially) all will be useful to make sure
that we can, hopefully, have some chance of noting that things have
changed.
Oh, and we need to make sure that the global stash that we're using
to store subs checks function signatures when existing
subs/methods/whatever are overridden, because we need to be able to
pitch a fit if that's the case, even if we don't complain by default.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Joe Wilson
> 1) The changes I proposed are going in. We get arg counts for I/S/N
> registers if they're used.
What purpose do these individual I/S/N arg counts serve exactly?
To simply check how many arguments are passed to a function you would
need to get the sum of the number of I/S/N/P argument counts.
This is needlessly complicated and slow. And that's just the beginning
of the fun - variable argument functions simply cannot be written
using this calling convention - just think of the issues with argument
ordering, default arguments and type promotion.
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
Dan Sugalski
>Dan Sugalski wrote:
>> 1) The changes I proposed are going in. We get arg counts for I/S/N
>> registers if they're used.
>
>What purpose do these individual I/S/N arg counts serve exactly?
You missed a bit when quoting. This bit, specifically:
>Everyone can cope. (You may, if you choose, whine about it for a
>bit--that's OK, if somewhat unbecoming)
Melvin Smith
>At 4:00 PM -0800 11/16/03, Joe Wilson wrote:
>>Dan Sugalski wrote:
>>> 1) The changes I proposed are going in. We get arg counts for I/S/N
>>> registers if they're used.
>>
>>What purpose do these individual I/S/N arg counts serve exactly?
>
>You missed a bit when quoting. This bit, specifically:
>
>>Everyone can cope. (You may, if you choose, whine about it for a
>>bit--that's OK, if somewhat unbecoming)
Rather than whining, I'm reworking IMCC so we can support multiple
parallel calling conventions and select a specific one by a pragma.
We can then do side-by-side benchmarks of the same code and play
around without breaking existing high level languages.
Once I'm done you won't even be able to see the calling convention
from IMCC, except in cases where you really want to. (see my last 2 patches)
-Melvin
Melvin Smith
problems, but when I have problems sitting in front of me, I can
usually solve them.
The situation we have now is: Parrot is a VM, and technically we could
just punt the whole calling convention issue to a high level languages forum
(parrot-languages if there was one) or something, but sadly that wouldn't
work, because currently there aren't enough people to go around.
What we really need is for some languages group to step up
and start a working paper on the possible high level constructs
that will present potential issues for Parrot, and show some potential
solutions for compiling them, and look at those issues when
related to maintaining backwards compatibility for old bytecodes.
The paper should probably be language specific.
I do like Tim's suggestion of multiple entry points for a given sub
in a module, but rather than discuss it much further, I'd like to
be presented with a clear sample and clear requirements beforehand.
I also do not think the Parrot core developers should have to
take responsibility of every possible issue because one language's
issues are not an issue for another. The questions is, how much
do we specify as a "Parrot Standard" as opposed to a language
specific standard.
I see 2 possible paths, both equally viable for us to take.
a) Parrot Standard specifies that all bytecodes will be compatible
with both prototyped calls and non-prototyped calls,
and all high level languages on Parrot will just magically work
together, even though the code will probably be a lot fatter.
b) Parrot Standard specifies what conventions are _available_, but
not which to use. If a high-level language lends itself to prototypes
and high levels of optimization, it should not have to suffer. Let library
writers write "glue" code, as they do now, if they wish to interact between
languages. Glue code might be as simple as defining certain entry points
(subs) as "unprototyped."
As far as requirements, I don't know whether it is (a) or (b) or neither.
Sometimes requirements are a luxury, but its hard for a group of open
source developers to get much done without any, and in this
case I think we really need them.
I like (b) because it is more flexible, and actually accomplishes the
same goal in (a), but lets the developer decide when and where
it makes sense to "work together".
-Melvin
Joe Wilson
Perhaps another register can hold the number of problems
with this calling convention.
<rim shot>
>Dan Sugalski wrote:
>> 1) The changes I proposed are going in. We get arg counts for I/S/N
>> registers if they're used.
>
>What purpose do these individual I/S/N arg counts serve exactly?
You missed a bit when quoting. This bit, specifically:
>Everyone can cope. (You may, if you choose, whine about it for a
>bit--that's OK, if somewhat unbecoming)
__________________________________
Dan Sugalski
> The situation we have now is: Parrot is a VM, and technically we could
> just punt the whole calling convention issue to a high level languages forum
> (parrot-languages if there was one) or something, but sadly that wouldn't
> work, because currently there aren't enough people to go around.
Right, and we're looking to be efficient for our core language set, so
it's in our interests to make sure that we're a good fit there. There,
unfortunately, is a land of variable-length argument lists and named
argument processing. Which we'll need to deal with shortly, but that's for
Part 2, and'll live on top of the base conventions. But to snip wildly:
> b) Parrot Standard specifies what conventions are _available_, but
> not which to use.
This is pretty much it. We mandate what the caller must provide, and under
what circumstances, to conform to conventions. (And we're getting
multi-layer conventions, in part because they'll make the low-level
library code faster) Beyond that it's all up in the air--nobody's going to
force any language compiler to use the provided information.