Re: [CVS ci] multiarray
On Sat, 26 Oct 2002, Leopold Toetsch wrote: > I committed a new multiarray.pmc, now based on list.c. It's not totally > finished yet (the clone codes needs some polishing to call the init_pmc > method) and needs a lot more tests. > > But I hate failing tests ... > > leo > Well done Leo you beat me to it, :-) i got finished last weekend with my version of marray with underlying list. But i believe your version looks better. Keep up the good work! /Josef
[perl #18139] [PATCH] Yet another sprintf bug
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18139]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18139 >
Found yet another bug in sprintf: The code insists on prepending at
least one byte
"%02d", 25 => 025
Attached patch fixes this and supplies a test
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/40710/32812/ee5c7a/sprintf.diff
Index: spf_render.c
===
RCS file: /cvs/public/parrot/spf_render.c,v
retrieving revision 1.4
diff -u -r1.4 spf_render.c
--- spf_render.c 27 Oct 2002 11:57:14 - 1.4
+++ spf_render.c 28 Oct 2002 22:19:28 -
@@ -121,7 +121,7 @@
}
}
-if (info->flags & FLAG_WIDTH) {
+if ((info->flags & FLAG_WIDTH) && info->width > len) {
STRING *fill;
if (info->flags & FLAG_ZERO) {
@@ -131,8 +131,7 @@
fill = cstr2pstr(" ");
}
-if (info->width > len)
-string_repeat(interpreter, fill, info->width - len, &fill);
+string_repeat(interpreter, fill, info->width - len, &fill);
if (info->flags & FLAG_MINUS) { /* left-align */
string_append(interpreter, str, fill, 0);
Index: t/src/sprintf.t
===
RCS file: /cvs/public/parrot/t/src/sprintf.t,v
retrieving revision 1.8
diff -u -r1.8 sprintf.t
--- t/src/sprintf.t 28 Oct 2002 07:50:32 - 1.8
+++ t/src/sprintf.t 28 Oct 2002 22:19:28 -
@@ -95,6 +95,9 @@
S = Parrot_sprintf_c(interpreter, "== %05d\n", ival);
printf("%05d %s", (int) ival,
string_to_cstring(interpreter, S));
+S = Parrot_sprintf_c(interpreter, "== %2d\n", ival);
+printf("%2d %s", (int) ival,
+ string_to_cstring(interpreter, S));
ival = -1;
S = Parrot_sprintf_c(interpreter, "== %#x\n", ival);
@@ -129,6 +132,7 @@
25 ==25
25== 25 |
00025 == 00025
+25 == 25
0x == 0x
-001 == -001
That's all, folks!
Re: Of mops and microops
On Tue, Oct 29, 2002 at 08:26:00AM +0100, Leopold Toetsch wrote: > Dan Sugalski wrote: > > I'm currently leaning against it only because it doesn't ultimately help > > the JIT. What we have now is wildly cool and damn useful (and has anyone > > heard from Daniel lately, BTW?) but there's room for more optimizations. > > > Yes, that's correct. JIT wouldn't profit currently. But with an > optimized stream of (micro-)Ops, having optimzed fetch/store opcodes not > in (basic-) block but finer granularity, JIT could profit too. Also the > JIT-optimizer now run at load time would be done at compile time, so JIT > startup time would be cut down. But then you end up with a messier two level register spillage problem at compile time, don't you? Which values to spill from fast to slow registers, and which values to spill further from slow to stack? And is there much literature on this sort of thing? > My hack with the 3 globals includes obviously some cheating, globals are > a nono, when having multiple interpreters. But nethertheless we could > produce an optimized PBC stream, where the 3*4 registers are treated as > "fast" registers, with load/store to the 32*4 slower registers only when > necessary. This would also fit neatly with my proposal WRT keyed access. And the fast registers are going to be called ax, bx, cx and dx? :-) > I was also thinking of the various fixed sized integer ops for JVM or > C#. The load/store ops would prepare integers of needed size and do sign > extension when necessary. I've had 3 drafts at responding to this, and I conclude "my brain hurts" I don't see an "obvious" clean solution to this, specifically 64 bit ops that run correctly on 32 bit native systems, but take advantage of 64 bit native systems. Nicholas Clark
[perl #18141] [PATCH] determine PARROT_STACK_DIR on Win32 with Visual C++
# New Ticket Created by "Aldo Calpini"
# Please include the string: [perl #18141]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18141 >
due to a bug in config/auto/stackdir.pl, Configure.pl
was unable to determine PARROT_STACK_DIR when using
Visual C++.
the error was to use ${cc_exe_out} as a parameter to
$link, instead of ${ldout}, which resulted in producing
the wrong executable name for the test program. as a
result, Parrot was unable to compile (syntax error in
dod.c).
the attached patch fixes the problem.
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/40714/32817/be0ada/stackdir.patch
stackdir.patch
Description: stackdir.patch
Re: [CVS ci] multiarray
Josef Hook wrote: Well done Leo you beat me to it, :-) i got finished last weekend with my version of marray with underlying list. If I had known, that i will rewrite it, I'd dropped a note - sorry for work duplication. But it took an hour or so and I thought, just commit early so that test failure is gone ;-) But i believe your version looks better. Keep up the good work! Thank you. Do you have additional tests, we can put in? /Josef leo
[perl #18142] [PACTH] Parrot_destroy
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #18142]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18142 >
Attached is a (big) patch that implements Parrot_destroy.
Test results with --gc-debug: All tests successful.
Test results with leak detection[1]/--gc-debug:
Failed Test Status Wstat Total Fail Failed List of failed
---
t/op/hacks.t 21 50,00% 1
t/op/interp.t 22 100,00% 1-2
t/op/rx.t237 30,43% 8-9, 12-14, 21-22
t/op/stacks.t352 5,71% 31-32
t/pmc/pmc.t 834 4,82% 62-64, 76
7 subtests skipped.
Failed 5/34 test scripts, 85.29% okay. 16/495 subtests failed, 96.77% okay.
Some notes WRT still exisiting leaks:
- hacks.t: PIO related, open does new_IO which doesn't seem to store
this structure somewhere. Explicit closing the handle would help, as
done now in embed.c
- interp.t: crashes with ATEXIT_DESTROY (2 interpreters interfere)
- rx.t:Bitmaps leakage
- stacks.t: leaking intstack
- pmc.t: leaking intqueue
TODO:
- header file changes WRT global warnings
- probably remove intqueue from classes
- move the stack destroying code to stacks, reuse it in
classes/coroutine.pmc
- fix PIO_destroy
- to clean up properly after exceptions, I added a define locally to
interpreter.c: ATEXT_DESTROY, which installs an atexit-handler. This
works only for one existing interpreter, due to the __interpreter
global. We should either keep an interpreter array or fix
internal_exception to take an Parrot_Interp*, so that Parrot_destroy
can be called.
- Running with --gc=malloc is broken (mostly COWed strings).
- (unrelated) mmap in Parrot_readbc is not used now, missing
HAS_HEADER_SYSMMAN definition
Some notes to the changes:
- classe/*.pmc missing flags setting in clone, destroy
- dod.c made free_unused_* global
- embed.c PIO_close
- headers.c honor active_destroy, destroy_headers
- chartype.c usascii (better latin1) is default
- interpreter Parrot_destroy
- io/io.c PIO_destroy / _close
- res*.c destroy_memory_pools
- t/src/manifest accout for skipped test
[1] I used run-yamd (s. attached testyamd script) for running all tests
through the memory debugger and made leaking tests fail. This is part
of YAMD (Yet Another Memory Debugger).
Please test the patch on different platforms. Mine is i386/linux.
Have fun,
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/40716/32820/b03730/parrot_destroy.patch
--- parrot/classes/continuation.pmc Mon Oct 21 13:56:24 2002
+++ parrot-leo/classes/continuation.pmc Tue Oct 29 10:47:04 2002
@@ -60,6 +60,7 @@
= mem_sys_allocate(sizeof(struct Parrot_Continuation));
ret->vtable = &Parrot_base_vtables[enum_class_Continuation];
ret->data = retc;
+ret->flags |= PMC_custom_mark_FLAG | PMC_active_destroy_FLAG;
memcpy(retc, SELF->data, sizeof(struct Parrot_Continuation));
/* we may have copied our stack already, so we need to re-COW
* it */
--- parrot/classes/coroutine.pmcMon Oct 21 13:56:24 2002
+++ parrot-leo/classes/coroutine.pmcTue Oct 29 10:57:23 2002
@@ -33,6 +33,9 @@
}
void destroy () {
+ /* XXX stack_destroy for deeper stacks */
+ mem_sys_free(((struct Parrot_Coroutine *)SELF->data)->ctx.user_stack);
+ mem_sys_free(((struct Parrot_Coroutine *)SELF->data)->ctx.control_stack);
mem_sys_free(SELF->data);
}
@@ -84,6 +87,7 @@
PMC * ret = new_pmc_header(INTERP);
ret->vtable = &Parrot_base_vtables[enum_class_Coroutine];
ret->data = retc = mem_sys_allocate(sizeof(struct Parrot_Coroutine));
+ret->flags |= PMC_custom_mark_FLAG | PMC_active_destroy_FLAG;
memcpy(ret->data, SELF->data, sizeof(struct Parrot_Coroutine));
stack_mark_cow(retc->ctx.user_stack);
stack_mark_cow(retc->ctx.control_stack);
--- parrot/classes/sub.pmc Mon Aug 5 08:49:15 2002
+++ parrot-leo/classes/sub.pmc Tue Oct 29 10:45:50 2002
@@ -54,6 +54,7 @@
PMC* clone () {
PMC * ret = new_pmc_header(INTERP);
ret->vtable = &Parrot_base_vtables[enum_class_Sub];
+ ret->flags |= PMC_active_destroy_FLAG;
ret->data = mem_sys_allocate(sizeof(struct Parrot_Sub));
memcpy(ret->data, SELF->data, sizeof(struct Parrot_Sub));
return ret;
--- parrot/dod.cMon Oct 28 14:59:42 2002
+++ parrot-leo/dod.cTue Oct 29 10:44:16 2002
@@ -279,7 +279,7 @@
}
/* Free up any PMCs that aren't in use */
-static void
+void
free_unused_PMCs(struct Parrot_Interp *interpreter)
{
struct Small_Object_Arena *cur_arena;
@@ -365,7 +365,7 @@
#endif /* GC_IS_MALLOC */
/* Put any buffers that are now unused, on to the free list
Re: Parrot 0.0.9
Dan Sugalski <[EMAIL PROTECTED]> writes: > Well, on thinking a bit about this, there's no reason that we have to > worry--it's perfectly OK for us to declare, unconditionally, that > segment 0 is always bytecode, 1 line number info, and so on, with > everything after position X (for some value of X) left up in the > air. A bit dodgy, true, as it means that any new known segment types > we add in will be floating, but I don't think we're going to end up > with too many performance-critical pieces in the bytecode. (Arguably > it's just the bytecode itself, the symbols, and the constants, as the > rest are looked at under exceptional circumstances or on (rare) demand) *No* This really kills extendability, or makes it at least very ugly. It needs to prealloc a certain number of segments. Each of this has a fixed semantic. Extending means consuming on of the preallocated fields, or using some segment beyond the preallocated area but then it needs a type field. In fact the preallocated segments also have a type-field: the position in the packfile. I'm fine with a numeric type for the core, and have some extension type with named types if it is a speed issue, but I really dont like this positional approach. BTW: COFF and ELF use named sections. bye b. -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Of mops and microops
Nicholas Clark wrote: On Tue, Oct 29, 2002 at 08:26:00AM +0100, Leopold Toetsch wrote: But then you end up with a messier two level register spillage problem at compile time, don't you? Yes. ...Which values to spill from fast to slow registers, and which values to spill further from slow to stack? imcc does already spilling if more then 32 registers per type are used. Adding another step to optimize for 3 * 4 usage wouldn't be much different IMHO. It could probably done in one step, when we define I0-I3, S0-S2 ... as the "fast" registers. Though I didn't thin much of this until now. ... And is there much literature on this sort of thing? Dunno. And the fast registers are going to be called ax, bx, cx and dx? :-) How did you know that ;-) No actually I'm always thinking of 3*4 registers. I was also thinking of the various fixed sized integer ops for JVM or C#. The load/store ops would prepare integers of needed size and do sign extension when necessary. I've had 3 drafts at responding to this, and I conclude "my brain hurts" I don't see an "obvious" clean solution to this, specifically 64 bit ops that run correctly on 32 bit native systems, but take advantage of 64 bit native systems. 2 separate core.ops files e.g. core32.ops emulating 64bit ints, and core64.ops with native 64bit ints, generated from core.ops? Nicholas Clark leo
[perl #18144] [PATCH] resurrect pdump
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18144]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18144 >
In order to do some debugging with PackFiles I had resurrected
pdump. It now uses a valid interpreter for output.
To test it use
make pdump
pdump life.pbc
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/40719/32825/696825/pdump.diff
Index: pdump.c
===
RCS file: /cvs/public/parrot/pdump.c,v
retrieving revision 1.13
diff -u -r1.13 pdump.c
--- pdump.c 6 Mar 2002 15:45:28 - 1.13
+++ pdump.c 28 Oct 2002 22:20:58 -
@@ -11,6 +11,10 @@
*/
#include "parrot/packfile.h"
+#include "parrot/interpreter.h"
+
+void PackFile_dump (struct Parrot_Interp *interpreter,
+struct PackFile *pf);
int
main(int argc, char **argv)
@@ -20,7 +24,7 @@
opcode_t *packed;
size_t packed_size;
struct PackFile *pf;
-struct Parrot_Interp *interpreter = make_interpreter(NO_FLAGS);
+struct Parrot_Interp *interpreter;
if (argc != 2) {
fprintf(stderr, "pdump: usage: pdump FILE\n");
@@ -37,9 +41,9 @@
return 1;
}
-init_world();
-
interpreter = make_interpreter(NO_FLAGS);
+Parrot_init (interpreter, (void *) &file_stat);
+init_world(interpreter);
packed_size = file_stat.st_size;
@@ -68,8 +72,8 @@
printf("Can't unpack.\n");
return 1;
}
-PackFile_dump(pf);
-PackFile_DELETE(pf);
+PackFile_dump(interpreter, pf);
+PackFile_destroy(pf);
pf = NULL;
Index: packdump.c
===
RCS file: /cvs/public/parrot/packdump.c,v
retrieving revision 1.4
diff -u -r1.4 packdump.c
--- packdump.c 11 Oct 2002 01:46:31 - 1.4
+++ packdump.c 28 Oct 2002 22:20:58 -
@@ -13,64 +13,82 @@
#include "parrot/parrot.h"
#include "parrot/packfile.h"
+/*
+** FIXME: this should also be segmentized.
+** For now just remove some warnings
+*/
+
+void PackFile_dump (struct Parrot_Interp *, struct PackFile *);
+static void PackFile_FixupTable_dump (struct Parrot_Interp *,
+ struct PackFile_FixupTable *);
+static void PackFile_ConstTable_dump (struct Parrot_Interp *,
+ struct PackFile_ConstTable *);
+static void PackFile_Constant_dump (struct Parrot_Interp *,
+struct PackFile_Constant *);
+
void
-PackFile_dump(struct PackFile *self)
+PackFile_dump(struct Parrot_Interp *interpreter, struct PackFile *self)
{
size_t i;
-PIO_printf(NULL, "FIXUP => {\n");
+PIO_printf(interpreter, "FIXUP => {\n");
-PackFile_FixupTable_dump(self->fixup_table);
+PackFile_FixupTable_dump(interpreter, self->fixup_table);
-PIO_printf(NULL, "},\n");
+PIO_printf(interpreter, "},\n");
-PIO_printf(NULL, "CONST => [\n");
+PIO_printf(interpreter, "CONST => [\n");
-PackFile_ConstTable_dump(self->const_table);
+PackFile_ConstTable_dump(interpreter, self->const_table);
-PIO_printf(NULL, "],\n");
+PIO_printf(interpreter, "],\n");
-PIO_printf(NULL, "BCODE => [ # %ld bytes", (long)self->byte_code_size);
+PIO_printf(interpreter, "BCODE => [ # %ld bytes",
+ (long)self->byte_code_size);
for (i = 0; i < self->byte_code_size / sizeof(opcode_t); i++) {
if (i % 8 == 0) {
-PIO_printf(NULL, "\n%08lx: ", (unsigned long)i * sizeof(opcode_t));
+PIO_printf(interpreter, "\n%08lx: ",
+ (unsigned long)i * sizeof(opcode_t));
}
-PIO_printf(NULL, "%08lx ", (unsigned long)self->byte_code[i]);
+PIO_printf(interpreter, "%08lx ", (unsigned long)self->byte_code[i]);
}
-PIO_printf(NULL, "\n]\n");
+PIO_printf(interpreter, "\n]\n");
return;
}
void
-PackFile_FixupTable_dump(struct PackFile_FixupTable *self)
+PackFile_FixupTable_dump(struct Parrot_Interp *interpreter,
+ struct PackFile_FixupTable *self)
{
UNUSED(self);
return;
}
void
-PackFile_ConstTable_dump(struct PackFile_ConstTable *self)
+PackFile_ConstTable_dump(struct Parrot_Interp *interpreter,
+ struct PackFile_ConstTable *self)
{
opcode_t i;
if (!self) {
-PIO_eprintf(NULL, "PackFile_ConstTable_dump: self == NULL!\n");
+PIO_eprintf(interpreter, "PackFile_ConstTable_dump: self == NULL!\n");
return;
}
for (i = 0; i < self->const_count; i++) {
-PIO_printf(NULL, "# %ld:\n", (long)i);
-PackFile_Constant_dump(self->constants[i]);
+PIO_printf(interpreter, "# %ld:\n", (long)i);
+PackFile_Constant_dump(interpreter, self->constants[i]);
}
return;
}
void
-PackFil
Re: [perl #18139] [PATCH] Yet another sprintf bug
Jürgen Bömmels (via RT) wrote: # New Ticket Created by Jürgen Bömmels # Please include the string: [perl #18139] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18139 > Thanks, applied leo
Re: Copyright notices and license stuff
Dan Wrote, >>This came up a while back in regards to GCC. Someone was working on a >>front (or back, I don't recall) end to gcc to dump out the internal >>representation of source as XML for some damn thing or other. I am working on something like that, there are 2-3 other similar projects. I am using the front end tree structures of the gcc to extract information about software into a new visualization and reverse engineering tool. > This >>was essentially stopped (don't recall whether it was stopped >>outright, or GPL was put on the generated rep, which is close enough >>to stopping for most folks) by the GCC folks as they claimed, quite >>rightly, that the internal representation was a derived work of their >>code as well as the original source, and as such they could put their >>license on it too. I had stopped distribution for a while on my own accord. It was not stopped by the gcc. I had stopped for a while, out of respect of the wishes of the gcc group and rms. It now turns out that they are doing the same themselves. There is not any real policy or consistency in the actions of the gcc and fsf group, therefore I will hold back any longer. The gcc interface project has been offically restarted. http://gcc.gnu.org/ml/gcc/2002-10/msg00806.html >> quite >>rightly, that the internal representation was a derived work of their >>code as well as the original source, and as such they could put their >>license on it too. This is not correct, there is no way to enforce that via the GPL, which is based on copyright. Look at the dumping of the ASTS into GraphViz Format. The only arguments which are pretty weak where that the data structures are copyrighted, but there is no real case for it. Just lots and lots of FUD from the gcc developers. >> This doesn't apply to object files that gcc >>generates as there's explicit disclaiming of ownership on them in >>gcc's license, as there is with pretty much all compilers. This does not apply to any of the input or output files of a GPled software, only the creative work of a person can be copyrighted. Mechanical translations are just derived works. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: How to portably link on Win32 (all flavors), OS/2 and VMS?
On Mon, 28 Oct 2002, Josh Wilmes wrote: > > If patch [perl #18127] goes in, we can dodge this bullet a while longer :) Agreed. But since we can't dodge it forever, this seemed as good a place to try it as any. (Particularly if your patch goes in, then I can't possibly break anything :-). -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #18127] [PATCH] Implicit stack direction probe
Jason Gloudon (via RT) wrote: # New Ticket Created by Jason Gloudon # Please include the string: [perl #18127] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18127 > I have problems to understand the line below: (not voting against your patch - original line is similar) +cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr + PARROT_PTR_ALIGNMENT) When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are skipped during stack scanning by incrementing cur_var_ptr by sizeof(size_t) * PARROT_PTR_ALIGNMENT bytes. As a side note: applying your patch slows down e.g. life.pasm by ~2%. (I really don't see why). leo
Re: How to portably link on Win32 (all flavors), OS/2 and VMS?
Andy Dougherty wrote: > but I'm unsure what to put for link_exe_out for each of the three > compilers mentioned in config/init/hints/mswin32.pl, nor for the > compilers used under OS/2 and VMS. config/init/hints/mswin32.pl already defines what you need. is called 'ld_out' (also see my recent patch to stackdir.pl). cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [perl #18127] [PATCH] Implicit stack direction probe
On Tue, Oct 29, 2002 at 02:40:14PM +0100, Leopold Toetsch wrote: > >+cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr + > >PARROT_PTR_ALIGNMENT) > > When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are skipped > during stack scanning by incrementing cur_var_ptr by sizeof(size_t) * > PARROT_PTR_ALIGNMENT bytes. ptrdiff_t is not a pointer type, so cur_var_ptr + PARROT_PTR_ALIGNMENT skips exactly PARROT_PTR_ALIGNMENT bytes. You may not be matching ( )'s quite right. > As a side note: applying your patch slows down e.g. life.pasm by ~2%. > (I really don't see why). Are you compiling with optimization enabled ? Is the difference consistent ? If the answer to both questions is yes, it is probably a cache effect related to the new variable on the function stack. I doubt the slowdown is universal. I will try to check on SPARC sometime today. -- Jason
Re: [perl #18144] [PATCH] resurrect pdump
Jürgen Bömmels (via RT) wrote: # New Ticket Created by Jürgen Bömmels # Please include the string: [perl #18144] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18144 > Thanks, applied - with little modifications. leo
Re: How to portably link on Win32 (all flavors), OS/2 and VMS?
On Tue, 29 Oct 2002, Aldo Calpini wrote: > Andy Dougherty wrote: > > but I'm unsure what to put for link_exe_out for each of the three > > compilers mentioned in config/init/hints/mswin32.pl, nor for the > > compilers used under OS/2 and VMS. > > config/init/hints/mswin32.pl already defines what you need. is called > 'ld_out' (also see my recent patch to stackdir.pl). Thanks. I wasn't sure if that is really what I wanted. $ldout is what you need to specify the output to $ld. ($ld is the command you use to build shared libraries. That's not what we're doing here.) I want the flag that you need to specify to $link to produce an executable. It's possible they are the same. I didn't know and didn't want to guess. I also don't know if they are the same for Borland CC, OS/2, and VMS. Hence my post. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #18131] [PATCH] make disassemble.pl print header information
Matthew Zimmerman (via RT) wrote: # New Ticket Created by Matthew Zimmerman # Please include the string: [perl #18131] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18131 > Thanks applied + printing of fingerprint. leo
Re: [perl #18127] [PATCH] Implicit stack direction probe
Jason Gloudon wrote: On Tue, Oct 29, 2002 at 02:40:14PM +0100, Leopold Toetsch wrote: +cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr + PARROT_PTR_ALIGNMENT) When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are skipped during stack scanning by incrementing cur_var_ptr by sizeof(size_t) * PARROT_PTR_ALIGNMENT bytes. ptrdiff_t is not a pointer type, so cur_var_ptr + PARROT_PTR_ALIGNMENT skips exactly PARROT_PTR_ALIGNMENT bytes. You may not be matching ( )'s quite right. Brr, yes. I checked with gdb. cur_var_ptr is incremented by PARROT_PTR_ALIGNMENT _bytes_ i.e. by 1 byte on i386. Can we really have e.g. odd aligned PMCs on stack? I don't think so. Or am I still missing something? As a side note: applying your patch slows down e.g. life.pasm by ~2%. (I really don't see why). Are you compiling with optimization enabled ? Is the difference consistent ? W/o optimization, but consistent. If the answer to both questions is yes, it is probably a cache effect related to the new variable on the function stack. I doubt the slowdown is universal. I will try to check on SPARC sometime today. leo
Re: [perl #18127] [PATCH] Implicit stack direction probe
At 3:27 PM +0100 10/29/02, Leopold Toetsch wrote: Jason Gloudon wrote: On Tue, Oct 29, 2002 at 02:40:14PM +0100, Leopold Toetsch wrote: +cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr + PARROT_PTR_ALIGNMENT) When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are skipped during stack scanning by incrementing cur_var_ptr by sizeof(size_t) * PARROT_PTR_ALIGNMENT bytes. ptrdiff_t is not a pointer type, so cur_var_ptr + PARROT_PTR_ALIGNMENT skips exactly PARROT_PTR_ALIGNMENT bytes. You may not be matching ( )'s quite right. Brr, yes. I checked with gdb. cur_var_ptr is incremented by PARROT_PTR_ALIGNMENT _bytes_ i.e. by 1 byte on i386. Can we really have e.g. odd aligned PMCs on stack? I don't think so. Or am I still missing something? There was some indication back when this was first implemented that the i386, at least when running windows, could have odd-aligned pointers in stack-allocated data. Nobody was 100% sure, but better safe than not, at least until someone can say definitively that we're being too cautious. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Draft sketch of bytecode generation
At 8:40 AM -0800 10/28/02, chromatic wrote: On Sunday 27 October 2002 23:27, Brent Dax wrote: Appearances are deceiving--the first adds some (unparsed?) source code, the second adds information on file and line numbers, probably based on offset into the bytecode. Similar in terms of implementation, that is. :) Underlying implementation, sure--we'll just be jamming bytes into the appropriate chunks of the segment, potentially in multiple calls. I'm not sure I want to worry too much about that quite yet, though, as I'm still trying to nail down the required functionality. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #18127] [PATCH] Implicit stack direction probe
Jason Gloudon wrote: ptrdiff_t is not a pointer type, so cur_var_ptr + PARROT_PTR_ALIGNMENT skips exactly PARROT_PTR_ALIGNMENT bytes. I did modify your patch slightly - reversed directions (top->down is probably more common) - increment by sizeof(void*) This boost life.pasm gens from 270 -> 330 The I did apply #17495 again: 330 -> 403 WRT the latter: It was considered unsafe to put lo_var_ptr just above the run_loop. I still don't see an example for this. It could be a src test, which first tests some PMC stuff, the runs an interpreter and finally checks PMCs again. To be safe, we could do: if (!interpreter->lo_var_ptr) interpreter->lo_var_ptr = &lo_var_ptr; Default is not to set it early, so interpreter->lo_var_ptr would always be near the run loop. This applies of course to all cores. (All tests still succeed --gc-debug) leo --- parrot/ops2cgc.pl Thu Jul 11 10:25:47 2002 +++ parrot-leo/ops2cgc.pl Sun Sep 22 18:42:28 2002 @@ -158,6 +158,14 @@ print SOURCElo_var_ptr; size_t hi_var_ptr = (size_t)&lo_var_ptr; -size_t prefix; +size_t prefix, tmp_ptr; ptrdiff_t cur_var_ptr; size_t buffer_min = get_min_buffer_address(interpreter); @@ -476,17 +476,20 @@ size_t mask = find_common_mask(buffer_min < pmc_min ? buffer_min: pmc_min, buffer_max > pmc_max ? buffer_max : pmc_max); +if (!lo_var_ptr) +return last; +if(lo_var_ptr < hi_var_ptr){ +tmp_ptr = hi_var_ptr; +hi_var_ptr = lo_var_ptr; +lo_var_ptr = tmp_ptr; +} /* Get the expected prefix */ prefix = mask & buffer_min; -if (!lo_var_ptr) -return last; -for (cur_var_ptr = lo_var_ptr; -(ptrdiff_t)(cur_var_ptr * PARROT_STACK_DIR) < -(ptrdiff_t)(hi_var_ptr * PARROT_STACK_DIR); -cur_var_ptr = (size_t)( (ptrdiff_t)cur_var_ptr + -PARROT_STACK_DIR * PARROT_PTR_ALIGNMENT ) +for (cur_var_ptr = hi_var_ptr; + (ptrdiff_t)cur_var_ptr < (ptrdiff_t)lo_var_ptr; + cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr + sizeof(void*)) ) { size_t ptr = *(size_t *)cur_var_ptr;
Re: [perl #18127] [PATCH] Implicit stack direction probe
Dan Sugalski wrote: At 3:27 PM +0100 10/29/02, Leopold Toetsch wrote: ... Can we really have e.g. odd aligned PMCs on stack? I don't think so. Or am I still missing something? There was some indication back when this was first implemented that the i386, at least when running windows, could have odd-aligned pointers in stack-allocated data. Nobody was 100% sure, but better safe than not, at least until someone can say definitively that we're being too cautious. Then lets first test my patch(es) (in a different followup) on all plattforms. If i386/Win really fails, we make some #ifdef. life.pasm gens 270 => 403 is an argument ;-) leo
Re: [perl #18127] [PATCH] Implicit stack direction probe
At 4:57 PM +0100 10/29/02, Leopold Toetsch wrote: Dan Sugalski wrote: At 3:27 PM +0100 10/29/02, Leopold Toetsch wrote: ... Can we really have e.g. odd aligned PMCs on stack? I don't think so. Or am I still missing something? There was some indication back when this was first implemented that the i386, at least when running windows, could have odd-aligned pointers in stack-allocated data. Nobody was 100% sure, but better safe than not, at least until someone can say definitively that we're being too cautious. Then lets first test my patch(es) (in a different followup) on all plattforms. If i386/Win really fails, we make some #ifdef. life.pasm gens 270 => 403 is an argument ;-) Oh, absolutely. Correctness, though, is more important that speed. (Barely, but still more important :) I'm always loathe to count on empirical research on computers--the specs are available *somewhere*, and we should see about digging them up and getting a final answer one way or another. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Parrot 0.0.9
[EMAIL PROTECTED]:
# > Well, on thinking a bit about this, there's no reason that
# we have to
# > worry--it's perfectly OK for us to declare, unconditionally, that
# > segment 0 is always bytecode, 1 line number info, and so on, with
# > everything after position X (for some value of X) left up
# in the air.
# > A bit dodgy, true, as it means that any new known segment
# types we add
# > in will be floating, but I don't think we're going to end
# up with too
# > many performance-critical pieces in the bytecode. (Arguably
# it's just
# > the bytecode itself, the symbols, and the constants, as the
# rest are
# > looked at under exceptional circumstances or on (rare) demand)
#
# *No*
#
# This really kills extendability, or makes it at least very
# ugly. It needs to prealloc a certain number of segments. Each
# of this has a fixed semantic. Extending means consuming on of
# the preallocated fields, or using some segment beyond the
# preallocated area but then it needs a type field. In fact the
# preallocated segments also have a
# type-field: the position in the packfile.
How about this structure:
HEADER
SEGMENT 0
CHUNK 0 (DIRECTORY)
SIZE:
DATA:
CHUNK 0 ENTRY
TYPE: DIRECTORY (type 0)
OFFSET:
CHUNK 1 ENTRY
TYPE: e.g. BYTECODE (type 3)
OFFSET:
CHUNK 2 ENTRY
TYPE: e.g. CONSTTABLE (type 1)
OFFSET:
CHUNK 3 ENTRY
TYPE: e.g. FIXUP (type 2)
OFFSET:
CHUNK 4 ENTRY
TYPE: e.g. LINETABLE (type 4)
OFFSET:
CHUNK 1
SIZE:
DATA:
CHUNK 2
SIZE:
DATA:
CHUNK 3
SIZE:
DATA:
CHUNK 4
SIZE:
DATA:
SEGMENT 1
SEGMENT 2
SEGMENT 3
SEGMENT 4
Each chunk just holds its size and its data--the type is stored in the
directory. Chunk 0 is the only chunk with fixed meaning--it's always
the directory. There should only be one chunk per segment of the given
type. We'll reserve some of the types--say, up to 127 to be safe--and
let any outside tools use chunk numbers above that.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: How to portably link on Win32 (all flavors), OS/2 and VMS?
Here's my proposal for stage one: This patch is intended to define explicitly what the different compiler and linker commands and flags are, what they are supposed to mean, and how they are to be used. Does this set of variables look sufficient for everyone, and are the definitions clear? If so, the next step is to put the appropriate values in the hints files and re-work Configure and the Makefiles to use them consistently. -- Andy Dougherty [EMAIL PROTECTED]
Re: How to portably link on Win32 (all flavors), OS/2 and VMS?
On Tue, 29 Oct 2002, Andy Dougherty wrote:
> Here's my proposal for stage one: This patch is intended to define
> explicitly what the different compiler and linker commands and flags
> are, what they are supposed to mean, and how they are to be used.
>
> Does this set of variables look sufficient for everyone, and are the
> definitions clear? If so, the next step is to put the appropriate values
> in the hints files and re-work Configure and the Makefiles to use them
> consistently.
Of course it helps to include the patch :-(.
diff -r -u parrot-orig/config/init/data.pl parrot-andy/config/init/data.pl
--- parrot-orig/config/init/data.pl Thu Sep 12 10:39:22 2002
+++ parrot-andy/config/init/data.pl Tue Oct 29 11:44:55 2002
@@ -22,42 +22,70 @@
# Compiler -- used to turn .c files into object files.
# (Usually cc or cl, or something like that.)
+# Compile C source files with
+#$cc $ccflags $cc_inc $cc_debug $cc_warn $cc_c file.c
+# If you want this object file to be part of a shared library,
+# then you need to compile instead with
+#$cc $ccflags $cc_inc $cc_debug $cc_warn $cc_dlflags $cc_c file.c
+# Assume the compiler will put the object file in file$o.
+# These Unix-ish defaults should be overridden by hints files
+# as necessary for Win32, VMS, and other non-Unix systems.
cc=> $Config{cc},
ccflags => $Config{ccflags},
+cc_c => '-c' # Empty for VMS.
+cc_inc => "-I./include", # How to pick up parrot includes.
+cc_debug => '-g',
+cc_warn => '',
+cc_dlflags=> $Config{cccdlflags}, # Flags necessary to compile
+ # this file for use in a shared library.
+cc_o_out => '-o ', # cc object output file. Don't use this;
+ # it's not portable.
+cc_exe_out=> '-o ', # cc executable output file. Don't use this.
+ # Use $link to create executables.
+cc_ldflags=> '',# prefix for ldflags (necessary for Win32)
+ # Huh? This isn't used anywhere.
+ # Don't use this. I don't know what
+ # it means.
# Linker, used to link object files (plus libraries) into
# an executable. It is usually $cc on Unix-ish systems.
# VMS and Win32 might use "Link".
# Perl5's Configure doesn't distinguish linking from loading, so
# make a reasonable guess at defaults.
+# Create an executable with
+# $link $linkflags $link_debug ${link_out}file${exe} file${o} $libs
+# If you have multiple object files, VMS needs to have them
+# separated by commas, like this: (and all on one line)
+# $link $linkflags $link_debug ${link_out}file${exe} \
+# file1${o},file2${o} $libs
link => $Config{cc},
linkflags => $Config{ldflags},
+link_debug=> '',
+link_out => '-o ',# linker output file. Keep the trailing
+ # space for Unix-like linkers.
# ld: Tool used to build dynamically loadable libraries. Often
# $cc on Unix-ish systems, but apparently sometimes it's ld.
+# The exact usage has not been determined yet.
ld=> $Config{ld},
ldflags => $Config{ldflags},
+ld_out=> '-o ',# ld output file. Keep the trailing
+ # space for Unix-like linkers.
+ld_debug => '',# include debug info in executable
+ld_shared => $Config{lddlflags}, # Any flags specifically
+# needed to instruct ld to create
+ # a shared libary.
+ld_shared_flags=> '', # What is this, exactly? For GNU ld, it was
+ # '-Wl,-soname,libparrot$(SO)'
libs => $Config{libs},
-cc_inc => "-I./include",
-cc_debug => '-g',
-link_debug=> '',
-cc_warn => '',
o => '.o',# object files extension
-so=> '.so', # dynamic link library or shared object
extension
+so=> '.so', # dynamic link library or
+ # shared object extension
a => '.a',# library or archive extension
exe => $Config{_exe}, # executable files extension
-cc_o_out => '-o ', # cc object output file
-cc_exe_out=> '-o ', # cc executable output file (different on
Win32)
-
-cc_ldflags=> '', # prefix for ldflags (necessary for Win32)
-ld_out=> '-o ', # ld output file
-ld_debug => '', # include debug info in executable
-ld_shared => $Config{lddlflags},
-ld_shared_flags
Re: Parrot 0.0.9
At 11:46 AM +0100 10/29/02, Juergen Boemmels wrote: Dan Sugalski <[EMAIL PROTECTED]> writes: Well, on thinking a bit about this, there's no reason that we have to worry--it's perfectly OK for us to declare, unconditionally, that segment 0 is always bytecode, 1 line number info, and so on, with everything after position X (for some value of X) left up in the air. A bit dodgy, true, as it means that any new known segment types we add in will be floating, but I don't think we're going to end up with too many performance-critical pieces in the bytecode. (Arguably it's just the bytecode itself, the symbols, and the constants, as the rest are looked at under exceptional circumstances or on (rare) demand) *No* This really kills extendability, or makes it at least very ugly. It needs to prealloc a certain number of segments. No, it doesn't. It needs to preallocate a few entries in the TOC at the start of the chunk, but that's it. Not that much waste, even if some of the metadata's in the TOC. The point is to have a file format that does what we need it to--present executable bytecode data to the interpreter--as fast as possible. Everything else is secondary to that. The rest of the metadata's needed, so it's there, but access to it doesn't need to be as fast. Yes, it'll only be a few microseconds, but it's a few microseconds versus a few bytes in the file. Disk space is less dear than cycles. Each of this has a fixed semantic. Extending means consuming on of the preallocated fields, or using some segment beyond the preallocated area but then it needs a type field. In fact the preallocated segments also have a type-field: the position in the packfile. I'm fine with a numeric type for the core, and have some extension type with named types if it is a speed issue, but I really dont like this positional approach. BTW: COFF and ELF use named sections. Sure, but bell-bottoms are in, people drink absinthe, and there are folks that do street luge in San Francisco. Just because it's done by other systems doesn't make it the right answer. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Parrot 0.0.9
On Tue, 2002-10-29 at 11:48, Brent Dax wrote: > [EMAIL PROTECTED]: > # > Well, on thinking a bit about this, there's no reason that > # we have to > # > worry--it's perfectly OK for us to declare, unconditionally, that > # > segment 0 is always bytecode, 1 line number info, and so on, with > # > everything after position X (for some value of X) left up > # in the air. > # > A bit dodgy, true, as it means that any new known segment > # types we add > # > in will be floating, but I don't think we're going to end > # up with too > # > many performance-critical pieces in the bytecode. (Arguably > # it's just > # > the bytecode itself, the symbols, and the constants, as the > # rest are > # > looked at under exceptional circumstances or on (rare) demand) > # > # *No* > # > # This really kills extendability, or makes it at least very > # ugly. It needs to prealloc a certain number of segments. Each > # of this has a fixed semantic. Extending means consuming on of > # the preallocated fields, or using some segment beyond the > # preallocated area but then it needs a type field. In fact the > # preallocated segments also have a > # type-field: the position in the packfile. > > How about this structure: > > HEADER > SEGMENT 0 > CHUNK 0 (DIRECTORY) > SIZE: > DATA: > CHUNK 0 ENTRY > TYPE: DIRECTORY (type 0) > OFFSET: Is this really necessary? Seems like a chicken-and-egg thing: to know which chuck the directory is in, you need to read the directory. However, since you've defined that the first chunk (0) is always the directory, there's really no need to have it in the directory since you know it has to be the first chunk. Out of curiosity, would I need a separate segments if I was going to have multiple versions of the program (say, one debugging and one optimized) in the same file? It looks that way. Will the segment/chunk ids's be consistent between builds & how do I know what they will be in advance (for dynamically loading the 'debugging' version on demand) ? Brian
RE: Parrot 0.0.9
brian wheeler:
# Is this really necessary? Seems like a chicken-and-egg
# thing: to know which chuck the directory is in, you need to
# read the directory.
# However, since you've defined that the first chunk (0) is
# always the directory, there's really no need to have it in
# the directory since you know it has to be the first chunk.
It's essentially there as padding, so that you can do
directory->entries[chunkid] to get the entry for chunkid.
# Out of curiosity, would I need a separate segments if I was
# going to have multiple versions of the program (say, one
# debugging and one
# optimized) in the same file? It looks that way. Will the
# segment/chunk ids's be consistent between builds & how do I
# know what they will be in advance (for dynamically loading
# the 'debugging' version on demand) ?
*shrugs* Dan's the one who thinks multiple segments are important, not
me. :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: Draft sketch of bytecode generation
On Monday 28 October 2002 13:02, Dan Sugalski wrote: > At 1:08 PM -0800 10/27/02, chromatic wrote: > >Is there an underlying function used to add arbitrary (Unicode text) > > metadata to the bytecode? > Arbitrary metadata? Nope, no plans for that. While I can see it as a > useful thing (though it wouldn't be unicode, at least unicode > wouldn't be required) I'm not sure it's worth the time to define, > implement, and maintain. > On the other hand, if someone has a good proposal, clean API, and > generally feels strongly about it I certainly won't have any > objections. I'd really like to be able to save comments from source files as metadata. This has at least two potential benefits. First, it makes it much easier to recreate the whole file from bytecode (especially refactored bytecode). Second, it makes it possible to pull out method documentation in the Smalltalk or Python sense. Maybe metadata's not the place for this, but it seems rather natural to me. -- c
RE: [perl #18127] [PATCH] Implicit stack direction probe
Dan Sugalski wrote: > Leopold Toetsch wrote: > > > > Can we really have e.g. odd aligned PMCs on stack? > > the specs are available *somewhere*, and we should see > about digging them up and getting a final answer one way > or another. A gold mine of cpu specs: http://www.mit.edu/afs/sipb/contrib/doc/specs/ic/cpu/ Intel Architecture Software Development Manual - Volume 1: Basic Architecture http://www.mit.edu/afs/sipb/contrib/doc/specs/ic/cpu/x86/iapx-v1.pdf Chapter 4.2.2 Stack Alignment The stack pointer for a stack segment should be aligned on 16-bit (word) or 32-bit (double-word) boundaries, depending on the width of the stack segment. The D flag in the segment descriptor for the current code segment sets the stack-segment width (refer to Chapter 3, Protected-Mode Memory Managementof the Intel Architecture Software Developer's Manual, Volume 3). The PUSH and POP instructions use the D flag to determine how much to decrement or increment the stack pointer on a push or pop operation, respectively. When the stack width is 16 bits, the stack pointer is incremented or decremented in 16-bit increments; when the width is 32 bits, the stack pointer is incremented or decremented in 32-bit increments. The processor does not check stack pointer alignment. It is the responsibility of the programs, tasks, and system procedures running on the processor to maintain proper alignment of stack pointers. Misaligning a stack pointer can cause serious performance degradation and in some instances program failures. And also interesting: http://research.microsoft.com/users/jch/fftw-performance.html Tuning 64-bit floating point code on x86 using gcc, Visual C, and Intel C compilers -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Copyright notices and license stuff
On Tue, Oct 29, 2002 at 05:18:53AM -0800, James Michael DuPont wrote: > > The gcc interface project has been offically restarted. > http://gcc.gnu.org/ml/gcc/2002-10/msg00806.html Congratulations. I think it's an important project. Tim.
Re: [perl #18127] [PATCH] Implicit stack direction probe
On Tue, Oct 29, 2002 at 12:17:55PM -0600, Garrett Goebel wrote: > Dan Sugalski wrote: > > Leopold Toetsch wrote: > > > > > > Can we really have e.g. odd aligned PMCs on stack? > > > > the specs are available *somewhere*, and we should see > > about digging them up and getting a final answer one way > > or another. The system V ABI for IA-32(32-bit x86) does not specify how a compiler should align local variables on the stack. There are ABI rules for aligning structure members, and variables passed between functions, but both Visual C++ and gcc allow the programmer to request packing of structures which ignores these rules. By default both compilers align stack variables at their natural alignment, so PMC pointers would normally fall on 4 byte boundaries. However, it is also possible that someone might save a PMC pointer to an unaligned address on the stack (I can't imagine why). We could always say "don't do that!" for performance reasons. -- Jason
Re: [perl #16077] 'assign' opcode and unmorphing
On Aug-08, Peter Gibbs wrote: > # New Ticket Created by Peter Gibbs > # Please include the string: [perl #16077] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=16077 > > > > Attached patch implements Dan's new 'assign Px,Py' opcode, which basically > does Px->vtable->set_pmc(Py). > > set_pmc has been implemented in perlundef, perlint, perlnum, perlstring > > Also, all changes of destination vtables have been removed from the above > vtable - PMCs of those four types now retain their types permanently. > > This required some significant alterations to pmc.t, as a lot of the tests > assumed that PMCs would morph themselves. A test for 'assign' for > the supported PMC types has also been added to pmc.t. > > PerlUndef now silently ignores all set operations, much as the Perl5 'undef' > does when used as an lvalue. This could also be a singleton PMC ?? I applied the safe bits of this patch. The semantics of this are still being hashed out. I will tag this in RT as applied, but not resolved.
