Calling convention changes. Again. (And hopefully for the last time)
Dan Sugalski
Yeah, I know, I've said that before, but I think this round fixes up
all the pending problems.
The big things that have been addressed are:
1) Prototype language in PDD03 has been clarified
2) The overflow parameters now go into an Array passed in register
P3, rather than on the stack.
#1 was just a matter of cleaning up sloppy language and some sloppy
thought behind it.
#2 addresses some issues that were cropping up about calling into
coroutines and who got control over what, and how to represent stack
data. (Along with efficient access to data on the stack, and suchlike
stuff) Since I just didn't want to have to deal with that, we're
not--we pass in parameters entirely in registers and that's it.
The changes are in PDD03, so if the interested folks could look them
over, we can hash out any lingering dopey parts and make sure we're
where we want to be with this. I'm also more than up for hashing out
helper ops, convenience ops, and other things. (I'm pondering
built-in signature checking, for example)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Brent Dax
# stuff) Since I just didn't want to have to deal with that, we're
# not--we pass in parameters entirely in registers and that's it.
With this change, the user stack is no longer being used for argument
passing. What is it used for? If nothing, should we get rid of it?
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
K Stol
----- Original Message -----
From: "Brent Dax" <bren...@cpan.org>
To: "'Dan Sugalski'" <d...@sidhe.org>; <perl6-i...@perl.org>
Sent: Monday, May 05, 2003 2:27 AM
Subject: RE: Calling convention changes. Again. (And hopefully for the last
time)
> Dan Sugalski:
> # stuff) Since I just didn't want to have to deal with that, we're
> # not--we pass in parameters entirely in registers and that's it.
>
> With this change, the user stack is no longer being used for argument
> passing. What is it used for? If nothing, should we get rid of it?
>
I think not, It's really handy to have a place to store stuff. I'll probably
use it for things like this (here's an example):
a, b, c = f(), g()
This is an assignment statement. First all expressions on the RHS are
evaluated. Then they are assigned to
a, b and c respectively. Because first f is called, I need a place to stuff
the results, because its results are
in registers starting at P5 (s. calling conv.) If the results would not be
saved, the results of g would overwrite the
results of f.
Of course, I'm no designer or expert at this point, but when all sorts of
languages will be compiled to Parrot (and that will be the case, won't it?),
I think it is nice when Parrot has some features (like a stack to store
stuff) to make targeting Parrot easier.
Klaas-Jan.
Luke Palmer
Yeah, hmm. I've been thinking about exceptions (which Parrot has no
support for yet, right?), and I wonder if the user stack could
actually cause problems. For instance, routine A stores some stuff on
the stack. Then it calls B, which also stores some stuff on the
stack. B calls C which throws an exception that passes through B and
into A, which catches it. However, A's stack isn't what it thinks it
is, because it has the stuff B put on it first.
I've been considering a C<pushframe> op or some such thing, which
would set up a subcall (and it seems that the caller would have to
call this, according to the calling conventions). It would halfpush,
put a mark on the user stack (if it exists), and do anything else
necessary. Then when exceptions are propigating up the control stack,
they could pop the user stack up to each mark, and halfpop registers,
basically restoring state up to where somebody catches it. Probably
with C<popframe>.
Is there a plan for exceptions?
Luke