At 10:51 AM -0800 1/3/03, James Michael DuPont wrote:
Can someone tell me if anyone uses packdump from cvs? is that an
equivalent to ildasm in dotnet? It seems to be broken.
Can I dump an set of instructions from a program into a file, and
reassemble them?
If not, is there a way to dump a parrot
At 10:25 PM +0100 1/3/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
I'm not willing to go so radically to start, but I did have an
idea. I think part of the extra cost is just in cache
fluffiness--the sync info just isn't being used much. I don't think
that it, or the property info, will be
At 10:08 PM +0100 1/3/03, Leopold Toetsch wrote:
Ok. Here ist the rest.
- No stackwalk, as already sent by separate #19668, which is included
if this is a problem for $architecture, please enable
trace_system_areas in dod.c again - feedback still welcome
I think we're always going to have
At 9:35 PM -0500 1/3/03, Mitchell N Charity wrote:
I'm not willing to go so radically to start, but I did have an idea.
I think part of the extra cost is just in cache fluffiness--the sync
info just isn't being used much. I don't think that it, or the
property info, will be used most
Damian Conway wrote:
Piers Cawley wrote:
Acknowledgements
But, of course, modesty forebade him from thanking the tireless Perl 6
summarizer himself, for his sterling efforts wading through the morasses
that are P6-language and P6-internals
Remembering e.g. perl6 operator threads, brrr, I
Dan Sugalski wrote:
At 10:25 PM +0100 1/3/03, Leopold Toetsch wrote:
As programs tend to have much more scalars then aggregates and
probably more scalars w/o properties then with, this would win a lot
of precious cache mem.
Fair enough, though there's something just so bizarre about
Dan Sugalski wrote:
At 10:08 PM +0100 1/3/03, Leopold Toetsch wrote:
- No stackwalk,
I think we're always going to have to walk the stack, no matter how much
I'd rather not. It's an expensive walk too, alas.
This depends on. I think a mixed strategy of:
- code reordering (e.g.
Leopold Toetsch wrote:
Leopold Toetsch wrote:
$ time parrot -j stress.pbc
A total of 9 DOD runs were made
real0m0.708s
But this still could go faster:
$ parrot -j stress.pbc # w/o pmc-synchronize (-10% size)
A total of 9 DOD runs were made
real0m0.635s
$ time parrot -j stress.pbc
- {active,total}_{PMC,BUFFER}S are calculated now on demand and
therefore always valid, not only after a DOD run (active)
- these vars are no more in the interpreter struct
- removed duplicate printing of interpinfo
Accessing info from these interpreter stat fields shall be done only via
the
On Sat, 2003-01-04 at 04:05, Dan Sugalski wrote:
At 7:27 PM +0100 1/3/03, Erik Bågfors wrote:
On Sat, 2003-01-04 at 00:28, Gopal V wrote:
If memory serves me right, Dan Sugalski wrote:
language-level we're object-oriented dammit! objects, not the
lower-level stuff we're currently
If memory serves me right, Erik Bågfors wrote:
would a be able to modify itself ? (unfortunately C# allows that)
To clarify here's my example ...
=cut
using System;
public struct MyStruct
{
int val;
public MyStruct(int x){ val=x; }
public void Modify(){ val=42; }
Steve Fink wrote:
I was assuming the generation would be automatically incremented per
op, either in the runops loop or (if that is too slow) in the
implementation of selected ops.
In the runops loop would be slow, and not very practical for e.g. JIT or
CGoto. But e.g. branch instructions
FYI
--- Forwarded Message
Date:05 Jan 2003 00:41:55 +
From:Josh Wilmes [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: parrot/tools/dev rebuild_miniparrot.pl
cvsuser 03/01/04 16:41:54
Modified:config/auto jit.pl sizes.pl
On Jan-04, Gopal V wrote:
So, workarounds are possible .. and neither the host nor the compiler
is there yet ;) ...
Good point -- we'd better speed up on this Parrot stuff, so we can
push more of the really hard things onto you compiler guys. ;)
Steve Fink wrote:
It's late here, but I'll try an answer ;-)
... I was thinking that it might be okay
to say that any single operation (even those that could conceivably
trigger many other operations) must fit all of its allocations within
the total amount of available memory when it starts.
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #19729]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19729
This patch adds JIT support for restart and similar ops.
--
Jason
--
16 matches
Mail list logo
