On Wednesday 03 March 2004 19:50, Leopold Toetsch wrote:
Daniel Grunblatt [EMAIL PROTECTED] wrote:
When updating the old version I had at the TD machine to the current cvs
version I realize that it fails right after start running, entering in an
eternal loop, I could not find out exactly
When updating the old version I had at the TD machine to the current cvs
version I realize that it fails right after start running, entering in an
eternal loop, I could not find out exactly what is the problem but I think
it's related to threads.
It's Debian 3.0 on parisc using gcc 3.0.4
Any
I can point you to the docs:
docs/jit.pod
There should be an explanation of how it works.
Daniel.
On Wednesday 08 October 2003 13:16, Clemens Eisserer wrote:
Hi there!
I´m currently interrested a bit in howto write a just in time compilier
(jit). I searched a long time using google,
On Wednesday 10 September 2003 01:52, Luke Palmer wrote:
Okay, after some major changes, here's the second revision of my patch.
This one is fully functional.
On my system, it creates over a 10x speedup for lazy DOD runs!
Yay!
(I'll post the benchmark program if someone wants; it's pretty
On Friday 05 September 2003 12:34, Steve Fink wrote:
Nicholas Clark wrote:
On Tue, Sep 02, 2003 at 06:39:23AM +0300, Vladimir Lipskiy wrote:
D. Function parametres in declarations.
At the monent, pdd7 says that we mustn't omit them in declarations.
I propose to omit them. The advantage is:
On Thursday 21 August 2003 11:23, Tanton Gibbs wrote:
I just wanted to let the list know that with the following configure
options
--cgoto=0 --jitcapable=0 --execcapable=0
Just to let you know --jitcapable=0 implies --execcapable=0.
I had 100% pass rate on all cygwin tests.
Cool.
Tanton
On Thursday 14 August 2003 18:24, Mattia Barbon wrote:
Puts #ifdefs as per the rest of i386/jit_emit.h.
Regards
Mattia
Applied, Thanks.
Daniel.
If you want to compile your .pbc to $(EXE) but you don't want
blib/lib/libparrot.a included in each one, you can do it by linking the
generated .o with blib/lib/libparrot.so (you can try make exec_so
EXEC=program_name but I'm unsure if it will work correctly)
In order to have this working you
Now Exec works exactly like the jit, I have checked in the missing restart,
fixed some bugs at Parrot_jit_store_retval and make exec_start call runops
instead of calling run_compiled directly, so now all test are successful.
Have fun.
Daniel.
On Wednesday 13 August 2003 05:07, Leopold Toetsch wrote:
I started extending the packfile functions towards multiple code
segments. First is still some cleanup, but I already have troubles with
the EXEC stuff :-(
I could not reproduce the error here.
The debugger doesn't really like this
On Wednesday 13 August 2003 12:28, Daniel Grunblatt wrote:
On Wednesday 13 August 2003 05:07, Leopold Toetsch wrote:
I started extending the packfile functions towards multiple code
segments. First is still some cleanup, but I already have troubles with
the EXEC stuff :-(
I could
Now EXEC works for ARM (linux) too.
I've checked in what I did last year to make the JIT work on MIPS, it's not
finished but IMHO it's a good start, so if anyone wants to continue or gimme
an account in one (which I don't have anymore) I would be glad.
Daniel.
On Friday 08 August 2003 14:16, Nicholas Clark wrote:
On Fri, Aug 08, 2003 at 01:48:17PM -0300, Daniel Grunblatt wrote:
Now Exec works exactly like the jit, I have checked in the missing
restart, fixed some bugs at Parrot_jit_store_retval and make exec_start
call runops instead of calling
On Monday 04 August 2003 14:03, Dan Sugalski wrote:
Here's some stuff we need to add to the packfile format and the sub
header to get things ready for more language work.
Packfiles need to have a symbol table. A series of name/type/location
tuples so we can have global names that map to
On Sunday 03 August 2003 15:27, Simon Glover wrote:
On 3 Aug 2003, Luke Palmer wrote:
This fix has worked fine with JIT until now, so I suspect the problem
is elsewhere.
Bug confirmed here (although I need a slightly longer string to trigger
it). Here's a stacktrace:
I couldn't
On Thursday 31 July 2003 14:31, Brent Dax wrote:
Daniel Grunblatt:
+PIO_eprintf(interpreter, Parrot VM: Platform JIT_ARCHNAME
+ is not EXEC-capable.\n);
An unprefixed constant like JIT_ARCHNAME should not be available to
embedders. If it is, something's wrong
I have checked in a patch to make the following work:
./parrot -o life.o examples/assembly/life.pbc
So, don't use test_main anymore.
I made this storing the pointer to the -o argument in the interpreter string
register 0 to make it visible from inside the core, instead of adding another
On Tuesday 29 July 2003 21:10, chromatic wrote:
On Tuesday, July 29, 2003, at 02:41 PM, Simon Glover wrote:
Therefore the decision was taken that we should not guarantee that
Parrot
should never segfault when fed bad assembler; the creation of invalid
assembler is a compiler bug, and
On Monday 28 July 2003 20:46, Tim Howell wrote:
?tches from a few days ago to allow executable creation, the current CVS no
longer compiles properly on my MacOS X 10.2.6 box. The error I get is:
exec_save.c:319:16: #if with no expression
make: *** [exec_save.o] Error 1
The following patch
On Monday 28 July 2003 20:53, Simon Glover wrote:
On Mon, 28 Jul 2003, Tim Howell wrote:
?tches from a few days ago to allow executable creation, the current CVS
no longer compiles properly on my MacOS X 10.2.6 box. The error I get
is:
exec_save.c:319:16: #if with no expression
make:
On Thursday 24 July 2003 22:02, Arcady Goldmints wrote:
# New Ticket Created by Arcady Goldmints
# Please include the string: [perl #23115]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23115
Contrary to popular
On Thursday 24 July 2003 22:02, Arcady Goldmints wrote:
# New Ticket Created by Arcady Goldmints
# Please include the string: [perl #23115]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23115
Contrary to popular
Yes, it's already fixed, thanks.
On Friday 25 July 2003 17:55, Garrett Rooney wrote:
Daniel Grunblatt wrote:
+# endif
+# if EXEC_OS == DARWIN
+# define EXEC_MACH_O
+# endif
+# if (EXEC_OS == FREENBSD) || (EXEC_OS == LINUX)
# define EXEC_ELF
# endif
.
Daniel Grunblatt.
On Thursday 24 July 2003 15:14, Simon Glover wrote:
On Thu, 24 Jul 2003, Daniel Grunblatt wrote:
I have checked in a first attempt to make parrot generate an executable.
It works fine on x86 - OpenBSD/linux/FreeBSD and should also work on
NetBSD
It's not working for me on Linux/x86
On Thursday 24 July 2003 15:48, Juergen Boemmels wrote:
Daniel Grunblatt [EMAIL PROTECTED] writes:
I have checked in a first attempt to make parrot generate an executable.
This is very cool.
Thanks.
It works fine on x86 - OpenBSD/linux/FreeBSD and should also work on
NetBSD
On Thursday 24 July 2003 15:55, Juergen Boemmels wrote:
Magic: 7f 45 4c 46 01 01 01
00
--
00 00 00 00 00 00 00 00
OS/ABI:UNIX - System V
Patch is in, please resync and try it.
boe
Daniel
On Thursday 24 July 2003 16:13, Simon Glover wrote:
On Thu, 24 Jul 2003, Daniel Grunblatt wrote:
On Thursday 24 July 2003 15:55, Juergen Boemmels wrote:
Magic: 7f 45 4c 46 01 01 01
00
--
00 00 00 00 00 00 00 00
OS/ABI:UNIX - System V
Patch
Back in.
On Tuesday 08 July 2003 11:32, Sean O'Rourke wrote:
On 7 Jul 2003, Daniel Grunblatt wrote:
cvsuser 03/07/07 13:20:40
Modified:jit/ppc jit_emit.h
Log:
* 2 instructions instead of 3 to load a 32 bit integer.
I'm not sure this is a win, since loading small
On Thursday 20 February 2003 18:14, Leopold Toetsch wrote:
Tupshin Harper wrote:
Leopold Toetsch wrote:
Starting from the unbearable fact, that optimized compiled C is still
faster then parrot -j (in primes.pasm)
Lol...what are you going to do when somebody comes along with the
on x86.
Someone care to check it out and poke around a bit?
CG vs JIT (running with non jitted opcdes) wins CG, always.
Daniel Grunblatt.
Applied, thanks.
Daniel Grunblatt.
On Sunday 05 January 2003 01:10, Jason Gloudon (via RT) wrote:
# 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
On Monday 30 December 2002 21:30, Leopold Toetsch wrote:
Jerome Quelin (via RT) wrote:
# New Ticket Created by Jerome Quelin
# Please include the string: [perl #19610]
# in the subject line of all future correspondence about this issue.
# URL:
, if you don't mind I want to remove
ALLOCATE_REGISTERS_ALWAYS.
Daniel Grunblatt.
On Sunday 01 December 2002 18:04, Leopold Toetsch wrote:
Daniel Grunblatt wrote:
The problem is that we do want to allocate a hardware register for a
Parrot register that is used only once in the section since the section
can be executed more than once, if you don't mind I want to remove
anomalies like i386 shift ops.
I don't really know if we should spent too much time on this instead of
creating an intermediate language to write opcodes on it.
Daniel Grunblatt.
some time to finish it
on december).
Daniel Grunblatt.
On Tuesday 19 November 2002 10:04, Leopold Toetsch wrote:
Currently all architecures have there own core.jit. These are very
similar, e.g. checking for MAPped registers, but differ depending on
the processor architecure: basically we have
On Tuesday 19 November 2002 11:54, Leopold Toetsch wrote:
Daniel Grunblatt wrote:
The problem is when you want to implement an opcode like div, which is
easy in ppc but not in arm ideas?
I don't know arm, but this belongs to jit_emit.h, how it's done there is
a different issue.
what
On Thursday 14 November 2002 10:32, Leopold Toetsch wrote:
Daniel Grunblatt wrote:
On Thursday 14 November 2002 05:14, Leopold Toetsch wrote:
What JIT needs to know is the location of the resume opcode, to mark it
as a jump target properly, so that processor registers can be setup
correctly
On Wednesday 13 November 2002 08:06, Leopold Toetsch wrote:
I could localize a long outstanding bug in JIT causing 4 perl6 tests to
fail.
When an opcode was a branch target as well as a branch source, the
branch target got lost, causing wrong basic blocks, implying missing
register loads ...
You will see it running as fast as mops.c compiled with -O3 if you change
REDO: sub I4, I4, I3
for
REDO: dec I4
But that's obviously part of a higher level optimizer.
On Wednesday 13 November 2002 15:10, Leopold Toetsch wrote:
Watch the mops ;-)
leo
bad input
- allow passing command-line arguments to the program
- allow printing indexed aggregates indexed by integers (eg 'p P0[0]')
(other key types need implementing)
- makes pdb exit on EOF (ctrl-d on unix)
- removed some code duplication, other cleanups
CC'ing this to Daniel Grunblatt
platforms.
Thanks,
Mike Lambert
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/35605/28863/5e145e/fixup.diff
Applied, thanks.
Daniel Grunblatt.
On Mon, 26 Aug 2002, Andy Dougherty wrote:
Currently, a fresh checkout of the cvs tree contains 2215 files, but only
497 of them are listed in MANIFEST. Most are the icu/ files, but there
are scattered others as well. I'm unsure if all of them are supposed
to be in MANIFEST yet (e.g. is
I just added condition breakpoints and watchpoints, now you can do:
(pdb) b 4 if S14 = parrot
See docs/debugger.pod for details.
Is it worst to allow something like this?:
if (((S14 == I0) (I4 = N3) (N3 4.5 N7)) || (I5 == 32))
Daniel Grunblatt.
if parrot would now
support an assembler that was implemented in Parrot. Then we'd know
that the assembler was at least as portable as parrot itself...
Something like languages/parrot_compiler/ but working, right?
Daniel Grunblatt.
On Tue, 13 Aug 2002, John Porter wrote:
Piers Cawley wrote:
I'd also like to be able to generate parrot code from within parrot
and immediately execute it...
Something like that will be needed for eval() anyway, right?
Yes, like PDB_eval() may be...
Daniel Grunblatt.
) and tell me if this should be sent as a patch.
Applied, thanks.
Daniel Grunblatt.
On 12 Aug 2002, Jason Greene wrote:
One more safety check (fixes another crash bug). Hopefully this is the
last patch patch.
Applied, thanks.
Daniel Grunblatt.
to assemble anything.
Probably I should have gone the other way and fix it.
Daniel Grunblatt.
a prototype. The regex engine? The
GC? ...
The assembler is a bit outdated, it shouldn't be too difficult to bring it
up to date, I just don't have enough time latetly. But it did work fine
and is easy to extend it. Why do you think it should be thrown away?
Daniel Grunblatt.
On 12 Aug 2002, Simon Cozens wrote:
[EMAIL PROTECTED] (Daniel Grunblatt) writes:
I moved it back to pure-Perl because there were something like half of the
tinderboxes failing to assemble anything.
Ah, right. Yeah, the tinderboxes are good slaves but really bad masters.
True, but I
On 12 Aug 2002, Simon Cozens wrote:
[EMAIL PROTECTED] (Daniel Grunblatt) writes:
The assembler is a bit outdated, it shouldn't be too difficult to bring it
up to date, I just don't have enough time latetly. But it did work fine
and is easy to extend it. Why do you think it should
On 12 Aug 2002, Simon Cozens wrote:
[EMAIL PROTECTED] (Daniel Grunblatt) writes:
Oh, no, I was talking about languages/parrot_compiler/. Sorry.
Oh, I hadn't seen that. I can't work out what it is; it seems to be a
device for generating Couldn't find operator errors. Is there any,
dare I
?)
If so, imcc has already done some work about where slightly more JIT effort
might pay off, so it seems a shame to throw that out.
Yes, that's why we are not going to do any kind of optimization that is
not required to be done at runtime, that means, we expect the most optimal
bytecode.
Daniel
OK, now we have the JIT working on PPC.
More opcodes coming.
It's not currently using a constant pool but it should.
Thanks to Sean for the sync cache code and helping me.
Daniel Grunblatt.
on the register allocator too.
Daniel Grunblatt.
set tell that it combines
the elegance of the IA32 CISCy instruction set with
the elegance of the HPPA RISCy instruction set... :-)
I intend to do nothing on these except raise gui^H^H^Hawareness :-)
Or give me an acount? ;)
Daniel Grunblatt.
Yes, we can do that, we can also try to go in and out from the computed
goto core if available.
Daniel Grunblatt.
On Tue, 30 Jul 2002, Dan Sugalski wrote:
At 10:34 PM -0300 7/29/02, Daniel Grunblatt wrote:
On Mon, 29 Jul 2002, Nicholas Clark wrote:
As you can see from the patch all
well and I'm sure Dan will get his slides up
soon. BTW anyone want to work on getting Parrot to use less memory so
it can run on palmtops? ;-)
I'm told it will take much more than just reducing the memory it uses.
Daniel Grunblatt.
Leon
--
Leon Brocard.http
unoptimized, doesn't compare too bad
to perl5
- mops is a silly test ;-)
You didn't use -O3 while compiling mops.c, did you?
Daniel Grunblatt.
On Mon, 29 Jul 2002, Nicholas Clark wrote:
Here's a very minimal ARM jit framework. It does work (at least as far as
passing all 10 t/op/basic.t subtests, and running mops.pbc)
Cool, I have also been playing with ARM but your approach is in better
shape. (I'll send you a copy of what I got
I thing I forgot to tell is that I also have added a constant pool which
could be usefull for the ARM too, it's on my local tree,I don't know
exactly when I'm going to finish it.
Daniel Grunblatt.
Applied, thanks.
Daniel Grunblatt.
On Tue, 23 Jul 2002, Andy Dougherty wrote:
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #15401]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15401
Applied, thanks.
Daniel Grunblatt.
On Mon, 22 Jul 2002, Aldo Calpini wrote:
# New Ticket Created by Aldo Calpini
# Please include the string: [perl #15335]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15335
On Wed, 17 Jul 2002, Andy Dougherty wrote:
The following patch brings the MANIFEST file up-to-date with recent
additions. I haven't committed this in case some other reorganization
(e.g. moving stuff to a src/ or dev/ or doc/ directory) is underway.
There are also a few minor shuffles as
We have one vote for docs/dev.
Daniel Grunblatt.
On Wed, 17 Jul 2002, Melvin Smith wrote:
At 06:14 PM 7/16/2002 -0700, John Porter wrote:
Melvin Smith wrote:
I put it temporarily in the root dir, which I know is wrong.
Where should .dev files go, anyway?
Actually, I think that's
Applied.
Daniel Grunblatt.
On Wed, 17 Jul 2002, Sean O'Rourke wrote:
# New Ticket Created by Sean O'Rourke
# Please include the string: [perl #15009]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=15009
The assembler doesn't use the XS stuff anymore, just committed a patch
build from Jeff's code.
Let's hope to see some more tinderboxes green.
Daniel Grunblatt.
I just changed 'kc' to be an integer constant, because it was the
simpliest way to make the warnings go away.
If kc should be a string and k too, tell me.
Daniel Grunblatt.
of the interpreter anywhere, and either way you will
need to dereference it, and that's slower, leaves us with 1 less cpu
register for the register allocation and requires a total redesing(what is
of course the less important thing).
Daniel Grunblatt.
On Fri, 21 Jun 2002, Jerome Vouillon wrote:
On Thu, Jun 20, 2002 at 12:26:11AM -0400, Melvin Smith wrote:
Given that it seems capturing and restoring a context is the most
expensive part, should we make default routines lightweight (execute
on caller stack rather than getting their own)
It would be cute if you change the debugger to load all the included files
as well.
Daniel Grunblatt.
On 21 Jun 2002, brian wheeler wrote:
I've implemented a .include directive for the new assembler. It
basically changes the preprocessor to shift through the source file, and
when
Err, Jeff just told me to see the -E flag.
Daniel Grunblatt.
On Sat, 22 Jun 2002, Daniel Grunblatt wrote:
It would be cute if you change the debugger to load all the included files
as well.
Daniel Grunblatt.
On 21 Jun 2002, brian wheeler wrote:
I've implemented a .include directive
. The response to my report was that This'll be
fixed when we've got the Parrot IO support rolled out. Have you any idea
how far down the line that's going to be?
No, I got no idea, but the problem wasn't in the Parrot IO but in the
assembler.
Daniel Grunblatt.
warnings I couldn't understand why, thank you.
Daniel Grunblatt.
On 29 May 2002, Mike Lambert wrote:
# New Ticket Created by Mike Lambert
# Please include the string: [netlabs #634]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=634
Peter recently submitted a patch to RT
suggested, as well as documenting them (slightly). It also
adjusts the tests accordingly. All tests still pass.
Simon
Applied, thanks.
(with a perl -p -i -e 's/[gs]et_keyed/set/' *.t first)
Daniel Grunblatt.
On 1 Jun 2002, Simon Glover wrote:
# New Ticket Created by Simon Glover
# Please include the string: [netlabs #650]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=650
A few small fixes to the assembler
On 27 May 2002, Peter Gibbs wrote:
# New Ticket Created by Peter Gibbs
# Please include the string: [netlabs #628]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=628
Following patch adds dependencies entry
Now I attached all the files :)
I also added now the target disassemble, it will emit on stdout the
disassemble of a pbc, this output is (should be) ready to assemble.
(it might have some issues with strings).
Daniel Grunblatt.
On 27 May 2002, Daniel Grunblatt wrote:
# New Ticket Created
On Wed, 29 May 2002, Mike Lambert wrote:
Hey all,
After finding out that life.pasm only does maybe 1KB per collection, and
Sean reminding me that there's more to GC than life, I decided to create
some pasm files testing specific behaviors.
Attached is what I've been using to test and
On 26 May 2002, Mike Lambert wrote:
# New Ticket Created by Mike Lambert
# Please include the string: [netlabs #626]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=626
Looksd like the logic for keeping track
{
Regards,
Daniel Grunblatt.
On Fri, 24 May 2002, Peter Gibbs wrote:
I managed to send the wrong version of the patch on the previous post!
Herewith the correct (I hope) one.
Apologies to all.
--
Peter Gibbs
EmKel Systems
Applied, thanks.
The patch made it to the RT what is enough.
Daniel Grunblatt.
On 24 May 2002, Tony Payne wrote:
Hmm.. patch didn't make it.
On Fri, 2002-05-24 at 08:51, Tony Payne wrote:
# New Ticket Created by Tony Payne
# Please include the string: [netlabs #620]
# in the subject line of all
a decent stress test for the hash PMC, but especially
Exactly how do you want it to handle null bytes?
Daniel Grunblatt.
at runops_jit?
Daniel Grunblatt.
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 wrote
On Wed, 22 May 2002, Aldo Calpini wrote:
hello,
I've added the following new ops to i386/core.jit:
inc_i
dec_i
inc_i_ic
dec_i_ic
lt_i_ic_ic
lt_i_i_ic
gt_i_ic_ic
gt_i_i_ic
ge_i_ic_ic
ge_i_i_ic
le_i_ic_ic
le_i_i_ic
eq_i_ic_ic
On Wed, 24 Apr 2002, Daniel Grunblatt wrote:
Folks,
From now on, please every time you want to send a patch send it to
[EMAIL PROTECTED] so that we can keep track of it and it doesn't
get lost in space.
Thanks.
Daniel Grunblatt.
And, please:
1 - Try to send the patch
On 22 May 2002, Sean O'Rourke (via RT) wrote:
# New Ticket Created by Sean O'Rourke
# Please include the string: [netlabs #610]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=610
I believe there is a bug in
x86/sparc/alpha systems.
Jason, Excellent work.
Regards,
Daniel Grunblatt.
Try this:
cvs -d :pserver:[EMAIL PROTECTED]:/home/perlcvs get parrot
Daniel Grunblatt.
On 20 May 2002, Alberto Manuel [ISO-8859-1] Brandão Simões wrote:
On Mon, 2002-05-20 at 17:58, Daniel Grunblatt wrote:
On 20 May 2002, Alberto Manuel [ISO-8859-1] Brandão Simões wrote:
Directory
);
string_destroy(t);
goto NEXT();
}
t gets collected, one way to solve this is to disable the GC inside the
op, but I don't know if that's the best way, thoughts?
Regards,
Daniel Grunblatt.
On Mon, 20 May 2002, Daniel Grunblatt wrote:
On 20 May 2002, Peter Gibbs wrote:
# New Ticket
On 20 May 2002, Peter Gibbs wrote:
# New Ticket Created by Peter Gibbs
# Please include the string: [netlabs #602]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=602
Attached patch to core.ops implements
On 20 May 2002, David Lloyd wrote:
This patch removes the const-ness of those STRINGs that are modified.
Applied, thanks.
On Mon, 20 May 2002, David M. Lloyd wrote:
What about subroutines? Are bsr jsr the way it's gonna be or is there
a rework in the works?
docs/pdds/pdd03_calling_conventions.pod :)
On Mon, 20 May 2002, Jason Gloudon wrote:
The buflen of a new header was not always set to 0, which would cause SIGSEGVs
when parrot_reallocate tries to copy a non-zero length buffer with a bufstart
of NULL. This would happen when buffers get recycled.
I don't know if new_pmc_header has
1 - 100 of 142 matches
Mail list logo
