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
irb(mai
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:
Calli
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
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 wha
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 "un
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
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
On Fri, 26 Sep 2003, 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.
>
> I named it C though, to more clearly discern it fro
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 C though, to more clearly discern it from C.
.flatten_arg _AV_x is implemented too.
Checking for overfl
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,
On Sep-24, Leopold Toetsch wrote:
> No. But you are right. That's the code (/s\$I2/\$I1/) that ".args"
> should produce. Perhaps we shoud name the directive ".flatten_arg".
Yes, that makes its purpose more clear than calling it ".args".
>
> Is it supposed to do deep flattening? Do we need ".deep
Dan Sugalski writes:
> In the variable list case things are messier, definitely. This requires a
> small chunk of code to decide which register things need to go in
> dynamically, with overflow on the overflow array. For this, I think we're
> going to need a "setp Ix, Py" op which does indirect
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 arra
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 convention
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
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 impleme
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
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
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
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.
>
> Ano
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, bu
On Sep-22, Leopold Toetsch wrote:
> Steve Fink <[EMAIL PROTECTED]> wrote:
> >> Then we need code from HLL to see, how efficient (or not) parameter
> >> passing does look like.
>
> > I've been trying to implement A6 for languages/perl6. My first cut was
> > to have all calls, prototyped or not, tak
On Mon, 22 Sep 2003, Leopold Toetsch wrote:
> 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 agree
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.
>
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 registe
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 HL
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?
Th
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 acc
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
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
> > f
Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> This sounds like the beginning of a whole set of things like "Warning
>> #238: suboptimal implementation of xxx. Are you sure you know what you
>> are doing?"
>
> If the user turns on optimization and the compiler finds such code, yes,
> why not.
SBCL
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.
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 conventi
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 i
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 wors
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
>
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, C (number of items in
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 t
38 matches
Mail list logo
