Re: Inf and NaN

icholas Clark <[EMAIL PROTECTED]> wrote: On Sun, Jul 30, 2006 at 10:45:29PM -0700, jerry gay wrote: > don't forget about negative-not-a-number, and the quiet (or signaling) Ah yes. that oxymoron. I've never yet seen the reasons for why it exists at all. Does anyone have a URL? Nicholas Clark -- Bill Coffman ~~~_\\\|/ ~~~-(@ @) =oOO=(_)==OOo===

Re: [perl #38887] Result of INFINITY or NAN stringification is platform dependent

some tests): >type test.pir .sub main # -INF set N0, 0.0 ln N1, N0 print N1 print "\n" # +INF abs N2, N1 print N2 print "\n" # NaN set N3, -1.0 sqrt N4, N3 print N4 print "\n" .end # trunk >parrot test.pir -1.#INF00 1.#INF00 -1.#IND00 # local >parrot test.pir -inf inf NaN Thanks, Ron -- Bill Coffman ~~~_\\\|/ ~~~-(@ @) =oOO=(_)==OOo===

Re: [perl #36407] [BUG] imcc - register allocation

Isn't the register allocator pretty much minimized by the new architecture implementation? My understanding was that only temporary variables could benefit from it now. Perhaps the new changes aren't in effect yet? Just curious. On 6/28/05, via RT Leopold Toetsch <[EMAIL PROTECTED]> wrote: >

Re: Hackathon Day 2+3 Report

On 6/13/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote: > > I've posted a report on the Hackathon Days 2+3 as a journal entry on > use.perl.org : > > http://use.perl.org/~chip/journal/25182 > > I'm not going to copy it here, but you probably want to read it, if > only because

Re: Attack of the fifty foot register allocator vs. the undead continuation monster

people who would be happy to do so, if this issue could be resolved. -- -Bill Coffman

Re: Register Allocation and Continuations problem definition

t wants this thread to be a problem definition, so these thoughts seem appropriate for this thread. I hope no one is offended by my bluntness, but if this problem is to be solved, it must be understood. Bill Coffman ps: a couple important threads on this issue were http://groups-beta.go

Re: Regarding Google's Summer of Code 2005

nternals mailing list for continuations and register allocation. I'm sure you'll find it. The above not withstanding, I think there are still quite a few things that can be done to improve register allocation in parrot. If anyone is interested, I'm sure I could dig up my code. Bill

Re: continuation enhanced arcs

All, As with most technical problems, fully specifying them, is often half the battle. In this case, I think we're getting close to understanding the issues at least. [please treat all statements as possible questions] First, consider my original post in this thread: http://www.nntp.perl.org/gr

Re: continuation enhanced arcs

On Tue, 30 Nov 2004 14:45:39 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 11:20 AM -0800 11/30/04, Jeff Clites wrote: > >% cat continuation6.ruby > >def strange > > callcc {|continuation| $saved = continuation} > >end > > > >def outer > > a = 0 > > strange() > > a = a + 1 > >

Re: continuation enhanced arcs

Hello All, I haven't been able to devote much time lately, but this week I hope to modify the register allocator to deal with these arcs, as well as enhancements to the spill code. I expect that in some cases it will have a definite impact on speed, and others it won't. Most of the test cases (ma

Re: Lexicals, continuations, and register allocation

On Wed, 24 Nov 2004 09:39:27 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Bill Coffman wrote: > > On Tue, 23 Nov 2004 23:26:39 +0100, Leopold Toetsch <[EMAIL PROTECTED]> > > wrote: > > > Keep in mind that you don't actually have to add all those

Re: Lexicals, continuations, and register allocation

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

Re: Lexicals, continuations, and register allocation

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

Re: [perl #32418] Re: [PATCH] Register allocation patch - scales better to more symbols

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

Re: [perl #32418] Re: [PATCH] Register allocation patch - scales better to more symbols

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

continuation enhanced arcs

Hello all, I would like to address the problem of how continuations have affected the register allocator. This problem came to the public eye, when two tests that the new register allocator failed. Leo's analysis was essentially that the allocator was fine, but that our handling of continuations

Re: silent effects of opcodes

On Thu, 18 Nov 2004 08:13:02 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Bill Coffman <[EMAIL PROTECTED]> wrote: > > ps: I'm making progress on grokking the cfg and register renaming > > stuff. Will let you know. > > This needs an SSA graph of the d

Re: silent effects of opcodes

> >* [NEW] If register 15 or below is used, it should be cleared out, > >ZEROED, after it's last use and before the next sub call. This is for > >security reasons. Obviously, these registers will not be the first > >choice to use. > > Nope -- this isn't the job of the register allocator. We aren

Re: silent effects of opcodes

So to generalize. The following registers are available, under the following conditions: * Registers R16-R31 are always available for the allocator. * Registers R0-R15 are available between sub calls. That is, for any symbol, whose life range does not cross a subroutine. (This implies that all

Re: silent effects of opcodes

On Wed, 17 Nov 2004 14:14:18 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > I've now (locally here) extended Bill Coffman's register allocator by > one subroutine that actually decides to use non-volatiles or volatiles > according to pdd03. All variables that are live around a subroutine call

Re: IEEE 754 double floats

Another way is to count the bits, as in the following: .sub _main N1 = 1 N2 = 0.5 I0 = 0 REPEAT: I0 = I0 + 1 N2 = N2 / 2 N3 = N1 + N2 ne N1, N3, REPEAT print I0 print " bits precision\n" end .end On Wed, 17

Re: Continuations, basic blocks, loops and register allocation

On Sun, 14 Nov 2004 17:03:33 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 5:53 PM +0100 11/13/04, Leopold Toetsch wrote: > >As the analysis of test errors of the new reigster allocator has > >shown, we have a problem WRT register allocation. This problem isn't > >new, but as the allocator is

Re: Another issue with pdd03

PDD03: Responsibility for environment preservation PDD03: PDD03: The caller is responsible for preserving any environment it is interested PDD03: in keeping. This includes any and all registers, lexical scoping and PDD03: scratchpads, opcode libraries, and so forth. PDD03: PDD03: Use of the save

Re: Register allocation/spilling and register volitility

On Mon, 8 Nov 2004 12:20:19 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Jeff Clites <[EMAIL PROTECTED]> wrote: > > On Nov 8, 2004, at 1:34 AM, Leopold Toetsch wrote: > > >> If frames aren't adjacent, normal argument copying can be done anyway. > > > This would seem to require the same typ

Re: register allocation

> These errors look remarkable the same, when I turn on OPT_SUB that is, > when allocate_wanted_regs() is used. And this code did miss registers > sets like 'K' (compound keys). > > Changing imcc/reg_alloc.c:890 to: > >if (r->color >= 0 || r->want_regno == -1 || strchr("ISPN", r->set > ==

Re: register allocation

ndled in reg_alloc. Maybe it should be? ~Bill On Fri, 12 Nov 2004 10:26:51 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Bill Coffman wrote: > > Hello, > > * I have the below failed tests. I haven't looked into these. Can > > someone tell me if the t

Fwd: register allocation

Trying again... -- Forwarded message -- From: Bill Coffman <[EMAIL PROTECTED]> Date: Thu, 11 Nov 2004 14:05:29 -0800 Subject: register allocation To: Perl 6 Internals <[EMAIL PROTECTED]> Hello, I have addressed almost all the code issues from the last patch. Tha

register allocation

Hello, I have addressed almost all the code issues from the last patch. That broke some things, which I had to fix, but they're fixed. A couple other improvements too. Here's the state of things: * I have the below failed tests. I haven't looked into these. Can someone tell me if the tests a

Re: Solicitation of Ideas for Performance Statistics and Graphs

On Wed, 3 Nov 2004 12:52:26 -0800 (PST), Joshua Gatcomb <[EMAIL PROTECTED]> wrote: [snip] > What we would like to do is determine if what we have > done so far is sufficient or, if not, what specifically > people would like to see. Some of our unimplemented > ideas so far are: > 1. Include the co

Re: [perl #32208] [PATCH] Register allocation patch - scales better to more symbols

Hello, Just getting back to parrot. [Leo]* alloca() isn't portable and not available everywhere [Dan] Yep. This is a gcc-ism. Use Parrot's memory allocation functions instead. reg_alloc.c uses malloc(). I saw alloca() used in the CVS tree earlier, but it's gone now. What is the correct way to a

Re: [perl #32208] [PATCH] Register allocation patch - scales better to more symbols

Sounds like the memory leak. Let me try to fix this, and address the other issues. I'll get back to you. Thanks, -Bill On Fri, 29 Oct 2004 10:15:34 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 12:30 PM +0200 10/29/04, Leopold Toetsch wrote: > >Bill Coffman (via RT)

Re: register allocation questions

Thanks Matt, I hope I can help out. The patch I am submitting actually does simplify register coloring a bit. I've been waiting for perl6 with so much anticipation, I just couldn't stand it any more, and I had to participate. -Bill On Thu, 28 Oct 2004 18:17:57 -0400, Matt Fowles <[EMAIL PROTE

Re: register allocation

When I cvs up'd, cleared and reConfigure'd I got these stats: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/library/streams.t1 256211 4.76% 11 t/op/gc.t 1 25618

Re: C89

haps it's best to forget the whole C'89 thing. But maybe someone should remove that from the documentation? Just a thought. -Bill On Thu, 21 Oct 2004 22:41:36 -0700, Jeff Clites <[EMAIL PROTECTED]> wrote: > On Oct 21, 2004, at 11:51 AM, Dan Sugalski wrote: > > > At 11:2

Re: register allocation questions

t least one of the reg sets. > >[1] all except Dan's 6000 lines subroutines :) Did you start > >creating real subs for your code already? > > I wish. :( Unfortunately not, outside some simple stuff, and I doubt > I will. The language just doesn't lend itself to

register allocation questions

registers, but this seems strange, and there seems to be a little more going on than finding non-conflicting registers for variable names. The -d 008 output seems to produce pretty much the same thing, but just different registers. Maybe someone can point me at something to look at to fix this. I'll provide the patch if someone would like to play with it. Thanks to all who made it this far, Bill Coffman

C89

I read somewhere that the requirement for parrot code is that it should be compliant with the ANSI C'89 standard. Can someone point me to a description of the C89 spec, so I can make sure my reg_alloc.c patch is C89 compliant? Thanks, - Bill

Re: Pathological Register Allocation Test Generator

Leo, Thanks for your suggestions and comments. On Wed, 20 Oct 2004 10:35:04 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Some remargs WRT gen{3,4}.pl: > 1) While these programs exhibit some worst case register layout it's >probably not a very typical layout. Agreed. The idea was to a

Re: Pathological Register Allocation Test Generator

I've tried to do, in a very modest way, in my scripts. Thanks to Gregg Purdy for getting the ball rolling in this general direction. Thanks, Bill Coffman On Mon, 11 Oct 2004 09:54:31 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 4:58 PM -0700 10/2/04, Gregor N. Purdy wrote: >