Re: On JITs and regexps (was several threads)

[Daniel Grunblatt]

On Tue, 30 Jul 2002, Nicholas Clark wrote:

> On Tue, Jul 30, 2002 at 01:21:30PM -0400, 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 it does is implement the end
> > >and noop ops.
> > >> Everything else is being called. Interestingly, JITing like this is
> > >> slower
> > >> than computed goto:
> > >
> > >Yes, function calls are generally slower than computing a goto.
> >
> > Yup. There's the function preamble and postamble that get executed,
> > which can slow things down relative to computed goto, which doesn't
> > have to execute them.
> >
> > This brings up an interesting point. Should we consider making at
> > least some of the smaller utility functions JITtable? Not the opcode
> > functions, but things in string.c or pmc.c perhaps. (Or maybe getting
> > them inlined would be sufficient for us)
>
> I'm not sure. Effectively we'd need to define them well enough that we
> can support n parallel implementations - 1 in C for "everyone else", and
> 1 per JIT architecture.
>
> On Tue, Jul 30, 2002 at 03:14:48PM -0300, Daniel Grunblatt wrote:
> > Yes, we can do that, we can also try to go in and out from the computed
> > goto core if available.
>
> This sounds rather scary to me.

We can try and see, I'm not 100% sure if this will be faster.

>
>
> I've managed to delete a message (I think by Simon Cozens) which said
> that perl5 used to have a good speed advantage over the competition,
> but they'd all been adding optimisations to their regexp engines (that
> we had already)
> and now they're as fast.
>
>
> My thoughts are:
>
> If on a particular platform we don't have a JIT implementation for a
> particular op then we have to JIT a call to that op's C implementation.
> Do enough of these (what proportion?) and the computed goto core is faster
> than the JIT.
> I think (I could look at the source code, but that would break a fine Usenet
> tradition) that for ops not in the computed goto core we have to make a call
> from either JIT or computed goto core, so there's no speed difference on them.
>
> *BUG* Also, we are currently failing to distinguish the size of INTVALs
> and NUMVALs in our JIT names (so this makes 4 possible JIT variants on most
> CPUs)
>
> IIRC there are currently >500 ops in the core, which makes it unlikely that
> we'll have sufficient people to JIT most ops on most CPUs. So we have the
> danger of the JIT being slower in the general case.

Ok, I don't know if I should say this ... and I'm not saying I'm going to
do it, but there is a possibility to make an intermediate language.

Daniel Grunblatt.

Re: ARM Jit v2

[Daniel Grunblatt]

On Thu, 1 Aug 2002, Nicholas Clark wrote:

> Here goes. This *isn't* functional - it's the least amount of work I could
> get away with (before midnight) that gets the inner loop of mops.pasm JITted.
>

Applied, many many thanks.

