Bill Coffman <[EMAIL PROTECTED]> wrote:
> Thanks for the info...
> Apparently,
>gcc -ansi -pedantic
> is supposed to be ANSI C '89.
Not really. It's pedantic ;)
> Incidentally, I tried adding -ansi and -pedantic and I got lots of
> warnings, like "long long" not supported by ANSI C'89, etc
Bill Coffman <[EMAIL PROTECTED]> wrote:
> Currently, here's how the register allocator is doing.
> Failed TestStat Wstat Total Fail Failed List of Failed
> ---
> t/library/dumper.t5 1280135 38.46%
I was getting a failure under JIT on PPC for t/pmc/threads_8.pasm, and
the problem turned out to be that emitting a restart op takes 26
instructions, or 104 bytes, and we were hitting the grow-the-arena
logic just shy of what would have triggered a resize, then running off
the end.
The below p
Recently config/gen/platform/darwin/asm.s was added, containing
Parrot_ppc_jit_restore_nonvolatile_registers(). Corresponding code also
needs to be added to config/gen/platform/aix/asm.s -- Parrot should
fail to link on AIX currently, without this. I didn't try to update the
AIX asm.s myself, s
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Bill Coffman <[EMAIL PROTECTED]> wrote:
>> t/library/dumper.t5 1280135 38.46% 1-2 5 8 13
> I didn't look too close, but it's probably only the entry points:
> .sub _dumper
> _global_dumper()
Fixed.
leo
Jeff Clites <[EMAIL PROTECTED]> wrote:
> I was getting a failure under JIT on PPC for t/pmc/threads_8.pasm, and
> the problem turned out to be that emitting a restart op takes 26
> instructions, or 104 bytes, and we were hitting the grow-the-arena
> logic just shy of what would have triggered a res
On my Mac OS X (Darwin), when I install a Perl module from CPAN, it is
installed in or under this directory:
/usr/local/lib/perl5/site_perl/5.8.4/
Recently I got hankerin' to look at the source code for Devel::Cover. I
would have expected to find it here:
/usr/local/lib/perl5/site_perl
# New Ticket Created by Bill Coffman
# Please include the string: [perl #32208]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32208 >
Patch does the following:
- Applied Matula/Chaitin/Briggs algorithm for register all
Paolo Molaro <[EMAIL PROTECTED]> wrote:
> On 10/27/04 Luke Palmer wrote:
>>
>> Ugh, yeah, but what does that buy you? In dynamic languages pure
>> derivational typechecking is very close to useless.
> Actually, if I were to write a perl runtime for parrot, mono or
> even the JVM I'd experiment wi
Matt Diephouse <[EMAIL PROTECTED]> wrote:
> #0 0x0003d420 in pobject_lives (interpreter=0xd00140, obj=0x0) at
> src/dod.c:198
> #1 0x48f0 in mark_1_seg (interpreter=0xd00140, cs=0xd01fd0) at
> src/packfile.c:360
Ah. The code assumed that there is always a valid subroutine name, which
might n
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> arm, mips, and sun4 JIT platforms need definitely some work to even keep
> up with the current state of the JIT interface.
That's actually wrong - sorry. Sun4 JIT is fairly complete and is up to
date and should't have been in above sentence.
I've mess
We now have since quite a time the current subroutine and the current
continuation in the interpreter context structure. With that at hand, we
should now be able to generate function tracebacks in error case and we
need the call chain too, to optimize register frame recycling.
Whenever a contin
Bill Coffman (via RT) wrote:
Patch does the following:
- Applied Matula/Chaitin/Briggs algorithm for register allocation.
- Color the graph all at once, and spill all symbols with high colors.
Spill all at once to speed things up.
Good. Hopefully Dan can provide some compile number compares.
- Sho
James E Keenan wrote:
On my Mac OS X (Darwin), when I install a Perl module from CPAN, it is
installed in or under this directory:
/usr/local/lib/perl5/site_perl/5.8.4/
Recently I got hankerin' to look at the source code for Devel::Cover. I
would have expected to find it here:
/usr/loc
When PIR code has a function call syntax:
foo(i, j)
the created code has currently (amongst other) a line:
newsub Px, .Sub, foo
where the label "foo" is a relative branch offset.
This is suboptimal for several reasons:
- it creates a new PMC for every call albeit in 99.99% of cases the PMC
con
On Thu, 28 Oct 2004 19:22:02 -0700, Bill Coffman <[EMAIL PROTECTED]> wrote:
> Thanks for the info...
>
> Apparently,
>
>gcc -ansi -pedantic
>
> is supposed to be ANSI C '89. Equiv to -std=c89. Also, my
> Configure.pl generated make file uses neither -ansi nor -pedantic. I
> do have access
At 12:30 PM +0200 10/29/04, Leopold Toetsch wrote:
Bill Coffman (via RT) wrote:
Patch does the following:
- Applied Matula/Chaitin/Briggs algorithm for register allocation.
- Color the graph all at once, and spill all symbols with high colors.
Spill all at once to speed things up.
Good. Hopefully
At 2:46 PM +0200 10/29/04, Leopold Toetsch wrote:
When PIR code has a function call syntax:
foo(i, j)
the created code has currently (amongst other) a line:
newsub Px, .Sub, foo
where the label "foo" is a relative branch offset.
This is suboptimal for several reasons:
[snip]
So I think, we shou
On Thu, Oct 28, 2004 at 09:51:06PM -0400, James E Keenan ([EMAIL PROTECTED]) wrote:
> Recently I got hankerin' to look at the source code for Devel::Cover. I
> would have expected to find it here:
>
> /usr/local/lib/perl5/site_perl/5.8.4/Devel/Cover.pm
perldoc -l Module::Name will give you
At 12:30 PM +0200 10/29/04, Leopold Toetsch wrote:
Bill Coffman (via RT) wrote:
Patch does the following:
- Applied Matula/Chaitin/Briggs algorithm for register allocation.
- Color the graph all at once, and spill all symbols with high colors.
Spill all at once to speed things up.
Good. Hopefully
On 10/29/04 Leopold Toetsch wrote:
> >> Ugh, yeah, but what does that buy you? In dynamic languages pure
> >> derivational typechecking is very close to useless.
>
> > Actually, if I were to write a perl runtime for parrot, mono or
> > even the JVM I'd experiment with the same pattern.
>
> For t
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>
>> get_sub Px, foo # find the PMC with label "foo" in constants
> Yeah, but I think I've a better approach. Instead of doing this,
> let's just get PMC constants implemented.
Well, they are implemented, at least partly. Sub PMCs are in the
constant t
classes/*.c is created by the bytecode compiler classes/pmc2c2.pl. Most
of the actual code is in lib/Parrot/Pmc2c.pm.
The created C code could need some improvements:
* the temp_base_vtable should be const.
This is currently not possible, because items like ".whoami" are
changed in the temp_ba
Paolo Molaro <[EMAIL PROTECTED]> wrote:
> On 10/29/04 Leopold Toetsch wrote:
>> Well, we already got a nice method cache, which makes lookup a
>> vtable-like operation, i.e. an array lookup. But that's runtime only
>> (and it needs invalidation still). So actually just the first method
>> lookup i
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) wrote:
> >
> >>Patch d
On Thu, Oct 28, 2004 at 09:51:06PM -0400, James E Keenan wrote:
> On my Mac OS X (Darwin), when I install a Perl module from CPAN, it is
> installed in or under this directory:
>
> /usr/local/lib/perl5/site_perl/5.8.4/
>
> Recently I got hankerin' to look at the source code for Devel::Cover.
At 4:36 PM +0200 10/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
get_sub Px, foo # find the PMC with label "foo" in constants
Yeah, but I think I've a better approach. Instead of doing this,
let's just get PMC constants implemented.
Well, they are implemented, at le
Hi all,
It was my understanding that Patrick Michaud was working on the Perl 6
grammar and after that was done, the work on the actual compiler would
commence. I've checked http://dev.perl.org/perl6/ and I don't see any
more information there. Is there some other source that I can
regularly chec
On Fri, Oct 29, 2004 at 11:03:04AM -0700, [EMAIL PROTECTED] wrote:
> It was my understanding that Patrick Michaud was working on the Perl 6
> grammar and after that was done, the work on the actual compiler would
> commence. I've checked http://dev.perl.org/perl6/ and I don't see any
> more inform
Dan Sugalski wrote:
At 4:36 PM +0200 10/29/04, Leopold Toetsch wrote:
Well, they are implemented, at least partly. Sub PMCs are in the
constant table. The funny C "opcode" is actually a ...
set_p_pc op.
... with the small difference, that at compile time, the integer
argument is a label (offset)
At 10:17 PM +0200 10/29/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 4:36 PM +0200 10/29/04, Leopold Toetsch wrote:
Well, they are implemented, at least partly. Sub PMCs are in the
constant table. The funny C "opcode" is actually a ...
set_p_pc op.
... with the small difference, that at com
On Fri, Oct 29, 2004 at 05:47:55PM +0200, Leopold Toetsch wrote:
> classes/*.c is created by the bytecode compiler classes/pmc2c2.pl. Most
> of the actual code is in lib/Parrot/Pmc2c.pm.
>
> The created C code could need some improvements:
Can I add a fourth - one I said to Dan I intended to do,
On Fri, 29 Oct 2004 01:05:18 -0700, Jeff Clites <[EMAIL PROTECTED]> wrote:
> Recently config/gen/platform/darwin/asm.s was added, containing
> Parrot_ppc_jit_restore_nonvolatile_registers(). Corresponding code also
> needs to be added to config/gen/platform/aix/asm.s -- Parrot should
> fail to link
[EMAIL PROTECTED] writes:
> Hi all,
>
> It was my understanding that Patrick Michaud was working on the Perl 6
> grammar and after that was done, the work on the actual compiler would
> commence.
Something like that. He's working on a grammar engine for parrot:
basically the regular expression
# New Ticket Created by Will Coleda
# Please include the string: [perl #32223]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32223 >
I think we should be building dynclasses by default.
oolong:~/research/parrot/config/
> [coke - Sat Jan 24 19:32:16 2004]:
>
> It would be helpful if IMCC complained about duplicate ".local" labels,
> so that the attached wouldn't compile, rather than dying at runtime.
>
A naive pass at this is:
oolong:~/research/parrot coke$ cvs diff imcc/symreg.c
Index: imcc/symreg.c
That is to say, the file and line number appear to be off.
Will Coleda via RT wrote:
Also, the errors message isn't reporting properly.
Help?
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:17 PM +0200 10/29/04, Leopold Toetsch wrote:
> >That leads again to my warnocked proposal to just toss all variants
> >of opcodes that have constants too. With all possible PMC constants
> >in the constants table, we get another (estimated) times two
I recently got my hands on money for an upgrade, and got an AMD64 and
motherboard and installed them. I'm still using 32-bit Windows, but
I've also installed a 64-bit Gentoo on some previously unpartitioned
space.
Initially, Parrot didn't build. Fortunately, the error message was
helpful[1]; I h
On Oct 29, 2004, at 11:29 PM, Brent 'Dax' Royal-Gordon wrote:
I recently got my hands on money for an upgrade, and got an AMD64 and
motherboard and installed them. I'm still using 32-bit Windows, but
I've also installed a 64-bit Gentoo on some previously unpartitioned
space.
...
Failed Test
40 matches
Mail list logo
