Bill Coffman [EMAIL PROTECTED] wrote:
Since I understand the item about allocating registers between sub
calls, I can probably implement that change, as I work through the
control flow/data flow analysis.
I've no resynced pending changes with the old allocator and committed
these changes.
Here's again a summary of upcoming changes. I'll commit for now just the
new returncc opcode. Other changes that start breaking things will
follow in a few days.
Summary:
1) PIR code using PIRs HLL call syntax doesn't need changes.
foo() # call sub foo
a = bar(x)# call bar
On Wed, Nov 17, 2004 at 11:07:28PM +0100, Leopold Toetsch wrote:
$ parrot pmfactbsr.imc
500500
3.459947
$ parrot -Oc pmfact.imc
500500
1.237185
Now what ;)
Are you sure, that you can't do a tailcall sometimes?
Sure, p6ge already makes heavy use of tailcalls. In a bsr/ret scheme,
the
On Wed, Nov 17, 2004 at 10:35:47PM +, Nicholas Clark wrote:
On Wed, Nov 17, 2004 at 02:47:09PM -0700, Patrick R. Michaud wrote:
BTW, it may be very possible for me to write the p6ge generator so
that it can be switched between the PIR and bsr/ret calling conventions,
so we don't need
Will Coleda wrote:
Robert has provided me access to the RT command line tool, which I scripted
around to generate this small report. I'd appreciate feedback on whether
or not something like this would be useful (and suggestions for other things
to report on are welcome.)
If we can settle on a
At 8:26 AM +0100 11/18/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Exceptions and continuations should be the same problem -- the target
is the start of a basic block. (Well, more than that, as they're
places where calling conventions potentially kick in) This means the
Dan Sugalski wrote:
If the point is to direct the allocator to flush temps and start fresh,
then we should just do it:
.flushtemps
The point basically is to insert a loop into the CFG. When we have
foo()
...
bar()
which is a linear control flow through these basic blocks, we need:
From: Jeff Horwitz [EMAIL PROTECTED]
To: Matt Fowles [EMAIL PROTECTED]
cc: Perl 6 Internals List [EMAIL PROTECTED]
Subject: Re: Perl 6 Summary for 2004-11-08 through 2004-11-15
Message-ID: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 15 Nov 2004,
Now that invocation semantics are fixed and permanent, we need some
cleanup of the code base to round out support. It's also time to get
some things in place that are part of the fallout from it.
The 'invoke the current return continuation' op apparently got lost
in the blowup. That needs to
At 11:06 AM -0800 11/18/04, Michel Pelletier wrote:
From: Jeff Horwitz [EMAIL PROTECTED]
To: Matt Fowles [EMAIL PROTECTED]
cc: Perl 6 Internals List [EMAIL PROTECTED]
Subject: Re: Perl 6 Summary for 2004-11-08 through 2004-11-15
Message-ID: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type:
Sun's cc compiler complains about dynclasses/matchrange.pmc:
matchrange.pmc, line 305: void function cannot return value
The following patch fixes it.
--- parrot-current/dynclasses/matchrange.pmcFri Sep 17 00:55:02 2004
+++ parrot-andy/dynclasses/matchrange.pmc Mon Nov 15 11:04:04
On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
I'd like pushing exception handlers to remain simple -- the current
system is almost OK. What I'd like it to change to is:
push_eh label
with popping the top exception handler being:
pop_eh
I'm up for better names,
On Thu, Nov 18, 2004 at 11:37:54AM -0800, chromatic wrote:
On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
I'd like pushing exception handlers to remain simple -- the current
system is almost OK. What I'd like it to change to is:
push_eh label
with popping the top
I'd like to see:
...
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
14 matches
Mail list logo