> including this judicious bit of cheating:
> because I need if_i_ic JITted but mops only needs backwards jumps (which are
> easy, and don't require me to write the fixup routine yet)

We can wait, no problem.

Daniel Grunblatt.

[perl #15929] [no subject]

[via RT]

# New Ticket Created by  The RT System itself 
# Please include the string:  [perl #15929]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=15929 >

packfile tests?

[Jarkko Hietaniemi]

I can't off-hand see tests that would try to read in and execute
bytecode written all possible combinations of wordsize/byteorder?

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: negative index in arrays

[Graham Barr]

On Thu, Aug 01, 2002 at 05:42:12PM -0400, Dan Sugalski wrote:
> At 10:24 PM +0100 8/1/02, Graham Barr wrote:
> >On Thu, Aug 01, 2002 at 02:11:27PM -0700, Stephen Rawls wrote:
> >>  > It should pass them on to the PMC directly, which
> >>  > should then handle  them properly.
> >>
> >>  So, if ix < -SELF->cache.int_val then the code tries
> >>  to use a negative value to access the array element in
> >>  the C code.  This is obviously wrong.  My question is
> >>  should this raise an internal exception, or should
> >>  there be some DWIMery inside PerlArray.pmc.
> >
> >Well in perl today.
> >
> >  print $a[-2];
> >
> >just gives undef and @a is unchanged
> >
> >   $a[-2] = 1;
> >
> >dies with
> >
> >Modification of non-creatable array value attempted, subscript -2 at 
> >-e line 1.
> >
> >But it seems to me that parrot has not concept of lvalue/rvalue use
> >when fetching an element from an aggregate.
> 
> Not with fetching, no.

Hm, That may result in arrays being extended unnecessarily, which
would also be a change in semantics, or array access for rvalues
being multiple ops, checking the array length first.

> The second example would be something like:
> 
> set P0[-2], 1
> 
> in assembly.

Right, which would raise an exception if the array had less than 2 elements.

Graham.

Re: negative index in arrays

[Dan Sugalski]

At 2:54 PM -0700 8/1/02, Sean O'Rourke wrote:
>On Thu, 1 Aug 2002, Dan Sugalski wrote:
>>  No, I don't think this is appropriate. The PerlArray class implements
>>  Perl arrays, and should implement their semantics.
>
>It implements Perl 6 arrays, though.  If it's a useful semantic extension
>(restrictions are another matter), I don't see why "perl 5 doesn't do it"
>is a reason to leave it out.

Oh, "Perl 5 doesn't do it" is a lousy reason. "Perl 6 doesn't do it" 
however is. So... Larry? Semantic call for you on the white courtesy 
telephone!
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: On writing JITs

[Dan Sugalski]

At 9:42 PM +0100 8/1/02, Nicholas Clark wrote:
>Am I allowed to write ancillary functions I want the JIT to call in
>assembler? I presume that the JIT needs to go fast, and I suspect that there
>are some bits that are easier to write in assembler (eg rotates for figuring
>out constants) than in C, for the same amount of eventual speed.
>
>I guess it comes down to, are we assuming that the JIT always be run on the
>CPU which is is targeting? I suspect the answer ought to be "avoid the
>special case" and so the answer to my original question should be "no, make
>the JIT portable"

It's the JIT--evil things for speed reasons are almost obligatory. :)

Sure, go ahead and write whatever you want in assembler for the 
target platform. Just make sure that you'll assemble on that 
platform, and we'll be fine.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: negative index in arrays

[Dan Sugalski]

At 10:24 PM +0100 8/1/02, Graham Barr wrote:
>On Thu, Aug 01, 2002 at 02:11:27PM -0700, Stephen Rawls wrote:
>>  > It should pass them on to the PMC directly, which
>>  > should then handle  them properly.
>>
>>  So, if ix < -SELF->cache.int_val then the code tries
>>  to use a negative value to access the array element in
>>  the C code.  This is obviously wrong.  My question is
>>  should this raise an internal exception, or should
>>  there be some DWIMery inside PerlArray.pmc.
>
>Well in perl today.
>
>  print $a[-2];
>
>just gives undef and @a is unchanged
>
>   $a[-2] = 1;
>
>dies with
>
>Modification of non-creatable array value attempted, subscript -2 at 
>-e line 1.
>
>But it seems to me that parrot has not concept of lvalue/rvalue use
>when fetching an element from an aggregate.

Not with fetching, no. The second example would be something like:

set P0[-2], 1

in assembly.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: negative index in arrays

[Stephen Rawls]

--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> [snip]
> No, I don't think this is appropriate. The PerlArray
> class implements 
> Perl arrays, and should implement their semantics.

Let me rephrase again :)  What should the semantics
for Perl arrays be?

cheers,
Stephen Rawls

__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: negative index in arrays

[Sean O'Rourke]

On Thu, 1 Aug 2002, Dan Sugalski wrote:
> No, I don't think this is appropriate. The PerlArray class implements
> Perl arrays, and should implement their semantics.

It implements Perl 6 arrays, though.  If it's a useful semantic extension
(restrictions are another matter), I don't see why "perl 5 doesn't do it"
is a reason to leave it out.

/s

Re: negative index in arrays

[Dan Sugalski]

At 2:32 PM -0700 8/1/02, Stephen Rawls wrote:
>--- Sean O'Rourke <[EMAIL PROTECTED]> wrote:
>>  > Let me rephrase.  How should the PerlArray pmc
>>  > handle negative indecis when the absolute value of
>>  > the index is greater than the size of the array.
>>
>>  IMHO it would be most consistent with the way
>>  autovivification of positive indices works to extend
>>  the array to the left and set the first element,
>e.g.
>>
>>  @a = (1);
>>  @a[-3] = 2;
>>  # @a == (2, undef, 1)
>>
>
>Hmmm.  I hadn't even thought about expanding left and
>shifting everything else right. I like your way, so
>... if that's what everyone wants, I'll try my hand at
>a patch.

No, I don't think this is appropriate. The PerlArray class implements 
Perl arrays, and should implement their semantics.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: negative index in arrays

[Stephen Rawls]

--- Sean O'Rourke <[EMAIL PROTECTED]> wrote:
> > Let me rephrase.  How should the PerlArray pmc
> > handle negative indecis when the absolute value of
> > the index is greater than the size of the array.
> 
> IMHO it would be most consistent with the way
> autovivification of positive indices works to extend
> the array to the left and set the first element,
e.g.
> 
> @a = (1);
> @a[-3] = 2;
> # @a == (2, undef, 1)
> 

Hmmm.  I hadn't even thought about expanding left and
shifting everything else right. I like your way, so
 if that's what everyone wants, I'll try my hand at
a patch.

cheers,
Stephen Rawls

__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: negative index in arrays

[Graham Barr]

On Thu, Aug 01, 2002 at 02:11:27PM -0700, Stephen Rawls wrote:
> > It should pass them on to the PMC directly, which
> > should then handle  them properly.
> 
> So, if ix < -SELF->cache.int_val then the code tries
> to use a negative value to access the array element in
> the C code.  This is obviously wrong.  My question is
> should this raise an internal exception, or should
> there be some DWIMery inside PerlArray.pmc.

Well in perl today.

 print $a[-2];

just gives undef and @a is unchanged

  $a[-2] = 1;

dies with

Modification of non-creatable array value attempted, subscript -2 at -e line 1.

But it seems to me that parrot has not concept of lvalue/rvalue use
when fetching an element from an aggregate.

Graham.

On writing JITs

[Nicholas Clark]

Am I allowed to write ancillary functions I want the JIT to call in
assembler? I presume that the JIT needs to go fast, and I suspect that there
are some bits that are easier to write in assembler (eg rotates for figuring
out constants) than in C, for the same amount of eventual speed.

I guess it comes down to, are we assuming that the JIT always be run on the
CPU which is is targeting? I suspect the answer ought to be "avoid the
special case" and so the answer to my original question should be "no, make
the JIT portable"

Nicholas Clark
-- 
Even better than the real thing:http://nms-cgi.sourceforge.net/

Re: [perl #15922] [PATCH] jit documentatiion + tweaks

[Nicholas Clark]

On Thu, Aug 01, 2002 at 03:05:11PM +, Jason Gloudon wrote:
> More Revisions of jit.doc as well as some more overview comments on the SPARC
> jit approach. Also included is a change to the way interpreter functions are
> invoked on x86. This uses the fact that the interpreter argument remains
> unchanged on the stack to avoid pushing it every time.

Does that get you more MOPS on the same machine?
We want figures! Even if they are of no real meaning. :-)

Nicholas Clark
-- 
Even better than the real thing:http://nms-cgi.sourceforge.net/

Re: negative index in arrays

[Sean O'Rourke]

On Thu, 1 Aug 2002, Stephen Rawls wrote:

> > It should pass them on to the PMC directly, which
> > should then handle  them properly.
>
> Let me rephrase.  How should the PerlArray pmc handle
> negative indecis when the absolute value of the index
> is greater than the size of the array.

IMHO it would be most consistent with the way autovivification of
positive indices works to extend the array to the left and set the first
element, e.g.

@a = (1);
@a[-3] = 2;
# @a == (2, undef, 1)

Perl 5 says this is a "modification of a non-creatable array value",
though.

/s

Re: negative index in arrays

[Stephen Rawls]

> It should pass them on to the PMC directly, which
> should then handle  them properly.

Let me rephrase.  How should the PerlArray pmc handle
negative indecis when the absolute value of the index
is greater than the size of the array.  Here are some
examples:
#first set up an array
 new P0, .Perl Array
 set P0, 3

 set P0[0], 1
 set P0[1], 2
 set P0[2], 3
#now, what do these accesses produce?
P0[-1] => P0[2] => 3
P0[-3] => P0[0] => 1
P0[-5] => ?
here's my take on how to DTRT
-5 + 3 = -2, -2 + 3 = 1, so
P0[-5] => P0[1] => 2

Like I said in the earlier message, this would only
need the 'if's changed to 'while's to work.  But,
right now the PerlArray.pmc code does this:

if (ix < 0) ix += SELF->cache.int_val

So, if ix < -SELF->cache.int_val then the code tries
to use a negative value to access the array element in
the C code.  This is obviously wrong.  My question is
should this raise an internal exception, or should
there be some DWIMery inside PerlArray.pmc.

cheers,
Stephen Rawls

__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [perl #15927] [PATCH] perlarray clone

[Dan Sugalski]

At 7:59 PM + 8/1/02, Leopold Toetsch (via RT) wrote:
>So patch seems ok, but propably needs more tests in t/pmc.

Applied. Could you come up with some tests?
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: resize_array (PerlArray)

[Dan Sugalski]

At 9:04 PM +0100 8/1/02, Graham Barr wrote:
>On Thu, Aug 01, 2002 at 03:42:19PM -0400, Dan Sugalski wrote:
>>  At 5:28 PM +0200 8/1/02, Aldo Calpini wrote:
>>  >fetching an element out of bound changes the
>>  >length of the array. but should this really happen?
>>  >why does perlarray.pmc act like this:
>>
>>  Because that's the way Perl's arrays work. Joys of autovivification.
>
>Only if the element fetched is being used in an lvalue context.
>
>Just reading an array element will result in undef and no change to the array
>internals

Good point. Read shouldn't extend, write should.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

[perl #15927] [PATCH] perlarray clone

[via RT]

# New Ticket Created by  Leopold Toetsch 
# Please include the string:  [perl #15927]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=15927 >


Hi

I'm not totally sure, if it's the correct way to go, but it works ;-)

I did a test (with a slightly patched P6C, which clones @a = @b).

$ cat d.p6
sub main() {
   my @a = ("x ","y ","z ");
   my @b = @a;
   @a[2] = "2 ";
   @b[0] = "0 ";
   print @a, @b, "\n";
}

$ perl6 -g d.p6 --keep-imc
x y 2 0 y z

(without patch: 0 y 2 0 y 2 )

and from d.imc
#line 3 "d.p6"
# my @b = @a;
 _AV_b1 = clone _AV_a1

So patch seems ok, but propably needs more tests in t/pmc.

leo


-- attachment  1 --
url: http://rt.perl.org/rt2/attach/32597/26897/6446d3/perlarray.pmc.diff



--- parrot/classes/perlarray.pmcTue Jul 30 18:36:11 2002
+++ parrot-007/classes/perlarray.pmcThu Aug  1 18:19:12 2002
@@ -78,8 +78,28 @@
 }
 
 PMC* clone () { 
-/* XXX */
-return NULL;
+PMC* dest;
+INTVAL ix, size;
+PMC* element;
+PMC** array;
+
+dest = pmc_new(INTERP, enum_class_PerlArray);
+dest->vtable = SELF->vtable;
+   dest->vtable->init(interpreter, dest);
+   size = SELF->cache.int_val;
+   resize_array(interpreter, dest, size);
+   for (ix = 0; ix < size; ix++) {
+   PMC *new;
+   array = ((Buffer *) SELF->data)->bufstart;
+   element = array[ix];
+
+   if (element) {
+   new = element->vtable->clone(interpreter, element);
+   ((PMC**)((Buffer *) dest->data)->bufstart)[ix] = new;
+   }
+
+   }
+return dest;
 }
 
 INTVAL get_integer () {

Re: resize_array (PerlArray)

[Graham Barr]

On Thu, Aug 01, 2002 at 03:42:19PM -0400, Dan Sugalski wrote:
> At 5:28 PM +0200 8/1/02, Aldo Calpini wrote:
> >fetching an element out of bound changes the
> >length of the array. but should this really happen?
> >why does perlarray.pmc act like this:
> 
> Because that's the way Perl's arrays work. Joys of autovivification.

Only if the element fetched is being used in an lvalue context.

Just reading an array element will result in undef and no change to the array
internals

Graham.

Re: [perl #15922] [PATCH] jit documentatiion + tweaks

[Dan Sugalski]

At 3:48 PM -0400 8/1/02, Jason Gloudon wrote:
>Duh. Here's a unified diff.

Thanks, it's in.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: [perl #15922] [PATCH] jit documentatiion + tweaks

[Jason Gloudon]

Duh. Here's a unified diff.

-- 
Jason


Index: docs/jit.pod
===
RCS file: /cvs/public/parrot/docs/jit.pod,v
retrieving revision 1.4
diff -u -r1.4 jit.pod
--- docs/jit.pod29 Jul 2002 21:13:38 -  1.4
+++ docs/jit.pod1 Aug 2002 19:46:23 -
@@ -73,7 +73,9 @@
 =item jit/${jitcpuarch}/core.jit
 
 The functions to generate native code for core parrot opcodes are specified
-here.
+here. To simplify the maintenance of these functions, they are specified in a
+format that is pre-processed by B to produce a valid C source file,
+B. See L below.
 
 =item jit/${jitcpuarch}/string.jit
 
@@ -116,7 +118,7 @@
  
 =item jit2h.pl
 
-Reads the .jit files and prints the struct opcode_assembly_t.
+Preprocesses the .jit files to produce and prints the struct opcode_assembly_t.
 
 =back
 
@@ -129,12 +131,18 @@
 
 =item I { I }
 
-Where I is the name of the Parrot opcode, and I consists
-of a sequence of the following forms:
-
-=item Assembly instruction.
-
-Which may have one of this B as an argument: 
+Where I is the name of the Parrot opcode, and I consists of C
+syntax code which may contain any of the identifiers listed in the following
+section.
+
+=item Identifiers
+
+In general, prefixing an identifier with I<&> yields the address of the
+referenced Parrot register or constant.  If an identifier is given without a
+prefix, the value is returned by default.   To emphasis the use of the value,
+the I<*> prefix may be used.  Since Parrot register values vary during code
+execution, their values can not be obtained through identifier substitution
+alone.
 
 B
 
@@ -207,8 +215,6 @@
 B
 
 Gets replaced by the Ith temporary char array.
-
-You must preside all the identifiers with I<&> requesting the address of that 
identifier, or I<*> requesting the value, I<*> can be used only with constants since 
the replacement is done before start running.
 
 B<&INTERPRETER[n]>
 
Index: jit/i386/core.jit
===
RCS file: /cvs/public/parrot/jit/i386/core.jit,v
retrieving revision 1.20
diff -u -r1.20 core.jit
--- jit/i386/core.jit   5 Jul 2002 11:15:42 -   1.20
+++ jit/i386/core.jit   1 Aug 2002 19:46:23 -
@@ -5,7 +5,9 @@
 ;
 
 Parrot_end {
+emitm_addl_i_r(jit_info->native_ptr, 4, emit_ESP);
 NATIVECODE = emit_popl_r(NATIVECODE, emit_ESI);
+NATIVECODE = emit_popl_r(NATIVECODE, emit_EBP);
 emitm_ret(NATIVECODE);
 }
 
Index: jit/i386/jit_emit.h
===
RCS file: /cvs/public/parrot/jit/i386/jit_emit.h,v
retrieving revision 1.4
diff -u -r1.4 jit_emit.h
--- jit/i386/jit_emit.h 5 Jul 2002 11:11:09 -   1.4
+++ jit/i386/jit_emit.h 1 Aug 2002 19:46:24 -
@@ -98,7 +98,7 @@
 break;
 default :
 internal_exception(JIT_ERROR, "Invalid scale factor %d\n", scale);
-break;
+return;
 }
 
 *pc = scale_byte | (i == emit_None ? emit_Index_None : emit_reg_Index(i)) |
@@ -108,8 +108,8 @@
 static char *emit_r_X(char *pc, int reg_opcode, int base, int i, int scale,
 long disp)
 {
-if((i && !scale) || (scale && !i)){
-internal_exception(JIT_ERROR,
+if(i && !scale){
+internal_exception(JIT_ERROR,
 "emit_r_X passed invalid scale+index combo\n");
 }
 
@@ -341,6 +341,8 @@
 
 #define emitm_alul_i_r(pc, op1, op2, imm, reg) { *(pc++) = op1; *(pc++) = 
emit_alu_X_r(op2, reg); *(long *)((pc)) = (long)(imm); (pc) += 4; }
 
+#define emitm_alub_i_r(pc, op1, op2, imm, reg) { *(pc++) = op1; *(pc++) = 
+emit_alu_X_r(op2, reg); *(pc++) = (char)(imm); }
+
 #define emitm_alul_i_m(pc, op1, op2, imm, b, i, s, d) { \
  *(pc++) = op1; \
  (pc) = emit_r_X(pc, emit_reg(op2), b, i, s, d); \
@@ -366,6 +368,8 @@
 /* ADDs */
 
 #define emitm_addb_r_r(pc, reg1, reg2) emitm_alul_r_r(pc, 0x00, reg1, reg2)
+#define emitm_addb_i_r(pc, imm, reg)   emitm_alub_i_r(pc, 0x83, emit_b000, imm, reg)
+
 #define emitm_addl_r_r(pc, reg1, reg2) emitm_alul_r_r(pc, 0x01, reg1, reg2)
 #define emitm_addl_i_r(pc, imm, reg)   emitm_alul_i_r(pc, 0x81, emit_b000, imm, reg)
 #define emitm_addl_r_m(pc, reg, b, i, s, d) emitm_alul_r_m(pc, 0x01, reg, b, i, s, d)
@@ -667,14 +671,25 @@
 void Parrot_jit_begin(Parrot_jit_info *jit_info,
   struct Parrot_Interp * interpreter)
 {
+/* Maintain the stack frame pointer for the sake of gdb */
+jit_info->native_ptr = emit_pushl_r(jit_info->native_ptr, emit_EBP);
+emitm_movl_r_r(jit_info->native_ptr, emit_ESP, emit_EBP);
+
+/* Save ESI, as it's value is clobbered by jit_cpcf_op */
 jit_info->native_ptr = emit_pushl_r(jit_info->native_ptr, emit_ESI);
+
+/* Cheat on op function calls by writing the interpreter arg on the stack
+ * just once. If an op function ever modifies the interpreter argument on
+ * the stack this will stop working !!! */
+emitm_pushl_i

Re: maybe-PATCH: sub/continuation/dlsym/coroutine clean-up

[Dan Sugalski]

At 12:34 PM -0700 8/1/02, Sean O'Rourke wrote:
>On 1 Aug 2002, Jonathan Sillito wrote:
>  > sub it is dealing with. While I am thinking about it, would it make
>>  sense to distinguish between a sub and a closure? A sub would be a
>>  little more efficient in cases where a closure is not needed.
>
>Closures aren't really that much more expensive than subs -- just an extra
>hash (or whatever) for lexicals.  And while I could be wrong, I think that
>subs will _always_ be closures.

More or less always, yeah, at least for perl. It's tough to have a 
sub that's not a closure.

>  > > - not integrated with lexicals.  Parrot is a fast-moving target nowadays!
>>
>>  Current discussion on the list makes me wonder if this is still up in
>>  the air a bit. However I would be happy work on this, once I feel like I
>>  understand what the consensus is for lexicals ...
>
>Great.  I'm as much in the dark consensus-wise as you are, if not more so.
>I suspect it will come down to a tug-of-war between introspective power
>(e.g. %MY, caller, etc) and interpreter speed (I'm biased toward the
>former).

Joys of engineering. I'll get a position doc out soonish.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: resize_array (PerlArray)

[Dan Sugalski]

At 5:28 PM +0200 8/1/02, Aldo Calpini wrote:
>fetching an element out of bound changes the
>length of the array. but should this really happen?
>why does perlarray.pmc act like this:

Because that's the way Perl's arrays work. Joys of autovivification.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: [perl #15922] [PATCH] jit documentatiion + tweaks

[Dan Sugalski]

At 3:05 PM + 8/1/02, Jason Gloudon (via RT) wrote:
>More Revisions of jit.doc as well as some more overview comments on the SPARC
>jit approach. Also included is a change to the way interpreter functions are
>invoked on x86. This uses the fact that the interpreter argument remains
>unchanged on the stack to avoid pushing it every time.

Cool. Could we have it as a -u or -c diff, though? Patch likes those 
much better.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: negative index in arrays

[Dan Sugalski]

At 6:46 AM -0700 8/1/02, Stephen Rawls wrote:
>In working on the Tuple pmc (almost done!) I've come
>accross a small semantic problem.  I suppose this
>might be language level (and thus Larry's turf?), but
>how should the VM handle negative indecis?

It should pass them on to the PMC directly, which should then handle 
them properly.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: [perl #15920] [PATCH] squash IRIX warning (resubmit)

[Dan Sugalski]

At 12:20 PM + 8/1/02, Jarkko Hietaniemi (via RT) wrote:
>IRIX found another return missing from a non-void function.

Thanks, applied.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: maybe-PATCH: sub/continuation/dlsym/coroutine clean-up

[Sean O'Rourke]

On 1 Aug 2002, Jonathan Sillito wrote:

> Looks good to me. Couple of quick things, when I applied the patch
> locally, it indented the end bracket of the invoke op in core.ops which
> breaks ops2c.pl.

That's a bug.

> Also the patch removed the yield op from core.ops, was this
> intentional? More comments below.

Yes.  Yield becomes a special case of invoke.

> sub it is dealing with. While I am thinking about it, would it make
> sense to distinguish between a sub and a closure? A sub would be a
> little more efficient in cases where a closure is not needed.

Closures aren't really that much more expensive than subs -- just an extra
hash (or whatever) for lexicals.  And while I could be wrong, I think that
subs will _always_ be closures.

> > - not integrated with lexicals.  Parrot is a fast-moving target nowadays!
>
> Current discussion on the list makes me wonder if this is still up in
> the air a bit. However I would be happy work on this, once I feel like I
> understand what the consensus is for lexicals ...

Great.  I'm as much in the dark consensus-wise as you are, if not more so.
I suspect it will come down to a tug-of-war between introspective power
(e.g. %MY, caller, etc) and interpreter speed (I'm biased toward the
former).

/s

Re: parrot "press"

[Will Coleda]

Will Coleda wrote:
> Sean O'Rourke wrote:
> 
>> A bit of Parrot bloggage where I didn't expect it
>>
>> http://lambda.weblogs.com/discuss/msgReader$3850
> 
> 
> This includes a link to:
> 
> http://www.oreilly.com/parrot//
> 
> Which appears to be a leftover from the April Fool's joke. Except the 
> article doesn't seem to realize it's a joke.
> 

*sigh*

Which everyone who bothered to scroll down to the bottom of the page 
already realized they realized. =-)

I'm going back to sleep. =-)

Re: parrot "press"

[Will Coleda]

Sean O'Rourke wrote:
> A bit of Parrot bloggage where I didn't expect it
> 
> http://lambda.weblogs.com/discuss/msgReader$3850

This includes a link to:

http://www.oreilly.com/parrot//

Which appears to be a leftover from the April Fool's joke. Except the 
article doesn't seem to realize it's a joke.

Re: [perl #15919] [PATCH] make IRIX and UNICOS/mk happy (resubmit)

[Dan Sugalski]

At 12:19 PM + 8/1/02, Jarkko Hietaniemi (via RT) wrote:
>This fixes [perl #15865] and [perl #15870].  I never saw this in p6i
>(eaten by hungry spamfilters?), and the RT does not like me for some
>reason so I can't see whether it got filed under #15865.

Applied, thanks.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re[2]: [perl #15904] Configure broken on windows 9x

[Mattia Barbon]

On Thu, 1 Aug 2002 16:50:25 +0200 Aldo Calpini <[EMAIL PROTECTED]> wrote:

> Mr. Nobody wrote:
> > The windows 9x command.com shell dosen't recognize
> > 2>&1 so it ends up passing "2" as an argument to the
> > compiler, which fails because there's no such file.
> 
> this is no news. you can't even build Perl on 9x.
> IMHO, *build* platform targets should not include 9x.
> build it on NT/2000/XP and then feel free to use the
> binary on 9x (as Perl actually does).
Perl 5.8.0 almost builds on Win95, command.com, MinGW, dmake.
("almost" means that you need a small patch because MM autputs
 some spaces instead of tabs in makefiles, other than that it builds,
 but hangs in the test suite (it would probably work, too,
 but I use Win95 just to play RayMan, so I don't know...)

Regards
Mattia

Re: Lexical variables, scratchpads, closures, ...

[Dan Sugalski]

At 11:22 PM -0400 7/31/02, Melvin Smith wrote:
>>Conclusion
>>
>>   It seems to me that to implement lexical variables, we only need to
>>   implement the set_pmc method and to extend the Sub class so that it
>>   contains both a code pointer and a scratchpad.
>
>I agree with you. It can be done without special ops that we just added.
>I see no reason why we can't add an op that allows you to get the
>scratchpad into a Px reg and use it just as a Hash or Array. I expect
>we might want to.

I'd rather keep the separate interface to lexicals and globals. 
That'll make it much easier to change the implementation without 
breaking existing bytecode.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: parrot "press"

[jadams01]

On Thu, 1 Aug 2002 11:22:26 -0700 (PDT) Sean O'Rourke <[EMAIL PROTECTED]>
wrote:

> A bit of Parrot bloggage where I didn't expect it

> http://lambda.weblogs.com/discuss/msgReader$3850

I especially liked this part:

"There is a tutorial at the main site and an O'Reilly book available."

The book, of course, is _Programming Parrot_.

 John A

These are my principles. If you don't like them, I have others.
 --Groucho Marx

parrot "press"

[Sean O'Rourke]

A bit of Parrot bloggage where I didn't expect it

http://lambda.weblogs.com/discuss/msgReader$3850

including evidence that the Python folks are not completely dormant:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/sandbox/parrot/

/s

Re: Lexical variables, scratchpads, closures, ...

[Sean O'Rourke]

On Thu, 1 Aug 2002, Melvin Smith wrote:

> Jerome Vouillon writes:
> >On Wed, Jul 31, 2002 at 11:22:56PM -0400, Melvin Smith wrote:
> >> And they need to be COW, as closures have access to their
> >> own copies of lexicals.  I asked Jonathan to reuse the stack code
> >> I had already written because it was using the same semantics
> >> with COW as control and user stacks.
> >
> >I'm confused here.  In Jonathan's code, the stack is COW, not the
> >scratchpads.  If instead of using stacks you make each scratchpad
> >contains a pointer to its parent, there is no need to copy anything:
> >several scratchpads can then share the same parent.
>
> 1) Our stacks are being reworked to be tree-based, so multiple children
>can point to the same parent.

COW is a win when you may be able to avoid copying large amounts of data.
In a world of 4-character indents and 80-column editor windows, I'm not
sure the extra machinery of COW is a win -- an immediate copy of a stack 3
or 4 deep will be fast, and won't take much memory.

/s

Re: PATCH - Allow assemble.pl to read from STDIN

[Dan Sugalski]

At 2:41 AM -0700 8/1/02, Brian Ingerson wrote:
>Hi all,
>
>I'm new to Parrot and Perl6. I hope this is an ok way to submit a patch.
>
>---
>- Allow assemble.pl to read from STDIN
>- Use the '-' symbol to indicate STDIN
>- Made invocation failures/usages behave more correctly
>- Minor refactorings in this code section

Applied, thanks.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Lexical variables, scratchpads, closures, ...

[Sean O'Rourke]

On Thu, 1 Aug 2002, Jerome Vouillon wrote:

> On Wed, Jul 31, 2002 at 11:22:56PM -0400, Melvin Smith wrote:
> > We chose to implement
> > the access as ops, and you prefer using a PMC Array directly. I can
> > at least see one advantage to the explicit ops: they don't require
> > a register to use them in the general case.
>
> [snip]
>
> But I'm especially frightened by opcodes such as new_pad.  The Perl
> compiler may well be able to perform more optimizations if it does not
> use this opcode but rather generate specialized code.

Putting my "amateur compiler writer" hat on for a moment, I'll have to
agree for a couple of reasons.  First, supporting Perl 6's introspective
features (e.g. %MY) is much easier if the internals and language
implementation use the same data structures where practical.  Sure, it's
possible to write some glue code to make a stack act like a PerlArray, but
it's more work, and in this case I'm not sure it's necessary.  There is
the unfortunate fact that all of a sudden the lexical implementation will
be tied to a particular language's PMC's, but this seems like another
reason to push lexicals out of the interpreter core.

Second, I've been playing with implementing lexicals "the right way" in
P6C, and haven't really found new_pad and pop_pad all that useful.  Of
course, I don't have a working implementation yet, and I may be completely
misunderstanding how the ops should be used.  I suspect that getting them
to "do the right thing" would involve adding lex-playing-with code to bsr
and ret, plus maybe a couple more ops.  Plus adding more ops to push
lexical stacks onto the lexical stack-stack (for your Befunge fans ;).

> So, I would feel more comfortable trying to reuse existing opcodes for
> the moment, especially as I don't think we have a clear view of the
> "right" way to implement lexical variables yet.

My naive implementation would have an array of hashes for each sub, with
one entry for each level of scope within.  This is just like the
pad_stack, but implemented using only language features.  (Dynamic)
lexical lookup works its way through this stack.  Static lookups can
probably be resolved to registers, with code inserted to fetch values out
of the pad the first time they are used, and store them back when a scope
is exited.

Returning a closure would make a copy of the scope array, containing
references to the pad hashes (here's where GC makes me happy, and where I
may make the GC unhappy).  So the Sub PMC has a code pointer and a scope
stack pointer, which is either set up automatically when creating a new
Sub, or is accessible as a method.

Another alternative would be single-level pads for each scope containing
all accessible lexicals.  Unfortunately, I think %OUTER and %MY make this
very complicated (or impossible) to get right.

Waving my hands somewhat more quickly, as an optimization, lexicals can
just live in registers when the compiler sees no references to %MY or
closures.  Nastiness like eval and caller.MY can be handled by inserting
fixup code to reconstruct the lexical array on demand.

Hopefully I can get some of this working soon, and put it up on the list
for people to play with and improve.

/s

Re: Lexical variables, scratchpads, closures, ...

[Sean O'Rourke]

On 31 Jul 2002, Jonathan Sillito wrote:
> > > invoke# assumes sub is in P0
> > >   # on invoke the sub pmc fixes the current
> > >   # context to have the correct lexicals
> >
> > Can you elaborate on this?  What is done precisely to fix the current
> > context?
>
> This also is not implemented (unless Sean O'Rourke's recent patch does
> this?) However the Sub (or Coroutine, or Continuation, or ...) PMC could
> have the responsibility of putting the correct context in place before
> actually jumping to the body of the sub. Melvin's code in sub.c has a
> start on this, I think ...

Melvin did have stubs in place to do this, and I've played with it a bit.
The version on the list does not do this, however.

/s

[perl #15925] [PATCH] Configure broken on windows 9x, patch included

[Mr. Nobody]

# New Ticket Created by  "Mr. Nobody" 
# Please include the string:  [perl #15925]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=15925 >


The command.com shell in windows 9x dosen't recognize
2>&1 so it messes up Configure when it starts checking
pointer alignment, this patch fixes it on windows 9x
but it dosen't take out the stderr redirection on
shells that support it.

--- lib/Parrot/Configure/Step.bak   Thu Jul 18 16:59:04
2002
+++ lib/Parrot/Configure/Step.pmThu Aug  1 09:51:54
2002
@@ -16,6 +16,7 @@
gen   => ['genfile']
 );

+my $redir_err = ($ENV{COMSPEC} =~ /command\.com/i) ?
"" : "2>&1";
 
 #Configure::Data->get('key')
 #Configure::Data->set('key', 'value')
@@ -71,9 +72,9 @@
my($cc, $ccflags, $ldout, $o, $ld, $ldflags,
$cc_exe_out, $exe, $libs)=
Configure::Data->get( qw(cc ccflags ld_out o ld
ldflags cc_exe_out exe libs) );

-   system("$cc $ccflags -I./include -c test.c >test.cco
2>&1") and die "C compiler failed (see test.cco)";
+   system("$cc $ccflags -I./include -c test.c >test.cco
$redir_err") and die "C compiler failed (see
test.cco)";

-   system("$ld $ldflags test$o ${cc_exe_out}test$exe
$libs >test.ldo 2>&1") and die "Linker failed (see
test.ldo)";
+   system("$ld $ldflags test$o ${cc_exe_out}test$exe
$libs >test.ldo $redir_err") and die "Linker failed
(see test.ldo)";
 }
 
 sub cc_run {
@@ -89,10 +90,10 @@
 sub cc_run_capture {
my $exe=Configure::Data->get('exe');
 if (defined($_[0]) && length($_[0])) {
-   `./test$exe $_[0] 2>&1`;
+   `./test$exe $_[0] $redir_err`;
 }
 else {
-   `./test$exe 2>&1`;
+   `./test$exe $redir_err`;
 }
 }

__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: Lexical variables, scratchpads, closures, ...

[Melvin Smith]

Jerome Vouillon writes:
>On Wed, Jul 31, 2002 at 11:22:56PM -0400, Melvin Smith wrote:
>> At 06:25 PM 7/31/2002 +0200, Jerome Vouillon wrote:
>> >Closures
>> >
>> >  A subroutine must have access to the scratchpads of all the
>> >  englobing blocks.  As the scratchpads are linked, it is sufficient
>> >  to add a pointer to the immediately englobing scratchpads to the
>> >  closure (Sub class).
>>
>> And they need to be COW, as closures have access to their
>> own copies of lexicals.  I asked Jonathan to reuse the stack code
>> I had already written because it was using the same semantics
>> with COW as control and user stacks.
>
>I'm confused here.  In Jonathan's code, the stack is COW, not the
>scratchpads.  If instead of using stacks you make each scratchpad
>contains a pointer to its parent, there is no need to copy anything:
>several scratchpads can then share the same parent.

1) Our stacks are being reworked to be tree-based, so multiple children
   can point to the same parent.

>By the way, I don't understand how you intend to implement subroutine
>invocation.  Are you going to push the caller scratchpad stack on a

Neither do I, really. :(

-Melvin Smith

IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984

[perl #15923] [PATCH] Matrices for Parrot

[Höök]

# New Ticket Created by  Josef Höök 
# Please include the string:  [perl #15923]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=15923 >



Pjuh after 2 month of work i'm finally finished with a first release.
This patch adds matrices for Parrot. Current code handles dense and sparse
matrices. It also has a general interface that we can use
for multdim arrays ( interested ?:) ). 

Operations available:
transp   Transpose
det  Determinant you can also get determinant value by: 
 set I0, P0 if P0 is a matrix thatis.
ludcmp   ludecomposition needed for inverse, determinant and 
 other operations
plot_matrix 
Operations not yet available but in near future:
 inverse
 Probably some others too. I cant think of anyone right now.

Files included in patch:

matrix_core.cbasic framework.  
matrix.ops
cell.c   this file contains the core logic. 
classes/matrix.pmc   lots of stuff todo here :)
include/parrot/matrix_core.h 
include/parrot/cell.h

Have fun with it.. 

/Josef  


-- attachment  1 --
url: http://rt.perl.org/rt2/attach/32583/26881/9ed7e1/parrot_matrix_020801.patch



diff -urN parrot.orig/MANIFEST parrot/MANIFEST
--- parrot.orig/MANIFESTThu Aug  1 16:49:51 2002
+++ parrot/MANIFEST Thu Aug  1 16:53:12 2002
@@ -12,6 +12,7 @@
 VERSION
 assemble.pl
 byteorder.c
+cell.c
 chartype.c
 chartypes/unicode.c
 chartypes/usascii.c
@@ -20,6 +21,7 @@
 classes/default.pmc
 classes/genclass.pl
 classes/intqueue.pmc
+classes/matrix.pmc
 classes/perlarray.pmc
 classes/perlhash.pmc
 classes/perlint.pmc
@@ -179,6 +181,7 @@
 hash.c
 headers.c
 include/parrot/chartype.h
+include/parrot/cell.h
 include/parrot/debug.h
 include/parrot/dod.h
 include/parrot/embed.h
@@ -193,6 +196,7 @@
 include/parrot/io.h
 include/parrot/jit.h
 include/parrot/key.h
+include/parrot/matrix_core.h
 include/parrot/memory.h
 include/parrot/misc.h
 include/parrot/op.h
@@ -412,6 +416,8 @@
 lib/Text/Balanced.pm
 make.pl
 math.ops
+matrix.ops
+matrix_core.c
 memory.c
 misc.c
 obscure.ops
diff -urN parrot.orig/assemble.pl parrot/assemble.pl
--- parrot.orig/assemble.pl Thu Aug  1 16:49:51 2002
+++ parrot/assemble.pl  Thu Aug  1 16:58:25 2002
@@ -138,6 +138,7 @@
   $self->{constants}{IntQueue} = 8;
   $self->{constants}{Sub} = 9;
   $self->{constants}{Coroutine} = 10;
+  $self->{constants}{Matrix} = 11;
   $self;
 }
 
diff -urN parrot.orig/cell.c parrot/cell.c
--- parrot.orig/cell.c  Thu Jan  1 01:00:00 1970
+++ parrot/cell.c   Thu Aug  1 17:38:02 2002
@@ -0,0 +1,112 @@
+/* cell.c
+ *  Copyright: (When this is determined...it will go here)
+ *  CVS Info
+ *$Id: cell.c,v 1.2 2002/07/18 21:19:49 joh Exp joh $
+ *  Overview:
+ * Represents a cell or a point in multidimensional space
+ * this is used by matrix and hopefully soon also multidimensional arrays.
+ *
+ *  Data Structure and Algorithms:
+ *   This is one way for calculating offsets in 2 dimensional space.
+ *
+ *   (y-1)X0+x   
+ *
+ *   Where X0 is the length of X-base (fig 1.1). We use this equation in 
+ *   calc_offset to get offset from the buffer we store our data in. 
+ *   Lets say we want to store (2,2) in a buffer. We then take values and do:
+ *   (2-1)3 + 2 = 5. 
+ * 
+ *  
+ *  base | 1 | 2 | 3 | 4 |*5*|  | 
+ *  - fig 1.0
+ *
+ *
+ *  Y 
+ *  |  
+ *  | --- 
+ *  | [ 7 ][ 8 ][ 9 ] 
+ *  | [ 4 ][ 5 ][ 6 ] 
+ *  | [ 1 ][ 2 ][ 3 ] < a CELL
+ *  |-- X
+ *|-|   
+ *X0  fig 1.1   
+ *  virtual_addr is the return value from a calculation of CELL's position.
+ *  Changes:  2002/08/01
+ *Our cell_buffer starts from 0 equation is now y*x0+x.
+ *
+ *  Current code has complexity: 
+ *
+ *O(1) writing.  
+ *O(1) reading, worst case O(N).
+ *
+ *  History:
+ *  by Josef Höök. 2002-07-18
+ *
+ *  Notes:
+ *Future plan is to make calc_offset polymorphic 
+ *and to make it handle multidimensions. 
+ *  References:
+ * none yet 
+ */
+
+#include "parrot/parrot.h"
+
+/* 
+ * CALC OFFSET FOR MATRICES 
+ * We always store matrix size at base address
+ * $1 is addr of our CELL_BUFFER structure.
+ * $2 is a key pointer containing positions in 2 dimensional space 
+ */
+INTVAL calc_offs

Re: Lexical variables, scratchpads, closures, ...

[Jerome Vouillon]

On Wed, Jul 31, 2002 at 11:40:39AM -0600, Jonathan Sillito wrote:
> So here is my take on a slightly simpler example:
> 
>   sub foo {
> my $x = 13;
> return sub { print "$x\n"; };
>   }
> 
>   $foo()

Melvin, I think it would really help if you could explain us how you
would compile this code.  Also, you should describe precisely what
"invoke" and "new_pad" (and maybe the other scratchpad-related
opcodes) do as far as scratchpads are concerned.

-- Jerome

Re: Perl 6 Summary for week ending 20020728

[Russ Allbery]

pdcawley <[EMAIL PROTECTED]> writes:

> Bugger, I used L and pod2text broke it.
> http:[EMAIL PROTECTED]/msg10797.html

perlpodspec sez you can't use L<...|...> with a URL, and I'm guessing that
I just didn't look at that case when writing the parsing code in pod2text
because of that.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Lexical variables, scratchpads, closures, ...

[Jerome Vouillon]

On Wed, Jul 31, 2002 at 11:22:56PM -0400, Melvin Smith wrote:
> At 06:25 PM 7/31/2002 +0200, Jerome Vouillon wrote:
> >Closures
> >
> >  A subroutine must have access to the scratchpads of all the
> >  englobing blocks.  As the scratchpads are linked, it is sufficient
> >  to add a pointer to the immediately englobing scratchpads to the
> >  closure (Sub class).
> 
> And they need to be COW, as closures have access to their
> own copies of lexicals.  I asked Jonathan to reuse the stack code
> I had already written because it was using the same semantics
> with COW as control and user stacks.

I'm confused here.  In Jonathan's code, the stack is COW, not the
scratchpads.  If instead of using stacks you make each scratchpad
contains a pointer to its parent, there is no need to copy anything:
several scratchpads can then share the same parent.

By the way, I don't understand how you intend to implement subroutine
invocation.  Are you going to push the caller scratchpad stack on a
stack and replace it by (a copy of) the callee scratchpad stack?

> We chose to implement
> the access as ops, and you prefer using a PMC Array directly. I can
> at least see one advantage to the explicit ops: they don't require
> a register to use them in the general case.

Adding special opcodes has a cost: they then need to be implemented
for all architectures supported by the JIT compiler.

But I'm especially frightened by opcodes such as new_pad.  The Perl
compiler may well be able to perform more optimizations if it does not
use this opcode but rather generate specialized code.  (And the JIT
compiler may then be able to generate some inlined assembly code
instead of a call to a generic C function.)

So, I would feel more comfortable trying to reuse existing opcodes for
the moment, especially as I don't think we have a clear view of the
"right" way to implement lexical variables yet.  It will still be
possible to add new opcodes to improve performances when we have a
working compiler to benchmark them.

-- Jerome

resize_array (PerlArray)

[Aldo Calpini]

take this little assembler program:

new P1, .PerlArray
set P1, 100
bsr GETLEN

set I0, P1[0]
print "P1[0]="
print I0
print "\n"
bsr GETLEN

set I0, P1[1]
print "P1[1]="
print I0
print "\n"  
bsr GETLEN
end

GETLEN:
set I0, P1
print "length="
print I0
print "\n"
ret

it prints:

length=100
P1[0]=0
length=100
P1[1]=0
length=10001

fetching an element out of bound changes the
length of the array. but should this really happen?
why does perlarray.pmc act like this:

if (ix >= SELF->cache.int_val) {
resize_array(interpreter, SELF, ix+1);
}

instead of:

if (ix >= SELF->cache.int_val) {
value = pmc_new(INTERP, enum_class_PerlUndef);
return value->vtable->get_integer(INTERP, value);
}

are there any reason for this that I can't see or does it
just need a patch?

cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;

Re: tuple algebra (was: negative index in arrays)

[Stephen Rawls]

--- Aldo Calpini <[EMAIL PROTECTED]> wrote:
> you should also consider the case TUPLE1 + 5 which
> should return (a1 + 5, a2 + 5, ... , an + 5).

Agreed.  I had started to implement this already, but
I've only done the add function so far, since I'm
still testing and waiting for a consensus.

 
> what do you do if TUPLE1 and TUPLE2 are of different
> length?

Throw an exception.  If there are more graceful
solutions, though, I'm open to them.


> changing subject again... how is tuple storage
> implemented? do they contain only integers (or
> whatever), or is the base type definable? 

I based it off array.pmc, so you can store
ints/chars/floats/pmcs in it.

Stephen Rawls


__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: tuple algebra (was: negative index in arrays)

[Aldo Calpini]

Stephen Rawls wrote:
> Also of note, instead of having TUPLE1 + TUPLE2 act as
> arrays, and return the sum of their sizes, I am
> treating it like this: (a1, a2, ... , an) + (b1, b2,
> ... , bn) = (a1 + b1, a2 + b2, ... , an + bn)

makes sense to me (and certainly adds some spice to
the cause of tuples instead of arrays :-).

you should also consider the case TUPLE1 + 5 which
should return (a1 + 5, a2 + 5, ... , an + 5).

what do you do if TUPLE1 and TUPLE2 are of different
length?

changing subject again... how is tuple storage
implemented? do they contain only integers (or whatever),
or is the base type definable? I ask this because I
thought it would be nice to have a 4-tuple of type char.
this will nicely represent an IP address, for example
(or do we need an ipaddr.pmc? ;-).

cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;

Re: [perl #15904] Configure broken on windows 9x

[Nicholas Clark]

On Thu, Aug 01, 2002 at 04:50:25PM +0200, Aldo Calpini wrote:
> Mr. Nobody wrote:
> > The windows 9x command.com shell dosen't recognize
> > 2>&1 so it ends up passing "2" as an argument to the
> > compiler, which fails because there's no such file.
> 
> this is no news. you can't even build Perl on 9x.
> IMHO, *build* platform targets should not include 9x.
> build it on NT/2000/XP and then feel free to use the
> binary on 9x (as Perl actually does).

Nikola Knezevic ( indy at tesla.rcub.bg.ac.yu ) was certainly managing
it last year, and was reporting to p5p on progresses with clearing up
regression test failures.
I think he wasn't using the 9x command.com shell though.

Nicholas Clark

[perl #15922] [PATCH] jit documentatiion + tweaks

[via RT]

# New Ticket Created by  Jason Gloudon 
# Please include the string:  [perl #15922]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=15922 >



More Revisions of jit.doc as well as some more overview comments on the SPARC
jit approach. Also included is a change to the way interpreter functions are
invoked on x86. This uses the fact that the interpreter argument remains
unchanged on the stack to avoid pushing it every time.

-- 
Jason


-- attachment  1 --
url: http://rt.perl.org/rt2/attach/32575/26872/3ac00b/jit.patch



Index: docs/jit.pod
===
RCS file: /cvs/public/parrot/docs/jit.pod,v
retrieving revision 1.4
diff -r1.4 jit.pod
76c76,78
< here.
---
> here. To simplify the maintenance of these functions, they are specified in a
> format that is pre-processed by B to produce a valid C source file,
> B. See L below.
119c121
< Reads the .jit files and prints the struct opcode_assembly_t.
---
> Preprocesses the .jit files to produce and prints the struct opcode_assembly_t.
132,137c134,145
< Where I is the name of the Parrot opcode, and I consists
< of a sequence of the following forms:
< 
< =item Assembly instruction.
< 
< Which may have one of this B as an argument: 
---
> Where I is the name of the Parrot opcode, and I consists of C
> syntax code which may contain any of the identifiers listed in the following
> section.
> 
> =item Identifiers
> 
> In general, prefixing an identifier with I<&> yields the address of the
> referenced Parrot register or constant.  If an identifier is given without a
> prefix, the value is returned by default.   To emphasis the use of the value,
> the I<*> prefix may be used.  Since Parrot register values vary during code
> execution, their values can not be obtained through identifier substitution
> alone.
210,211d217
< 
< You must preside all the identifiers with I<&> requesting the address of that 
identifier, or I<*> requesting the value, I<*> can be used only with constants since 
the replacement is done before start running.
Index: jit/i386/core.jit
===
RCS file: /cvs/public/parrot/jit/i386/core.jit,v
retrieving revision 1.20
diff -r1.20 core.jit
7a8
> emitm_addl_i_r(jit_info->native_ptr, 4, emit_ESP);
8a10
> NATIVECODE = emit_popl_r(NATIVECODE, emit_EBP);
Index: jit/i386/jit_emit.h
===
RCS file: /cvs/public/parrot/jit/i386/jit_emit.h,v
retrieving revision 1.4
diff -r1.4 jit_emit.h
101c101
< break;
---
> return;
111,112c111,112
< if((i && !scale) || (scale && !i)){
< internal_exception(JIT_ERROR,
---
> if(i && !scale){
> internal_exception(JIT_ERROR,
343a344,345
> #define emitm_alub_i_r(pc, op1, op2, imm, reg) { *(pc++) = op1; *(pc++) = 
>emit_alu_X_r(op2, reg); *(pc++) = (char)(imm); }
> 
368a371,372
> #define emitm_addb_i_r(pc, imm, reg)   emitm_alub_i_r(pc, 0x83, emit_b000, imm, reg)
> 
669a674,678
> /* Maintain the stack frame pointer for the sake of gdb */
> jit_info->native_ptr = emit_pushl_r(jit_info->native_ptr, emit_EBP);
> emitm_movl_r_r(jit_info->native_ptr, emit_ESP, emit_EBP);
> 
> /* Save ESI, as it's value is clobbered by jit_cpcf_op */
670a680,686
> 
> /* Cheat on op function calls by writing the interpreter arg on the stack
>  * just once. If an op function ever modifies the interpreter argument on
>  * the stack this will stop working !!! */
> emitm_pushl_i(jit_info->native_ptr, interpreter);
> 
> /* Point ESI to the opcode-native code map array */ 
677d692
< emitm_pushl_i(jit_info->native_ptr, interpreter);
686c701
< emitm_addl_i_r(jit_info->native_ptr, 8, emit_ESP);
---
> emitm_addb_i_r(jit_info->native_ptr, 4, emit_ESP);
Index: jit/sun4/jit_emit.h
===
RCS file: /cvs/public/parrot/jit/sun4/jit_emit.h,v
retrieving revision 1.3
diff -r1.3 jit_emit.h
8a9,19
> /* 
>  * SPARC JIT overview:
>  * 
>  * The interpreter pointer is kept in i0.
>  * The address of register I0 is stored in i1, with all parrot register access
>  * performed relative to this register.
>  * The address of the opcode - native code mapping array is kept in i3.
>  *
>  * See IMPORTANT SHORTCUTS below.
>  * /
> 
267c278,284
< /* Shortcuts for registers */
---
> /* 
>  *
>  * IMPORTANT SHORTCUTS
>  *
>  * */ 
> 
> /* The register holding the interpreter pointer */
268a286,287
> 
> /* The register holding the address of I0 */
269a289,290
> 
> /* The register containing the address of the opmap */
270a292,293
> 
> /* The scratch register used for certain address calculations */
273a297,298
> 
> /* The offset of a Parrot register from the base register */
301a327
> /* This function loads a value */

Re: negative index in arrays

[Stephen Rawls]

--- Aldo Calpini <[EMAIL PROTECTED]> wrote:
> there should also be no need to check for
> syntactic sugar like negative indices.

True, I suppose if a language REALLY wanted this, it
could be implemented on the interpreter level.


Also of note, instead of having TUPLE1 + TUPLE2 act as
arrays, and return the sum of their sizes, I am
treating it like this: (a1, a2, ... , an) + (b1, b2,
 , bn) = (a1 + b1, a2 + b2, ... , an + bn)

This is (of course) not restricted to addition.  I
thought I'd check and see if you all feel that should
be the default implementation, though.  Or maybe we
need a special HyperTuple pmc too?

cheers,
Stephen Rawls


__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [perl #15904] Configure broken on windows 9x

[Aldo Calpini]

Mr. Nobody wrote:
> The windows 9x command.com shell dosen't recognize
> 2>&1 so it ends up passing "2" as an argument to the
> compiler, which fails because there's no such file.

this is no news. you can't even build Perl on 9x.
IMHO, *build* platform targets should not include 9x.
build it on NT/2000/XP and then feel free to use the
binary on 9x (as Perl actually does).


cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;

Re: negative index in arrays

[Aldo Calpini]

Stephen Rawls wrote:
> since I want the Tuple pmc to do the same thing in
> this respect as the PerlArray pmc.

just my opinion, but I don't want this. it would be
PerlTuple then. let's keep this stuff at a higher level.

the only and one reason I see because one would implement
tuples instead of arrays is: speed. no need to cope with
dynamic memory allocation, no need to grow or shrink,
se there should also be no need to check for syntactic
sugar like negative indices.

cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;

[perl #15920] [PATCH] squash IRIX warning (resubmit)

[via RT]

# New Ticket Created by  Jarkko Hietaniemi 
# Please include the string:  [perl #15920]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=15920 >


This also never seemed to show up in p6i.

- Forwarded message from Jarkko Hietaniemi <[EMAIL PROTECTED]> -

Subject: [PATCH] [perl #15865] squash IRIX warning
From: Jarkko Hietaniemi <[EMAIL PROTECTED]>
Date: Wed, 31 Jul 2002 08:19:20 +0300
Message-ID: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
User-Agent: Mutt/1.2.5.1i

IRIX found another return missing from a non-void function.

diff -ruN parrot/core.ops parrot+cast/core.ops
--- parrot/core.ops 2002-07-26 22:15:56.0 +0300
+++ parrot+cast/core.ops2002-07-31 07:02:37.0 +0300
@@ -4257,6 +4257,7 @@
   else {
 abort();
   }
+  return 0;
 }
 
 =item B(in INT)

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

- End forwarded message -

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

[perl #15919] [PATCH] make IRIX and UNICOS/mk happy (resubmit)

[via RT]

# New Ticket Created by  Jarkko Hietaniemi 
# Please include the string:  [perl #15919]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=15919 >


This fixes [perl #15865] and [perl #15870].  I never saw this in p6i
(eaten by hungry spamfilters?), and the RT does not like me for some
reason so I can't see whether it got filed under #15865.

- Forwarded message from Jarkko Hietaniemi <[EMAIL PROTECTED]> -

Subject: [PATCH] [perl #15865] SGI compilation error
From: Jarkko Hietaniemi <[EMAIL PROTECTED]>
Date: Wed, 31 Jul 2002 08:17:14 +0300
Message-ID: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
User-Agent: Mutt/1.2.5.1i

This fixes also [perl #15870] UNICOS/mk compilation error.

diff -ruN parrot/classes/coroutine.pmc parrot+cast/classes/coroutine.pmc
--- parrot/classes/coroutine.pmc2002-07-26 22:17:41.0 +0300
+++ parrot+cast/classes/coroutine.pmc   2002-07-31 06:35:27.0 +0300
@@ -325,14 +325,14 @@
}
 */
 
-   INTVAL invoke () {
- struct Parrot_Coroutine* co = (struct Parrot_Sub*)SELF->data;
+   INTVAL invoke () { /* XXX shouldn't this be UINTVAL? XXX */
+ struct Parrot_Coroutine* co = (struct Parrot_Coroutine*)SELF->data;
 
  /* Resuming co-routine or fresh call? */
  if(!co->resume) {
-   return co->init;
+   return PTR2INTVAL(co->init);
  }
 
- return co->resume;
+ return PTR2INTVAL(co->resume);
} 
 }
diff -ruN parrot/classes/sub.pmc parrot+cast/classes/sub.pmc
--- parrot/classes/sub.pmc  2002-07-26 22:17:41.0 +0300
+++ parrot+cast/classes/sub.pmc 2002-07-31 06:37:58.0 +0300
@@ -326,8 +326,8 @@
}
 */
 
-   INTVAL invoke () {
+   INTVAL invoke () { /* XXX shouldn't this be UINTVAL? XXX */
  /* return address that the interpreter should jump to */
- return ((struct Parrot_Sub*)SELF->data)->init;
+ return PTR2INTVAL(((struct Parrot_Sub*)SELF->data)->init);
} 
 }
diff -ruN parrot/include/parrot/parrot.h parrot+cast/include/parrot/parrot.h
--- parrot/include/parrot/parrot.h  2002-07-18 07:30:42.0 +0300
+++ parrot+cast/include/parrot/parrot.h 2002-07-31 06:49:05.0 +0300
@@ -97,6 +97,12 @@
 #define D2FPTR(x) (funcptr_t)(UINTVAL) x
 #define F2DPTR(x) (void*)(UINTVAL)(funcptr_t) x
 
+/*
+ * Macroized in case more complex casts required in some platforms.
+ */
+#define PTR2INTVAL(p)   (INTVAL)(p)
+#define INTVAL2PTR(i,p) (p*)(i)
+
 /* On Win32 we need the constant O_BINARY for open() (at least for Borland C), 
but on UNIX it doesn't exist, so set it to 0 if it's not defined
  */

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

- End forwarded message -

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: problems sending patches

[Nicholas Clark]

On Wed, Jul 31, 2002 at 11:44:00PM -0700, Robert Spier wrote:
> >On Wed, Jul 24, 2002 at 08:44:20AM -0700, Stephen Rawls wrote:
> >> The last two (well, the only two :) patches I sent
> >> were counted as spam.  Some of the points were becuase
> 
> Sorry about that!  I'm trying to be better safe than sorry in
> preventing spam from getting to the list.

I don't like spam. Thanks for keeping it out.

> Yes.  We periodically check the spam queue and move things to the
> right place.  I have a todo list item for resending them to the list,
> but until that's done, they'll just be less noticed until someone goes
> through open tickets.

How do you recruit new "someone"s?
Are they the same sort of "someone"s who manage perl5 bugs?

> >1: Changing your machine so that it doesn't think it's yahoo.com
> >2: Adding a Reply-To: back to your yahoo address
> >
> >(clearly if you currently need to have your machine think it's in a sub-domain
> >of yahoo.com so that your messages come From: yahoo.com, then you'd have to
> >do both of the above to get mail to go back to your yahoo account)
> 
> He's using Yahoo webmail.

And (IIRC) Spam Assassin is then penalising him for having a *false*
yahoo header in there? So you can't win, unless you fake Yahoo's headers
to a better standard then Yahoo fake them? :-(

> >I'm curious why Reply-To is scored so highly - I don't set any Reply-To in
> >my messages, and I didn't think that it was normal practice.
> 
> Ask the SpamAssassin folks.  ;)

Oh, maybe I should have asked them the above question then.

Nicholas Clark

Re: parrot reading from stdin

[Stephen Rawls]

--- Melvin Smith <[EMAIL PROTECTED]> wrote:
> You can do this now:
> 
> ../assemble.pl a.pasm | parrot -

*slaps head* Do'h.  Thanks for the information, sorry
I missed it.

Stephen Rawls

__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: admin question: mail gets tagged as spam when mailing bugs..@perl..

[Ask Bjoern Hansen]

[EMAIL PROTECTED] (=?Latin1?Q?Josef_h=F6=F6k?=) writes:

> As im not that familiar with spamassasin maybe someone could help me
> stop getting my mail tagged as spam when mailing patches..

Let [EMAIL PROTECTED] know about such thing and we'll take care of
it.  Most likely it has been fixed by Robert upgrading our perl to
5.8.0 proper.


 - ask

-- 
ask bjoern hansen, http://askbjoernhansen.com/ !try; do();

Re: Perl 6 Summary for week ending 20020728

[Ask Bjoern Hansen]

On 1 Aug 2002 [EMAIL PROTECTED] wrote:

> The mailing list archives are still not searchable (tell me about it),
> but Brent Dax points out that the ever wonderful Google has the "site:"
> keyword to do search restriction. I foresee a handy little autobookmark
> appearing on my galeon toolbar real soon now.

http://groups.google.com/groups?q=perl.perl6

(via colobus (by Jim Winstead), colobus patches (by me) and Stanford
NNTP (by Russ Allbery)).

> Stephen Rawls has a problem; Spamassassin thinks his patches are spam.

Spamassassin didn't play nicely with 5.8.0RC1 which we used until
yesterday when Robert upgraded it.

> 1 It's late.

Don't worry about that.  I'm sure I'm not the only one to really
appreciate it, whenever it comes out.  Thanks!

> Actually, feedback on this would be good; in general adding the links is
> the most time consuming and tedious part of writing the summaries,
> requiring a net connection and time to check the links. Which leads me
> to wonder if I can't write links as predictable google searches using
> the message-id. Time to experiment methinks.

nntp.perl.org supports linking by message-id.

-- 
ask bjoern hansen, http://askbjoernhansen.com/   !try; do();

PATCH - Allow assemble.pl to read from STDIN

[Brian Ingerson]

Hi all,

I'm new to Parrot and Perl6. I hope this is an ok way to submit a patch.

---
- Allow assemble.pl to read from STDIN
- Use the '-' symbol to indicate STDIN
- Made invocation failures/usages behave more correctly
- Minor refactorings in this code section


Index: assemble.pl
===
RCS file: /cvs/public/parrot/assemble.pl,v
retrieving revision 1.82
diff -u -r1.82 assemble.pl
--- assemble.pl 18 Jul 2002 02:13:27 -  1.82
+++ assemble.pl 1 Aug 2002 09:25:00 -
@@ -1047,35 +1047,33 @@
 sub process_args {
   my ($args,$files) = @_;
 
-  for (my $count = 0; $count < @ARGV; $count++) {
-my $arg = $ARGV[$count];
-
+  while (my $arg = shift @ARGV) {
 if($arg =~ /^-(c|-checksyntax)$/) { $args->{-c} = 1; }
 elsif($arg =~ /^-E$/) { $args->{-E} = 1; }
-elsif($arg =~ /^-(o|-output)$/)   { $args->{-o} = $ARGV[++$count]; }
-elsif($arg =~ /^-(h|-help)$/) { Usage(); }
-else {
-  push @$files,$arg;
-}
-  }
-  unless(@$files) {
-print STDERR "No files to process.\n";
-Usage();
+elsif($arg =~ /^-(o|-output)$/)   { $args->{-o} = shift @ARGV; }
+elsif($arg =~ /^-(h|-help)$/) { Usage(); exit 0; }
+elsif($arg =~ /^-./)  { Fail("Invalid option '$arg'\n"); }
+else  { push @$files,$arg; }
   }
-  for(@$files) {
-next if -e $_;
-print STDERR "File '$_' does not exist.\n";
+  Fail("No files to process.\n") unless(@$files);
+  Fail("File '$_' does not exist.\n") for grep { not (-e or /^-$/) } @$files;
+}
+
+sub Fail {
+print STDERR @_;
 Usage();
-  }
+exit 1;
 }
 
 sub Usage {
   print <<"  _EOF_";
+
 usage: $0 [options] file [file...]
 
 -E  Preprocess input files and terminate processing
 -h,--help   Print this message
 -o,--output Write file 
 -c,-checksyntax Check syntax only, do not generate bytecode
+
   _EOF_
 }