# New Ticket Created by Steve Peters
# Please include the string: [perl #21389]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21389 >
This patch is to stop warnings from being generated when compiling dod.c.
In the funct
# New Ticket Created by Steve Peters
# Please include the string: [perl #21388]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21388 >
The attached patch is to stop compilier warnings in jit.c. The local
variables i and t
# New Ticket Created by Steve Peters
# Please include the string: [perl #21387]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21387 >
This patch is to stop compilier warnings in embed.c. The loop label "again"
is only ca
# New Ticket Created by Steve Peters
# Please include the string: [perl #21386]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21386 >
This patch fixes compilier warnings generated when compiling interpreter.c.
In the fun
# New Ticket Created by Steve Peters
# Please include the string: [perl #21385]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21385 >
This patch eliminates compiler warnings generated when compiling packfile.c.
In the f
Benjamin Goldberg wrote:
African Grey, Brotogeris, Parakeet, Budgerigar, Budgie, Cockatiel,
Cockatoo, Conure, Eclectus, Kakapo, Lory, Lorikeet, Lovebird, Macaw,
Parrotlet, Pionus, Poicephalus, Quaker, Ringneck?
Since we don't have any of objects, exceptions, or a real IO system, I
would suggest "K
Jerome Quelin wrote:
>
> Steve Fink wrote:
> > I'm assuming this will be 0.0.10
>
> codename?
>
> > I could be persuaded to call it 0.1.0
>
> codename?
African Grey, Brotogeris, Parakeet, Budgerigar, Budgie, Cockatiel,
Cockatoo, Conure, Eclectus, Kakapo, Lory, Lorikeet, Lovebird, Macaw,
Parrot
Piers Cawley wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> writes:
>
> > Piers Cawley wrote:
> > [snip]
> >> Um... no. tail call optimization implies being able to replace *any*
> >> tail call, not just a recursive one with a simple goto.
> > [snip]
> >
> > In perl5, doing a tail call optimi
Jerome Quelin wrote:
Steve Fink wrote:
I'm assuming this will be 0.0.10
codename?
I could be persuaded to call it 0.1.0
codename?
Jerome
while trolling for things parrot, I came upon this;
http://www.kingsnicknames.co.uk/
Towards the bottom of this paragraph is the HIT, from
Phil Hassey wrote:
... The current bytecode from parrot already has potential
for slowing things down, and that's what worries me here.
I don't see that.
My understanding is that PBC has a limit of 16 (32?) integer registers. When
a code block needs more than 16 registers, they are overflowed i
# New Ticket Created by logo
# Please include the string: [perl #21378]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21378 >
I was trying to install the latest version of libwww-perl with my 5.8.0
installation of perl.
> > Although it might be nice if IMC were binary at this stage (for some
> > feel-good-reason?).
>
> You mean, that a HL like perl6 should produce a binary equivalent to
> ther current .imc file? Yep - this was discussed already, albeit there
> was no discussion, how this should look like. And the
Angel Faus wrote:
(1) First, do a register allocation for machine registers, assuming
that there are N machine registers and infinite parrot registers.
This uses equally the top N used registers for processor regs. The
"spilling" for (1) is loading/moving them to parrot registers/temp
registe
At 12:41 PM -0500 2/26/03, Jason Gloudon wrote:
On Wed, Feb 26, 2003 at 09:31:39AM -0800, Sean O'Rourke wrote:
Dan -- you might be interested in
http://www.usenix.org/events/javavm02/chen_m.html (if you have a USENIX
Research wants to be free:
http://www-hydra.stanford.edu/publications/JVM02.pd
Phil Hassey wrote:
[snip]
Although it might be nice if IMC were binary at this stage (for some
feel-good-reason?).
You mean, that a HL like perl6 should produce a binary equivalent to
ther current .imc file? Yep - this was discussed already, albeit there
was no discussion, how this shoul
> [ you seem to be living some hors ahead in time ]
Yep, sorry about that.
> The problem stays the same: spilling processors to parrot's or
> parrots to array.
>
Thinking a bit more about it, now I believe that the best way to do it
would be:
(1) First, do a register allocation for machine re
Okay, here's the plan for the string rework.
All the string functions we have now should keep their names and
signatures. They do reasonable things, and that's just fine. What we
need is shadow functions that do the same thing, only get passed in
the destination string. Or, rather, we need to r
On Wed, Feb 26, 2003 at 09:31:39AM -0800, Sean O'Rourke wrote:
> Dan -- you might be interested in
> http://www.usenix.org/events/javavm02/chen_m.html (if you have a USENIX
Research wants to be free:
http://www-hydra.stanford.edu/publications/JVM02.pdf
--
Jason
First off, thanks to our relentless..., er, tireless summarizer for
continuing to digest and clarify our wandering discussion.
On Tue, 25 Feb 2003, Piers Cawley wrote:
> Using IMCC as JIT optimizer
> Apparently, Leo Tötsch finds it unbearable that 'optimized compiled C is
> still faster
Steve Fink wrote:
> I'm assuming this will be 0.0.10
codename?
> I could be persuaded to call it 0.1.0
codename?
Jerome
--
[EMAIL PROTECTED]
[snip]
> > Maybe we starting to get to the point of having imcc deliver parrot
> > bytecode if you want to be portable, and something approaching native
> > machine code if you want speed.
>
> IMHO yes, the normal options produce a plain PBC file, more or less
> optimized at PASM level, the -Oj op
Nicholas Clark wrote:
Well, I think that proper IO would be useful. But I don't think it affects
the innards of the execution system greatly >
No, though we will need some more ops - or not. Current io also defines
a more or less dummy io PMC (e.g. io.ops:open). This could be a full
PMC, with
As Leon pointed out in another thread, we're overdue for another
release. I'd like to have a feature freeze on March 8, leading to a
release within a week after.
Any objections?
Side note: I'll be gone Feb 26 - Mar 4.
I'm assuming this will be 0.0.10, but if anyone sneaks in a complete
implement
As Leon pointed out in another thread, we're overdue for another
release. I'd like to have a feature freeze on March 8, leading to a
release within a week after.
Any objections?
Side note: I'll be gone Feb 26 - Mar 4.
I'm assuming this will be 0.0.10, but if anyone sneaks in a complete
implement
On Feb-22, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >In my local copy (currently locked away on my home hard drive, so I
> >can't post it from here at work), I also added stabs entries for all
> >the PMC registers (in addition to the current S, I, and N registers.)
> >You can see the PMC's d
On Feb-25, Leon Brocard wrote:
> David sent the following bits through the ether:
>
> > Thanks. I better upgrade my version, I'm not seeing it in 0.0.9.
>
> It's been a while since 0.0.9 (errr, 20th Dec). A lot has changed
> since then. Maybe it's time for a 0.1.0 release. What are we waiting
> f
On Tue, Feb 25, 2003 at 11:58:41PM +0100, Leopold Toetsch wrote:
> Nicholas Clark wrote:
[thanks for the explanation]
> > And is this all premature optimisation, give that we haven't got objects,
> > exceptions, IO or a Z-code interpreter yet?
> And yes: We don't have exceptions and threads yet.
27 matches
Mail list logo
