[perl #22387] [PATCH] simple constant propagation

# New Ticket Created by Matt Fowles # Please include the string: [perl #22387] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=22387 > All~ This patch adds simple constant propagation to imcc. The tests for this level of

[perl #22386] [PATCH] Make .constant constantly .const

# New Ticket Created by "Bryan C. Warnock" # Please include the string: [perl #22386] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=22386 > As mentioned previously. Makes IMCC and PASM constant keywords consistent, with '

Re: Register access

On 30 May 2003, Bryan C. Warnock wrote: > Ha ha, just kidding, of course. I'm all for it, but given my record > today, that might be an imminent sign of its rejection. Or, given your historical record, you may have just killed the thread ;). /s

Re: Register access

On Fri, 2003-05-30 at 19:42, Mitchell N Charity wrote: > Eeep. {snip snip} > So... > > I suggest existing register access be replaced with a new macro set >#define REG_INT(x) interpreter->ctx.int_reg.registers[x] >#define REG_NUM(x) interpreter->ctx.num_reg.registers[x] >#define REG_

Register access

Eeep. I was struck by this recent code fragment /* calling convention says that receiver should be in P2 and method in P0 */ interpreter->ctx.pmc_reg.registers[0] = method; interpreter->ctx.pmc_reg.registers[2] = $1; interpreter->ctx.string_reg.registers[0] = $2; which might be rewritt

Re: Timers (was Threads and Progress Monitors)

"Dulcimer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I find C too terse, and would > rather see a more verbose version I'm obviously more lazy than you ;-). > Ah. Ok, but if that's the case, you could as easily write it > >timeout(5) { coro { ... } }; > > and have the com

Re: Add #22337

Andy Switala <[EMAIL PROTECTED]> wrote: > I found this online: http://unixhelp.ed.ac.uk/CGI/man-cgi?posix_memalign. Thanks to you and Steve for the docs. I've now a test and platform code for both flavors of memalign. I'll send it later. leo

Re: Timers (was Threads and Progress Monitors)

--- Dave Whipp <[EMAIL PROTECTED]> wrote: > "Dulcimer" <[EMAIL PROTECTED]> wrote > > > But exposing the object like that still bothers be: I shouldn't > > > need the $tmp, nor the .new. > > > > I'm not so sure I agree with losing the new(). I kinda like that > > just for readability. Less isn't al

RE: Method calling

Calling convention says that before a sub/method is invoked: - P0 Holds the object representing the subroutine. - P1 Holds the continuation for the caller, assuming this sub was called with callcc. Otherwise NULL. - P2 Holds the object the sub was called on. (For method calls) Or put another wa

Re: Method calling

I'm not sure if I'm asking a stupid question here, but: On Fri, May 30, 2003 at 08:12:34AM -0400, Dan Sugalski wrote: > We add three ops, findmeth, callmeth and callmethcc. (The latter just > automatically takes a continuation for the following op and stashes > it in P2, while the former assume

Re: Timers (was Threads and Progress Monitors)

"Dulcimer" <[EMAIL PROTECTED]> wrote > > But exposing the object like that still bothers be: I shouldn't need > > the $tmp, nor the .new. > > I'm not so sure I agree with losing the new(). I kinda like that just > for readability. Less isn't always more. :) > > Ok, how about this: > > sub slow_fn

RE: Method calling

Thanks Dan. One little picky thing what is the naming convention for ops? find_method (currently in core.ops), call_method, and call_method_cc (or callcc_method?) or findmeth, callmeth, and callmethcc (or callccmeth?) or findmethod, callmethod, and callmethodcc (or callccmeth

Re: Timers (was Threads and Progress Monitors)

> > sub slow_fn { > > my $pause = 1; > > my $timer is last { .stop } = new Timer secs => $pause++, > >reset => {$pause++}, > > code => {print "."}; > > return slow_fn_imp @_; > > } > > I'm think

RE: Method calling

At 9:20 AM -0700 5/30/03, Jonathan Sillito wrote: Dan, Why is there a callmeth op? Can't we just use a regular invoke as with other subs? Or does the callmeth op do both a find and invoke as an optimization? It does a find and invoke, and the callmethcc does a find, cc-capture, and invoke. I'm n

Re: [perl #22353] JIT!

Luke Palmer wrote: I'm running i686 (P3) Linux, gcc-3.2.2 It's that JIT_CGP thingy Thanks for your tests. It seems, I've to download and install the latest gcc, to get this fixed. In the meanwhile, we probably need some more compiler specific config stuff. leo

RE: Method calling

Dan, Why is there a callmeth op? Can't we just use a regular invoke as with other subs? Or does the callmeth op do both a find and invoke as an optimization? Jonathan Sillito > -Original Message- > From: Dan Sugalski [mailto:[EMAIL PROTECTED] > > Nope, not objects, but at least it's part

Timers (was Threads and Progress Monitors)

"Dulcimer" <[EMAIL PROTECTED]> wrote > so that the timer goes off after a second, prints a dot, and resets > itself to go off again after another second? And I still like the idea > of an expanding temporal window between dots: > > sub slow_fn { > my $pause = 1; > my $timer is last { .sto

Re: Threads and Progress Monitors

--- Dave Whipp <[EMAIL PROTECTED]> wrote: > Dulcimer wrote: > >>sub slow_fn { > >> my $tick = Timer.new(60, { print "..." }); > >> return slow_fn_imp @_; > >>} > >> > >>Now if I could just get the compiler to not complain about that > >>unused variable... > > > > > > Maybe I'm being dense...