On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
> > ... However, if a continuation restores registers to the data they
> > had when the continuation was taken, then all of the registers will
> > contain the things that exactly
On Tue, 23 Nov 2004 23:26:39 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
> > Have we seen that this actually destroys us? Meaning, if we add the
> > extra CFG arcs, do we start spilling like mad? If not, this is much
> > ado about nothing.
>
> Please first have a lo
Leo~
On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
>
> > Won't your approach put every one of those things in its own register?
>
> I've clearly stated that lexicals aka non-volatiles have distinct
> registers.
Thus for t
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Won't your approach put every one of those things in its own register?
I've clearly stated that lexicals aka non-volatiles have distinct
registers.
> ... However, if a continuation restores registers to the data they
> had when the continuation was taken
I've now removed the code that preserved P0, P1, P2 around calls. All
code that assumes P0 is the current sub ... now just breaks.
Please use the syntax construct described in the deprecation warning.
Currently failing tests: t/library/streams.t11, 14, 17, 19
leo
Leo~
On Tue, 23 Nov 2004 23:26:39 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
> > Have we seen that this actually destroys us? Meaning, if we add the
> > extra CFG arcs, do we start spilling like mad? If not, this is much
> > ado about nothing.
>
> Please first hav
Matt Fowles wrote:
Have we seen that this actually destroys us? Meaning, if we add the
extra CFG arcs, do we start spilling like mad? If not, this is much
ado about nothing.
Please first have a look at Dan's recent posting about Evil Sub. Then
estimate, how many subs may be called in 14000 basic
At 12:27 PM -0500 11/23/04, Dan Sugalski wrote:
At 9:17 AM -0800 11/23/04, Bill Coffman wrote:
Wait, I just thought of a huge change.
Dan, Does the patch you have implement Leo's U_NON_VOLATILE patch?
It was the patch originally attached to this ticket, over a stock
parrot from CVS. If there's som
Leo~
On Tue, 23 Nov 2004 21:15:33 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Below inline/attached are some thoughts WRT the subject.
>
> leo
>
>
> Lexicals, continuations, and register allocation
>
> 1) Recent discussions have shown that we obviously can't handle all
> the side effec
Below inline/attached are some thoughts WRT the subject.
leo
Lexicals, continuations, and register allocation
1) Recent discussions have shown that we obviously can't handle all
the side effects of continuations correctly. Reusing preserved
(non-volatile) registers after a call isn't possible any
At 9:17 AM -0800 11/23/04, Bill Coffman wrote:
Wait, I just thought of a huge change.
Dan, Does the patch you have implement Leo's U_NON_VOLATILE patch?
It was the patch originally attached to this ticket, over a stock
parrot from CVS. If there's something else to try let me know -- I'm
all for i
Wait, I just thought of a huge change.
Dan, Does the patch you have implement Leo's U_NON_VOLATILE patch? If
so, that restricts from 32 to 16 registers, in various cases for
*non-volatile* symbols (did I get that right?). Anyway, the symbols
that cross sub calls can only use 16 registers, where
At 5:40 PM +0100 11/23/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
I can't. My dev machine's running gcc 2.95.4, and gcc throws lisp
error messages compiling the switch core if I turn on optimizations.
You could try:
- perl Configure.pl --optimize
- make -s
- wait a bit unt
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I can't. My dev machine's running gcc 2.95.4, and gcc throws lisp
> error messages compiling the switch core if I turn on optimizations.
You could try:
- perl Configure.pl --optimize
- make -s
- wait a bit until first files start compiling
- interrupt it
At 8:25 AM -0800 11/23/04, Bill Coffman wrote:
On Tue, 23 Nov 2004 09:27:12 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
The parrot I have, which is a day or two out of date, takes 7m to
churn through one of my pir files. With this patch, I killed the run
at 19.5 minutes.
I'd be interested in
On Tue, 23 Nov 2004 09:27:12 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The parrot I have, which is a day or two out of date, takes 7m to
> churn through one of my pir files. With this patch, I killed the run
> at 19.5 minutes.
I'd be interested in getting this code for testing. The big one
Dan~
On Tue, 23 Nov 2004 10:43:57 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:15 AM -0500 11/23/04, Matt Fowles wrote:
> >All~
> >
> >Aperiodically I notice that my parrot directory has quite a few core
> >files in it (usually around 6), even though I have done nothing with
> >it except
At 10:15 AM -0500 11/23/04, Matt Fowles wrote:
All~
Aperiodically I notice that my parrot directory has quite a few core
files in it (usually around 6), even though I have done nothing with
it except "cvs -q update -dP; [make realclean;perl Configure.pl;]
make; make [full]test". Usually it says th
At 4:02 PM +0100 11/23/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
The parrot I have, which is a day or two out of date, takes 7m to
churn through one of my pir files. With this patch, I killed the
run at 19.5 minutes.
One more note: be sure to compile Parrot optimized - the new
reg_alloc.c h
At 3:54 PM +0100 11/23/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
The parrot I have, which is a day or two out of date, takes 7m to
churn through one of my pir files. With this patch, I killed the
run at 19.5 minutes.
Sh... That's one of the smaller ones I presume.
Nope, one of the biggest. S
All~
Aperiodically I notice that my parrot directory has quite a few core
files in it (usually around 6), even though I have done nothing with
it except "cvs -q update -dP; [make realclean;perl Configure.pl;]
make; make [full]test". Usually it says that all of the tests pass or
one or two tests f
Dan Sugalski wrote:
The parrot I have, which is a day or two out of date, takes 7m to churn
through one of my pir files. With this patch, I killed the run at 19.5
minutes.
One more note: be sure to compile Parrot optimized - the new reg_alloc.c
has some very expensive sanity checks in debug mode
Dan Sugalski wrote:
The parrot I have, which is a day or two out of date, takes 7m to churn
through one of my pir files. With this patch, I killed the run at 19.5
minutes.
Sh... That's one of the smaller ones I presume. How many basic blocks
and variables are listed with -v?
Thanks,
leo
Alberto Manuel Brandão Simões <> wrote:
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ---
> t/library/streams.t2 512212 9.52% 14 17
Yep. Currently failing due to explicit call regi
At 11:35 AM +0100 11/17/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
Okay. I'll apply it and take a shot. May take a few hours to get a
real number.
How does it look like? Any results already?
Okay, got some time this morning. Two of the patch hunks were already
in, so I skipped 'em. The result
Maybe this is normal (underdevelopment) fails, and in that case, ignore.
Cheers, alb
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/library/streams.t2 512212 9.52% 14 17
3 tests and
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> Parrot_compreg(Parrot_Interp interpreter, STRING *type, PMC *func)
> It claims to take a PMC, while it really take a C-function pointer.
Yes. The function was intended as a general interface to register a
compiler, which could also be a PASM/PI
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #32577]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32577 >
ops/ops.num opcode numbers don't match real opcode numbers, if opcodes
are missin
On Mon, Nov 22, 2004 at 10:11:42PM -0800, prashanth wrote:
> # New Ticket Created by prashanth
> # Please include the string: [perl #32573]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org:80/rt3/Ticket/Display.html?id=32573 >
>
>
> I having proble
# New Ticket Created by prashanth
# Please include the string: [perl #32573]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32573 >
I having problem installation rt-3.2.1 on redhat ÃÂ. I need steps to install
correctly o
Matt Fowles wrote:
It is also possible for functions to jump forward to the return
continuation of a function called later on
Yes. But I can't see a problem with that. The opcode after an invoke
opcode is already the begin of a new basic block. The forward branch
would just be an additional edge
31 matches
Mail list logo
