hello people,
I've implemented some print opcodes in JIT (for i386), but I would
like to know your opinion about these before submitting a patch.
in reality, there isn't a big performance boost, because I'm just
calling printf as the C opcode does. it just saves some
push/pop/call/ret
On Tue, 21 May 2002 12:18:50 -0400, Dan Sugalski wrote:
At 8:44 AM -0500 5/20/02, brian wheeler wrote:
I've been trying to catch up with parrot again (darn it, babies take more
time than I thought :) and I've come up with a question... how do you do
other things to PMCs that aren't normal
On Wed, 22 May 2002, Sean O'Rourke wrote:
This is an implementation of LZW compression in Parrot assembly. The fact
that pack() can't handle null bytes makes it a bit more complicated (and
limited) than it has to be, but for just text files, it seems to work just
fine. It's probably a
[re-cc'd p6i due to mailer failure on my part]
At 10:17 PM 5/22/2002 +, via RT wrote:
Clinton A. Pierce wrote:
* sync up, and get the latest Parrot BASIC. It's fully hash-enabled and
quite speedy now.
* Run basic.pl to assemble the interpreter, and get it started
* At the
On Thu, 23 May 2002, Aldo Calpini wrote:
hello people,
I've implemented some print opcodes in JIT (for i386), but I would
like to know your opinion about these before submitting a patch.
in reality, there isn't a big performance boost, because I'm just
calling printf as the C opcode
On Thu, 23 May 2002, Daniel Grunblatt wrote:
On Wed, 22 May 2002, Sean O'Rourke wrote:
that pack() can't handle null bytes makes it a bit more complicated (and
Exactly how do you want it to handle null bytes?
Nevermind -- sorry 'bout that. There's a little wierdness in there, but
it isn't
Let's try patch that compiles...
/s
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.143
diff -u -p -r1.143 core.ops
--- core.ops20 May 2002 17:52:28 - 1.143
+++ core.ops23 May 2002 15:03:31 -
-1957,11 +1957,17 inline op pack(inout STR, in INT, in STR
At 9:39 AM -0400 5/23/02, Clinton A. Pierce wrote:
[re-cc'd p6i due to mailer failure on my part]
At 10:17 PM 5/22/2002 +, via RT wrote:
Clinton A. Pierce wrote:
* sync up, and get the latest Parrot BASIC. It's fully hash-enabled and
quite speedy now.
* Run basic.pl to assemble the
Hi Folks!
I've attached a small pasm file that crashes Parrot. Seems to be a GC issue,
it workes fine if sweepoff is added.
Might be useful for debugging?
cya,
Jens Rieks
#
# small example that crashes parrot
#
set I1, 1
main: bsr print
inc I1
le I1, 100, main
At 8:00 PM +0200 5/23/02, Jens Rieks wrote:
I've attached a small pasm file that crashes Parrot. Seems to be a GC issue,
it workes fine if sweepoff is added.
The GC assumes that the stack entries are always valid, and you
pushed invalid strings onto the stack. (The string register was NULL
I've added a file RESPONSIBLE_PARTIES to the repository listing the
folks who I remembered as having both CVS commit access and
responsibility for a particular piece of Parrot. (If you've just got
plain commit access you're not on there, which is arguably a Good
Thing--all the power with none
I prefer it to work like this:
set S0,
set IO,42
pack S0, 4, I0 ,0
length I1, S0 # is 4
pack S0, 4, I0
length I1, S0 # is 8
pack S0, 4, I0, 1 # no segv :)
length I1, S0 # is 10004
Patch is already applied.
Daniel Grunblatt.
On Thu, 23 May 2002, Sean O'Rourke
Theoretically this shouldn't be done,
In practice you can't assume something like that (at least when using
callee-save calling convention), or do I miss the point?
but I put in a patch to the GC to double check, just in case.
Fine, tanks :)
cya,
Jens Rieks
At 8:55 PM +0200 5/23/02, Jens Rieks wrote:
Theoretically this shouldn't be done,
In practice you can't assume something like that (at least when using
callee-save calling convention), or do I miss the point?
Nope, you didn't miss the point. The GC assumes that the register
frames might be
At 1:23 PM +0100 5/23/02, Peter Haworth wrote:
On Tue, 21 May 2002 12:18:50 -0400, Dan Sugalski wrote:
At 8:44 AM -0500 5/20/02, brian wheeler wrote:
I've been trying to catch up with parrot again (darn it, babies take more
time than I thought :) and I've come up with a question... how do
At 7:01 PM -0700 5/22/02, Sean O'Rourke wrote:
I took a look at what was going on, and found that the GC probably needs a
good tuning. For the 20K file, parrot is doing 217 collections of the
string pool, the last 102 of which reclaim less than 10% of the pool.
Changing compact_string_pool() to
The hashtable currently has correctness and efficiency problems
resulting from string encodings (and their interaction with garbage
collection).
Correctness example:
Currently, string hash values are computed by going straight to the
actual data and running a fairly typical hashing algorithm.
Sean O'Rourke wrote:
I took a look at what was going on, and found that the GC probably needs
a
good tuning. For the 20K file, parrot is doing 217 collections of the
string pool, the last 102 of which reclaim less than 10% of the pool.
Changing compact_string_pool() to increase the pool size
# New Ticket Created by Tony Payne
# Please include the string: [netlabs #617]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=617
Fixed some minor bugs w/ the Optimizer, having to do mainly with
handling of
Steve Fink wrote:
lots of interesting stuff about hashes etc.
Reading this made me wonder if we should consider cached string
transcodings,
if we don't end up storing strings in a single form internally. The worst
case is
probably string constants, which could be transcoded over and over again
On Fri, 24 May 2002, Peter Gibbs wrote:
My current work is based on counting the size of freed buffers - yes,
this adds some overhead in free_unused_buffers, but it seems like it
may be worth it - and only doing compaction runs when a predefined
fraction of the pool size is available for
21 matches
Mail list logo
