On Sun, Sep 28, 2003 at 12:59:52PM -0700, Steve Fink wrote:
I don't know whether Perl6 or any other language we want to be nice to
has *non-constant* defaults. If so, and if we want direct support for
them, then it means we need to evaluate them in the context of the
callee.
Depends on what
Steve Fink [EMAIL PROTECTED] wrote:
On Sep-28, Leopold Toetsch wrote:
So we should specify, what to do with wrong param counts or wrong
types. pcc.t has some examples for this (labeled unproto or
exception).
I was arguing that this isn't enough. We need the set of parameters to
really be
Dan Sugalski [EMAIL PROTECTED] wrote:
I'm reworking the base vtable registration system at the moment. I'll get
the return conventions finished right after that. Should be a few hours.
^:)
Some remarks WRT pdd03:
Calling
Steve Fink wrote:
I don't know whether Perl6 or any other language we want to be nice to
has *non-constant* defaults.
Ruby appears to support non-constant, mutable defaults:
% irb
irb(main):001:0 $foo=[]
[]
irb(main):002:0 def x(n=$foo)
irb(main):003:1 n 1
On Sep-26, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
[ splatted function args ]
... For this, I think we're
going to need a setp Ix, Py op which does indirect register addressing.
Done.
Cool, thanks!
With it, I've been able to get a bit farther. Found a minor bug
Steve Fink [EMAIL PROTECTED] wrote:
With it, I've been able to get a bit farther. Found a minor bug where
it multiply defines a label if you make two calls.
Oh well, allways these nasty complicate programs, that want to call a
sub twice :) Fixed, thanks.
I'm not sure IMCC is going to be able
On Sep-28, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
I'm not sure IMCC is going to be able to autogenerate the prototyped
and nonprototyped versions of the callee's entry code from the same
set of .param declarations.
This is currently implemented as the unprototyped
Dan Sugalski [EMAIL PROTECTED] wrote:
[ splatted function args ]
... For this, I think we're
going to need a setp Ix, Py op which does indirect register addressing.
Done.
I named it Csetp_ind though, to more clearly discern it from Cset.
.flatten_arg _AV_x is implemented too.
Checking for
Luke Palmer wrote:
Dan Sugalski writes:
... For this, I think we're
going to need a setp Ix, Py op which does indirect register addressing.
Fair enough. I do suppose there will be a way to keep the register
allocation intact while doing this. Or maybe these ops are for IMCC's
personal use,
Ah, I reread one of your earlier posts. It appears that you are
proposing to pass the arguments in a PerlArray. So flattening is
possible.
Then what I am saying is that
sub f($a,$b) { ... }
is going to expect $a to be in P5 and $b to by in P6. In your scheme,
$a would be in P5[0] and $b would
Steve Fink [EMAIL PROTECTED] wrote:
That is you pass (3, _AV_x[0], ... _AV_x[i], _AV_y[0], ...).
Ok, we don't seem to be communicating.
Ok. Restart. Brain reset. I had a thinko somewhere.
I proposed .args simply because it seemed easier to implement than
runtime .arg directives. Would you
Leopold Toetsch writes:
Steve Fink [EMAIL PROTECTED] wrote:
That is you pass (3, _AV_x[0], ... _AV_x[i], _AV_y[0], ...).
Ok, we don't seem to be communicating.
Ok. Restart. Brain reset. I had a thinko somewhere.
I proposed .args simply because it seemed easier to implement than
Luke Palmer [EMAIL PROTECTED] wrote:
Okay, considering that it's hard to pack registers into an array, and
that it's easy to unpack an array into registers (in the context of
signatures), why don't we make the unprototyped calling conventions just
to pass everything in the overflow array?
On Wed, 24 Sep 2003, Luke Palmer wrote:
Okay, considering that it's hard to pack registers into an array, and
that it's easy to unpack an array into registers (in the context of
signatures), why don't we make the unprototyped calling conventions just
to pass everything in the overflow array?
Leopold Toetsch [EMAIL PROTECTED] writes:
Luke Palmer [EMAIL PROTECTED] wrote:
Okay, considering that it's hard to pack registers into an array, and
that it's easy to unpack an array into registers (in the context of
signatures), why don't we make the unprototyped calling conventions just
to
Steve Fink [EMAIL PROTECTED] wrote:
Just to be sure we're talking about the same thing:
sub f ($a, $b, $c) { ... }
$x = phase_of_moon('waxing') ? \f : \CORE::print;
$x-(3, [EMAIL PROTECTED], [EMAIL PROTECTED]);
I don't expect such contrived functions calls happen too often, but
anyway
On Tue, 23 Sep 2003, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
You seem to be suggesting something like:
No. My suggestion didn't cover splat arrays. When you don't know, what
sub you are calling, you just have to flatten the splatted args -
currently.
Another
On Sep-23, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
Just to be sure we're talking about the same thing:
sub f ($a, $b, $c) { ... }
$x = phase_of_moon('waxing') ? \f : \CORE::print;
$x-(3, [EMAIL PROTECTED], [EMAIL PROTECTED]);
I don't expect such contrived
On Sep-21, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
That would make it fun to track register usage.
And here is the problem with all these shortcuts.
But any one of these instructions could be treated by IMCC as
potentially reading from and writing to all PMC registers,
Steve Fink [EMAIL PROTECTED] wrote:
On Sep-21, Leopold Toetsch wrote:
Anyway, we should first finalize return conventions (it was proposed
these to be symmetric to calling conventions).
It seems like there was widespread agreement to that proposal. Dan?
Yep.
Then finish pcc.c.
What's
Steve Fink [EMAIL PROTECTED] wrote:
That would make it fun to track register usage.
And here is the problem with all these shortcuts. Anyway, we should
first finalize return conventions (it was proposed these to be symmetric
to calling conventions). Then finish pcc.c. Then we need code from HLL
On Sep-15, Dan Sugalski wrote:
On Sun, 14 Sep 2003, Steve Fink wrote:
But that's really just shifting the burden to the receiving end, which
will now have to filter P5..P(5+L1-1), P3[0..] into the appropriate
local variables. So what would be even easier, and probably just as
fast,
Steve Fink writes:
The callee side would then need to have a way of saying ...and all
the rest. So that would be
.params PythonArray foo
Or, perhaps we could have an ArgArray PMC, which, upon construction,
would examine the registers as per the calling conventions, and stick
all the
Luke --
Need it *actually* stick them in the array? Or, could it
just provide an array-like interface to the underlying
registers? Thats cheaper, especially if not all args are
going to get accessed.
Explaining how such a thing works to an optimizer that
wants to know when registers are being
Gregor N. Purdy writes:
Need it *actually* stick them in the array? Or, could it
just provide an array-like interface to the underlying
registers? Thats cheaper, especially if not all args are
going to get accessed.
I don't think so. What if you wanted to make a closure over the array?
Then
Steve Fink [EMAIL PROTECTED] wrote:
It would be tempting to change all pushtop,pushbottom,poptop,popbottom
ops into ones that had the start register and number of registers as
arguments.
No. These ops are used to save registers for the caller and not for
argument passing.
Yes, I know
Steve Fink [EMAIL PROTECTED] wrote:
I'm not sure how to use the current pdd03's calling conventions to
implement what I want right now. Let's consider Perl6:
First, that whole stuff definitely needs more clarification. Calling and
return conventions are not symmetrical, CI1 (number of items in
On Sun, 14 Sep 2003, Steve Fink wrote:
I'm not sure how to use the current pdd03's calling conventions to
implement what I want right now. Let's consider Perl6:
sub f ($a, $b) { ... }
f(1, 2);
f(1, 2);
(I'm not sure if that is correct Perl6 code -- what I mean is that I
call f
On Mon, 15 Sep 2003, Gordon Henriksen wrote:
Dan Sugalski wrote:
On Sun, 14 Sep 2003, Steve Fink wrote:
I suppose that was a question for the language list. But then I'd
have
to read the language list.
A fate worse than razor burn, to be sure. Possibly one worse than
really
Dan Sugalski wrote:
On Sun, 14 Sep 2003, Steve Fink wrote:
I suppose that was a question for the language list. But then I'd
have
to read the language list.
A fate worse than razor burn, to be sure. Possibly one worse than
really
bad Mexican food, but either way I'd not wish it on
On Sep-15, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
I'm not sure how to use the current pdd03's calling conventions to
implement what I want right now. Let's consider Perl6:
First, that whole stuff definitely needs more clarification. Calling and
return conventions are
I'm not sure how to use the current pdd03's calling conventions to
implement what I want right now. Let's consider Perl6:
sub f ($a, $b) { ... }
f(1, 2);
f(1, 2);
(I'm not sure if that is correct Perl6 code -- what I mean is that I
call f once with a perl-level prototype, and once without.
Steve Fink writes:
But that's really just shifting the burden to the receiving end, which
will now have to filter P5..P(5+L1-1), P3[0..] into the appropriate
local variables. So what would be even easier, and probably just as
fast, would be to say that unprototyped functions pass *all* of
33 matches
Mail list logo
