Re: String API

[Dave Storrs]

(As previously remarked, I'm trying to catch up from a few days offline,
so excuse me if this is OOD.)

On Tue, 11 Sep 2001, Ken Fox wrote:

> The interpreter knows the internals of the stack structure and is
> responsible for managing it. To change the stack implementation, we'll
> have to carefully examine all the interpreter code. The semantics of
> the stack aren't real clear either. For example, when changing the
> stack code what invariants must be preserved? If the stack had an API
> the interpreter used I think this would be much clearer.

If we defined that API as a series of tests, we might save
ourselves a lot of grief.  I'll volunteer to (attempt to) write the tests,
if someone will specify what the invariants are.

Dave

string vtable editing script

[Dave Storrs]

I've been offline for a few days and haven't caught up on email yet
(nor, most likely, will I ever), so I hope no one else has already
done this, but

Attached is a file, msv.tar.gz which contains a simple script and .pm
file (*) for editing the string vtable.  It asks you for a bunch of
typedef/function_name pairs and then rewrites string.h, string.c, and
all of the encoding code files (strnative.c, strforeign.c, strutf*.c),
incorporating what you gave it.

PROS:
- you can give it as many typedef/function pairs as you want at once

- it adds your new typedef only if it isn't already there

- before adding your new function, it checks the vtable in string.h to
make sure that there isn't already an identical function, or one that
differs only by return type

- it understands that (e.g.) 'two_strings_to_iv_t' should expand to:
IV (*two_strings_to_iv_t)(STRING *, STRING *);
(Actually, it understands numbers up to nine, but I hope you never go
that high.)

- it sets up stubs in string.c and all the encoding files, and adds
the appropriate entry to each file's vtable

- if your encoding files don't exist, it will generate them for you

CONS:

- your typedefs must match:  +_to__t  where  is
composed only of word characters.  The arguments (the part before the
'to') must be separated by underscores.  So, these are legal:
  string_to_string_t
  iv_nv_to_string_t
  three_strings_nv_to_nv_t  OR  three_string_nv_to_nv_t   (same thing)
these are not legal:
  &(*&_t  (not a valid symbol)
  string_string_t (doesn't specify a return type)
worst of all, this doesn't work:
  substr_t(the patch to change it to an accepted version
 is below) 

- any comments that you put in the vtable or the typedef section will
be stomped the next time you run the program.  If people actually use
this and find it useful, I will fix this misbehaviour.

NOTES:

- the stubs that are put into string.c and the encoding tables don't
have names for their parameters, since the program has no way of
knowing what meaningful names would be.

- the bodies of the stubs consist almost solely of 'FINISH ME', not in
comments (so that it won't compile).  There is probably more that I
could make it do for you here, but I wanted to get a working version
out. 

- the program uses various parts, including comments, of the string.h
file as delimiters, so if you start making regular manual changes it
might stop working or misbehave.




A sample session (actually a record of the last session I ran before
writing this email) is below.  I've put my inputs on the line
following the prompt and indented them to make them stand out.

CUT HERE--
Enter a function name (e.g. chopn), or  to quit: 
reverse
Enter a typedef name (e.g. iv_to_iv_t) to associate with reverse: 
string_to_string_t
Enter a function name (e.g. chopn), or  to quit: 

About to rewrite string.h...
Successfully wrote revised text to 'string.h.working'

About to rewrite string.c...
Successfully wrote revised text to 'string.c.working'

About to rewrite encoding files...
Successfully wrote revised text to 'strforeign.c.working'
Successfully wrote revised text to 'strnative.c.working'
Successfully wrote revised text to 'strutf16.c.working'
Successfully wrote revised text to 'strutf32.c.working'
Successfully wrote revised text to 'strutf8.c.working'

About to move working copies to primary versions...
Successfully moved working file 'strforeign.c.working' to 'strforeign.c'
Successfully moved working file 'strutf32.c.working' to 'strutf32.c'
Successfully moved working file 'strutf16.c.working' to 'strutf16.c'
Successfully moved working file 'strutf8.c.working' to 'strutf8.c'
Successfully moved working file 'strnative.c.working' to 'strnative.c'
Successfully moved working file 'string.h.working' to 'string.h'
Successfully moved working file 'string.c.working' to 'string.c'

./msv.pl completed successfully.

$ [edit string.c and strnative.c]
$ [compile and test]
$ [celebrate by submitting]


Here is the patch to change substr_t into something this program can  
accept:

[dstorrs@localhost parrot]$ cvsp -q diff -c string.h
--  DIFF OUTPUT STARTS ON NEXT LINE ---
Index: string.h
===
RCS file: /home/perlcvs/parrot/string.h,v
retrieving revision 1.5
diff -u -d -c -r1.5 string.h
cvs server: conflicting specifications of output style
*** string.h2001/09/14 14:08:00 1.5
--- string.h2001/09/16 03:54:37
***
*** 25,31 
  typedef IV (*string_to_iv_t)(STRING *);
  typedef STRING* (*string_iv_to_string_t)(STRING *, IV);
  typedef STRING* (*two_strings_iv_to_string_t)(STRING *, STRING *, IV);
! typedef STRING* (*substr_t)(STRING*, IV, IV, STRING*);
  typedef IV (*iv_to_iv_t)(IV);
  
  struct string_vtable {
--- 25,31 
  typedef IV (*string_to_iv_t)(STRING *);
  typedef STRING* (*string_iv_to_string_t)(STRING *,

RE: Constant comparisons

[Dan Sugalski]

On Sat, 15 Sep 2001, Nathan Torkington wrote:

> Gibbs Tanton - tgibbs writes:
> > It seems to me that this might eventually get out of hand...could there
> > possibly be some way to automate the generation of a family of opcodes?  For
> > example:
> 
> Hear hear, the same thing occurred to me.  The way that there are
> separate functions for each argument type is really adding to the
> number of functions.  What was the reasoning behind that again, Dan?

The reasoning is that we'd screw our pipleine exacly once per opcode, on
function dispatch, and not two or more times as we check and fiddle with
our arguments.

I agree, though, this is getting out of hand, especially as these are
probably some of the least-used opcodes in the engine for most of the
target languages. (Who'll all use the PMC variants of the opcodes) Let me
think about this some. For right now I'm OK with it happening, but I want
to see what the total opcode function count is reaching for before I'm
willing to commit 'em to stone.

Dan

Re: [patch] New comparison ops + better op inference

[Dan Sugalski]

On 15 Sep 2001, Gregor N. Purdy wrote:

> All --
> 
> In working to make Jako be able to handle while (i < 0) as well as
> while (i < n), I added a bunch of integer and numerical comparison
> ops. I also tinkered with the assembler's op inferencing to get it
> to pick the ops I intended.

Please back these out. I'd rather not have new operations added without a
good going-over first. (They may go in later, but not right now)

Dan

RE: Constant comparisons

[Nathan Torkington]

Gibbs Tanton - tgibbs writes:
> It seems to me that this might eventually get out of hand...could there
> possibly be some way to automate the generation of a family of opcodes?  For
> example:

Hear hear, the same thing occurred to me.  The way that there are
separate functions for each argument type is really adding to the
number of functions.  What was the reasoning behind that again, Dan?

Nat

Re: coding standards

[Nathan Torkington]

Gibbs Tanton - tgibbs writes:
> I will try to watch things as they go in and make coding standard
> changes immediately from now on so we don't have such a massive
> change.

Alternatively, pumpkings could refuse to apply patches that don't
conform.  One or two goes around and people will learn to submitting
correct patches.

Nat

mod_parrot

[Ask Bjoern Hansen]

Robert Spier and I just had some fun.

Parrot for Apache. :-)

http://cvs.perl.org/cvsweb/mod_parrot/

It's really simplistic and doesn't actually work.  As Robert just
told me, it'll be really ugly to get to actually send stuff back to
the browser until Parrot has some kind of real IO subsystem.  But it
does do the work. :-)


 - ask


-- 
ask bjoern hansen, http://ask.netcetera.dk/   !try; do();

RE: Constant comparisons

[Gibbs Tanton - tgibbs]

It seems to me that this might eventually get out of hand...could there
possibly be some way to automate the generation of a family of opcodes?  For
example:

MANUAL_OP_FAMILY eq_T1_T2 {
  if( T1 == T2 ) {
RETURN(P3);
  }
  else {
RETURN(P4);
  }
} OVER(i, ic, n, nc)

Note that I'm not proposing that syntax, just wondering if there is a more
automated way of doing things.

-Original Message-
From: Nathan Torkington
To: [EMAIL PROTECTED]
Sent: 9/15/2001 4:56 PM
Subject: Constant comparisons

I wanted to be able to say

eq I1, 15, label1, label2

That is, to compare against a constant.  I've implemented versions of
the comparison opcodes that let you compare against constants.  This
is my first patch to Parrot.  Be merciful :-)

Nat
(also working on test system ... stay tuned)


Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.15
diff -u -d -r1.15 basic_opcodes.ops
--- basic_opcodes.ops   2001/09/14 14:08:00 1.15
+++ basic_opcodes.ops   2001/09/15 21:52:38
@@ -56,6 +56,15 @@
   }
 }
 
+/* EQ Ix, CONSTANT, EQ_BRANCH, NE_BRANCH */
+MANUAL_OP eq_ic_ic {
+  if (INT_REG(P1) == P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* NE Ix, Iy, NE_BRANCH, EQ_BRANCH */
 MANUAL_OP ne_i_ic {
   if (INT_REG(P1) != INT_REG(P2)) {
@@ -65,6 +74,15 @@
   }
 }
 
+/* NE Ix, CONSTANT, NE_BRANCH, EQ_BRANCH */
+MANUAL_OP ne_ic_ic {
+  if (INT_REG(P1) != P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* LT Ix, Iy, LT_BRANCH, GE_BRANCH */
 MANUAL_OP lt_i_ic {
   if (INT_REG(P1) < INT_REG(P2)) {
@@ -74,6 +92,15 @@
   }
 }
 
+/* LT Ix, CONSTANT, LT_BRANCH, GE_BRANCH */
+MANUAL_OP lt_ic_ic {
+  if (INT_REG(P1) < P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* LE Ix, Iy, LE_BRANCH, GT_BRANCH */
 MANUAL_OP le_i_ic {
   if (INT_REG(P1) <= INT_REG(P2)) {
@@ -83,6 +110,15 @@
   }
 }
 
+/* LE Ix, CONSTANT, LE_BRANCH, GT_BRANCH */
+MANUAL_OP le_ic_ic {
+  if (INT_REG(P1) <= P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* GT Ix, Iy, GT_BRANCH, LE_BRANCH */
 MANUAL_OP gt_i_ic {
   if (INT_REG(P1) > INT_REG(P2)) {
@@ -92,6 +128,15 @@
   }
 }
 
+/* GT Ix, CONSTANT, GT_BRANCH, LE_BRANCH */
+MANUAL_OP gt_ic_ic {
+  if (INT_REG(P1) > P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* GE Ix, Iy, GE_BRANCH, LT_BRANCH */
 MANUAL_OP ge_i_ic {
   if (INT_REG(P1) >= INT_REG(P2)) {
@@ -101,6 +146,15 @@
   }
 }
 
+/* GE Ix, CONSTANT, GE_BRANCH, LT_BRANCH */
+MANUAL_OP ge_ic_ic {
+  if (INT_REG(P1) >= P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* IF IXx, TRUE_BRANCH, FALSE_BRANCH */
 MANUAL_OP if_i_ic {
   if (INT_REG(P1)) {
@@ -193,6 +247,15 @@
 /* EQ Nx, Ny, EQ_BRANCH, NE_BRANCH */
 MANUAL_OP eq_n_ic {
   if (NUM_REG(P1) == NUM_REG(P2)) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
+/* EQ Nx, CONSTANT, EQ_BRANCH, NE_BRANCH */
+MANUAL_OP eq_nc_ic {
+  if (NUM_REG(P1) == P2) {
 RETURN(P3);
   } else {
 RETURN(P4);
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.13
diff -u -d -r1.13 opcode_table
--- opcode_table2001/09/13 16:16:38 1.13
+++ opcode_table2001/09/15 21:52:38
@@ -62,12 +62,19 @@
 # Comparators
 
 eq_i_ic4   I I D D
+eq_ic_ic   4   I i D D
 eq_n_ic4   N N D D
+eq_nc_ic   4   N n D D
 ne_i_ic4   I I D D
+ne_ic_ic   4   I i D D
 lt_i_ic4   I I D D
+lt_ic_ic   4   I i D D
 le_i_ic4   I I D D
+le_ic_ic   4   I i D D
 gt_i_ic4   I I D D
+gt_ic_ic   4   I i D D
 ge_i_ic4   I I D D
+ge_ic_ic   4   I i D D
 
 # Flow control
 

coding standards

[Gibbs Tanton - tgibbs]

Ok, I just updated every .c and .h file to include the new coding standard.
I also updated most of the .pl files to use Parrot_Interp instead of
Perl_Interp.  Please refresh your copy of the files.

I will try to watch things as they go in and make coding standard changes
immediately from now on so we don't have such a massive change.

Thanks!
Tanton

[PATCH] Duplicate in Parrot/Opcode.pm

[Buggs]

Hoi,

Is this a pattern?

Buggs


Index: Parrot/Opcode.pm
===
RCS file: /home/perlcvs/parrot/Parrot/Opcode.pm,v
retrieving revision 1.3
diff -u -3 -p -r1.3 Opcode.pm
--- Parrot/Opcode.pm	2001/09/15 00:57:42	1.3
+++ Parrot/Opcode.pm	2001/09/16 01:02:04
@@ -105,89 +105,4 @@ The fingerprint() function returns the M
 opcode table.
 
 =cut
-package Parrot::Opcode;
 
-use strict;
-use Symbol;
-
-sub read_ops {
-my $file = @_ ? shift : "opcode_table";
-
-my $fh = gensym;
-open $fh, $file or die "$file: $!\n";
-
-my %opcode;
-my $count = 1;
-while (<$fh>) {
-	s/#.*//;
-	s/^\s+//;
-	chomp;
-	next unless $_;
-
-	my($name, @params) = split /\s+/;
-	if (@params && $params[0] =~ /^\d+$/) {
-	my $count = shift @params;
-	die "$file, line $.: opcode $name parameters don't match count\n"
-	  if ($count != @params);
-	}
-
-	warn "$file, line $.: opcode $name redefined\n" if $opcode{$name};
-
-	$opcode{$name}{ARGS}  = @params;
-	$opcode{$name}{TYPES} = \@params;
-	$opcode{$name}{CODE}  = ($name eq "end") ? 0 : $count++;
-	$opcode{$name}{FUNC}  = "Parrot_op_$name";
-
-	my $num_i = () = grep {/i/} @params;
-	my $num_n = () = grep {/n/} @params;
-	$opcode{$name}{RETURN_OFFSET} = 1 + $num_i + $num_n * 2;
-}
-
-return %opcode;
-}
-
-1;
-
-
-__END__
-
-=head1 NAME
-
-Parrot::Opcode - Read opcode definitions
-
-=head1 SYNOPSIS
-
-  use Parrot::Opcode;
-
-  %opcodes = Parrot::Opcode::read_ops();
-
-=head1 DESCRIPTION
-
-The read_ops() function parses the Parrot opcode_table file, and
-returns the contents as a hash.  The hash key is the opcode name;
-values are hashrefs containing the following fields:
-
-=over
-
-=item CODE
-
-The opcode number.
-
-=item ARGS
-
-The opcode argument count.
-
-=item TYPES
-
-The opcode argument types, as an arrayref.
-
-=item FUNC
-
-The name of the C function implementing this op.
-
-=back
-
-read_ops() takes an optional argument: the file to read the opcode table
-from.
-
-=cut

Re: [patch] A few fixes to the Jako compiler

[Buggs]

Hoi,

Just not to lie.

Buggs

Index: little_languages/jakoc
===
RCS file: /home/perlcvs/parrot/little_languages/jakoc,v
retrieving revision 1.1
diff -u -3 -p -r1.1 jakoc
--- little_languages/jakoc  2001/09/15 20:58:05 1.1
+++ little_languages/jakoc  2001/09/16 00:55:32
@@ -271,7 +271,7 @@ sub begin_if_block
 printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "gt", "$args[0], $args[1], 
${prefix}_REDO, ${prefix}_LAST";
 printf "%s_REDO:\n", $prefix;
   } else {
-printf(STDERR "jako: Syntax error. Unrecognized condition in while on line 
%d.\n", $line);
+printf(STDERR "jako: Syntax error. Unrecognized condition in if on line %d.\n", 
+$line);
   }
 }

Re: Minor "cleanup" patch to interpreter.*

[Dan Sugalski]

On Sat, 15 Sep 2001, Michael Fischer wrote:

> This set of patches just eliminates some casts, and some
> "foo" in favor of (IMHO) clearer variable names. 
> 
> I also removed the DO_OP macro as it seems unnecessary
> for the current case, but perhaps I undervalue it?

Yup. The point of that macro is so that we can generate the body of the
oploop at parrot build time. This way we can build a switch, computed
goto, or indirect function call loop, depending on what's fastest for the
platform.

Dan

Minor "cleanup" patch to interpreter.*

[Michael Fischer]

This set of patches just eliminates some casts, and some
"foo" in favor of (IMHO) clearer variable names. 

I also removed the DO_OP macro as it seems unnecessary
for the current case, but perhaps I undervalue it?

==

--- build_interp_starter.bak.pl Sat Sep 15 15:42:03 2001
+++ build_interp_starter.pl Sat Sep 15 15:42:34 2001
@@ -29,13 +29,6 @@
 # Spit out the DO_OP function
 print INTERP opcode_funcs = (void*)foo;
+interpreter->opcode_funcs = parrot_opcode_table;
   }
 
   /* In case the I/O system needs something */

==




Michael
-- 
Michael Fischer 7.5 million years to run
[EMAIL PROTECTED]printf "%d", 0x2a;
-- deep thought 

RE: [PATCH] testsuite and Win32 compilation

[Brent Dax]

Brent Dax:
# Mattia Barbon:
# # > ## +#if defined(WIN32)
# # > ## +program_code = malloc( file_stat.st_size );
# # > ## +#else
# # >
# # > #Should we be using malloc, or are we supposed to use our
# # own allocator?
# # > #(I haven't been munging in the C, so I don't really
# # know--it just looks
# # > #a little suspicious.)
# # >
# # > In memory.{h,c} there is a mem_sys_allocate(IV) that I
# # would suggest.
# # Of course you're right.
# # New patch Attached
# #
# # The attached patch replaces things.diff ( testsuite.diff should be
# # OK )
# 
# I've made some small changes, including some comments so people don't
# keep putting new C compiler flags in the wrong place.  Most 
# of the other
# changes were things like formatting.  Patch attached.  I'll 
# commit this
# myself if nobody has any objections.  (Once this is 
# committed, I'll work
# on the parrot/config.h stuff, and merge that in to this patch.)

Ack, forgot to actually *attach* the file...

--Brent Dax
[EMAIL PROTECTED]

They *will* pay for what they've done.

--- parrot-cvs\parrot\Configure.pl  Fri Sep 14 17:57:42 2001
+++ parrot\parrot\Configure.pl  Sat Sep 15 16:01:18 2001
@@ -5,7 +5,36 @@
 
 use strict;
 use Config;
+use Getopt::Long;
 
+my( $opt_debugging, $opt_defaults, $opt_version, $opt_help ) =
+  ( 0, 0, 0, 0 );
+my( %opt_defines );
+my $result = GetOptions( 'debugging!' => \$opt_debugging,
+'defaults!'  => \$opt_defaults,
+'version'=> \$opt_version,
+'help'   => \$opt_help,
+'define=s'   => \%opt_defines,
+   );
+
+if( $opt_version ) {
+   print '$Id:$' . "\n";
+   exit;
+}
+
+if( $opt_help ) {
+   print <<"EOT";
+$0 - Parrot Configure
+Options:
+   --debugging  Enable debugging
+   --defaults   Accept all default values
+   --define name=value  Defines value name as value
+   --help   This text
+   --versionShow assembler version
+EOT
+   exit;
+}
+
 my($DDOK)=undef;
 eval {
require Data::Dumper;
@@ -29,21 +58,48 @@
 #defaults for them.
 #XXX Figure out better defaults
 my(%c)=(
-   iv =>   ($Config{ivtype}||'long'),
-   nv =>   ($Config{nvtype}||'long double'),
-   cc =>   $Config{cc},
-   ccflags =>  $Config{ccflags},
-   libs => $Config{libs},
-   perl => $^X,
+   iv =>   ($Config{ivtype}||'long'),
+   nv =>   ($Config{nvtype}||'double'),
+   cc =>   $Config{cc},
+   #ADD C COMPILER FLAGS HERE
+   ccflags =>  $Config{ccflags}." -I./include",
+   libs => $Config{libs},
+   perl => $^X,
+   cc_debug => '-g',
+   o =>'.o',   # object files extension
+   exe =>  $Config{_exe},
+   ld =>   $Config{ld},
+   ld_out =>   '-o ',  # ld output file
+   ld_debug => '', # include debug info in executable
+   debugging =>$opt_debugging,
 );
 
+foreach my $i ( keys %opt_defines ) {
+   $c{$i} = $opt_defines{$i};
+}
+
+# set up default values
+my $hints = "hints/" . lc( $^O ) . ".pl";
+if( -f $hints ) {
+   local($/);
+   open HINT, "< $hints" or die "Unable to open hints file '$hints'";
+   my $hint = ;
+   close HINT;
+   eval $hint or die "Error in hints file $hints: '$@/$!'";
+}
+
 #ask questions
 prompt("What C compiler do you want to use?", 'cc');
+prompt("How about your linker?", 'ld');
 prompt("What flags would you like passed to your C compiler?", 'ccflags');
 prompt("Which libraries would you like your C compiler to include?", 'libs');
 prompt("How big would you like integers to be?", 'iv');
-prompt("How about your floats?", 'nv');
+prompt("And your floats?", 'nv');
 
+unless( $c{debugging} ) {
+   $c{ld_debug} = ' ';
+   $c{cc_denug} = ' ';
+}
 
 print <<"END";
 
@@ -95,6 +151,8 @@
 
 #prompt for something from the user
 sub prompt {
+   return if $opt_defaults;
+
my($message, $field)=(@_);
my($input);
print "$message [$c{$field}] ";
--- parrot-cvs\parrot\Makefile.in   Fri Sep 14 17:57:42 2001
+++ parrot\parrot\Makefile.in   Sat Sep 15 16:01:24 2001
@@ -1,21 +1,27 @@
-O = .o
+O = ${o}
 
 H_FILES = config.h exceptions.h io.h op.h register.h string.h events.h interpreter.h 
memory.h parrot.h stacks.h bytecode.h global_setup.h
 
 O_FILES = global_setup$(O) interpreter$(O) parrot$(O) register$(O) basic_opcodes$(O) 
memory$(O) bytecode$(O) string$(O) strnative$(O)
 
-C_FLAGS = ${ccflags} -I..
+#DO NOT ADD C COMPILER FLAGS HERE
+#Add them in Configure.pl--look for the
+#comment 'ADD C COMPILER FLAGS HERE'
+C_FLAGS = ${ccflags} ${cc_debug}
 
 C_LIBS = ${libs}
 
 
 CC = ${cc} $(C_FLAGS)
+LD = ${ld}
 
-all : $(O_FILES)
+TEST_PROG=test_prog${exe}
 
-test_p

RE: [PATCH] testsuite and Win32 compilation

[Brent Dax]

Mattia Barbon:
# > ## +#if defined(WIN32)
# > ## +program_code = malloc( file_stat.st_size );
# > ## +#else
# >
# > #Should we be using malloc, or are we supposed to use our
# own allocator?
# > #(I haven't been munging in the C, so I don't really
# know--it just looks
# > #a little suspicious.)
# >
# > In memory.{h,c} there is a mem_sys_allocate(IV) that I
# would suggest.
# Of course you're right.
# New patch Attached
#
# The attached patch replaces things.diff ( testsuite.diff should be
# OK )

I've made some small changes, including some comments so people don't
keep putting new C compiler flags in the wrong place.  Most of the other
changes were things like formatting.  Patch attached.  I'll commit this
myself if nobody has any objections.  (Once this is committed, I'll work
on the parrot/config.h stuff, and merge that in to this patch.)

--Brent Dax
[EMAIL PROTECTED]

They *will* pay for what they've done.

How to get Digest::MD5

[Matthew Cline]

Since build_interp_starter.pl and assemble.pl need Digest::MD5, I tried to 
get it via CPAN, but it requires a compilation, which requires perl.h.  I'd 
think that there must be somewhere I can get the MD5 binary, since the MD5 
module would be of use to others besides perl developers.  My Perl is from 
5.700, from a Mandrake.

Thanks in advance.

-- 
Matthew Cline| Suppose you were an idiot.  And suppose that
[EMAIL PROTECTED] | you were a member of Congress.  But I repeat
 | myself.  -- Mark Twain

"Automated" Purify Run

[Josh Wilmes]

This time i've filtered out all the memory leak related data so all that 
shows up are legitimate errors. (hopefully)

I have set up a cheesy script to update the following URL with the current output 
of purify on the current CVS test_prog (test,test2,test3,euclid) every hour.

http://www.hitchhiker.org/josh/parrot/purify.txt

--Josh

Constant comparisons

[Nathan Torkington]

I wanted to be able to say

eq I1, 15, label1, label2

That is, to compare against a constant.  I've implemented versions of
the comparison opcodes that let you compare against constants.  This
is my first patch to Parrot.  Be merciful :-)

Nat
(also working on test system ... stay tuned)


Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.15
diff -u -d -r1.15 basic_opcodes.ops
--- basic_opcodes.ops   2001/09/14 14:08:00 1.15
+++ basic_opcodes.ops   2001/09/15 21:52:38
@@ -56,6 +56,15 @@
   }
 }
 
+/* EQ Ix, CONSTANT, EQ_BRANCH, NE_BRANCH */
+MANUAL_OP eq_ic_ic {
+  if (INT_REG(P1) == P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* NE Ix, Iy, NE_BRANCH, EQ_BRANCH */
 MANUAL_OP ne_i_ic {
   if (INT_REG(P1) != INT_REG(P2)) {
@@ -65,6 +74,15 @@
   }
 }
 
+/* NE Ix, CONSTANT, NE_BRANCH, EQ_BRANCH */
+MANUAL_OP ne_ic_ic {
+  if (INT_REG(P1) != P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* LT Ix, Iy, LT_BRANCH, GE_BRANCH */
 MANUAL_OP lt_i_ic {
   if (INT_REG(P1) < INT_REG(P2)) {
@@ -74,6 +92,15 @@
   }
 }
 
+/* LT Ix, CONSTANT, LT_BRANCH, GE_BRANCH */
+MANUAL_OP lt_ic_ic {
+  if (INT_REG(P1) < P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* LE Ix, Iy, LE_BRANCH, GT_BRANCH */
 MANUAL_OP le_i_ic {
   if (INT_REG(P1) <= INT_REG(P2)) {
@@ -83,6 +110,15 @@
   }
 }
 
+/* LE Ix, CONSTANT, LE_BRANCH, GT_BRANCH */
+MANUAL_OP le_ic_ic {
+  if (INT_REG(P1) <= P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* GT Ix, Iy, GT_BRANCH, LE_BRANCH */
 MANUAL_OP gt_i_ic {
   if (INT_REG(P1) > INT_REG(P2)) {
@@ -92,6 +128,15 @@
   }
 }
 
+/* GT Ix, CONSTANT, GT_BRANCH, LE_BRANCH */
+MANUAL_OP gt_ic_ic {
+  if (INT_REG(P1) > P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* GE Ix, Iy, GE_BRANCH, LT_BRANCH */
 MANUAL_OP ge_i_ic {
   if (INT_REG(P1) >= INT_REG(P2)) {
@@ -101,6 +146,15 @@
   }
 }
 
+/* GE Ix, CONSTANT, GE_BRANCH, LT_BRANCH */
+MANUAL_OP ge_ic_ic {
+  if (INT_REG(P1) >= P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* IF IXx, TRUE_BRANCH, FALSE_BRANCH */
 MANUAL_OP if_i_ic {
   if (INT_REG(P1)) {
@@ -193,6 +247,15 @@
 /* EQ Nx, Ny, EQ_BRANCH, NE_BRANCH */
 MANUAL_OP eq_n_ic {
   if (NUM_REG(P1) == NUM_REG(P2)) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
+/* EQ Nx, CONSTANT, EQ_BRANCH, NE_BRANCH */
+MANUAL_OP eq_nc_ic {
+  if (NUM_REG(P1) == P2) {
 RETURN(P3);
   } else {
 RETURN(P4);
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.13
diff -u -d -r1.13 opcode_table
--- opcode_table2001/09/13 16:16:38 1.13
+++ opcode_table2001/09/15 21:52:38
@@ -62,12 +62,19 @@
 # Comparators
 
 eq_i_ic4   I I D D
+eq_ic_ic   4   I i D D
 eq_n_ic4   N N D D
+eq_nc_ic   4   N n D D
 ne_i_ic4   I I D D
+ne_ic_ic   4   I i D D
 lt_i_ic4   I I D D
+lt_ic_ic   4   I i D D
 le_i_ic4   I I D D
+le_ic_ic   4   I i D D
 gt_i_ic4   I I D D
+gt_ic_ic   4   I i D D
 ge_i_ic4   I I D D
+ge_ic_ic   4   I i D D
 
 # Flow control
 

[commit] Renamed jako_compiler.pl to jakoc

[Gregor N. Purdy]

All --

I have renamed the Jako compiler from jako_compiler.pl to jakoc.


Regards,

-- Gregor
 _ 
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)'  \

   Gregor N. Purdy  [EMAIL PROTECTED]
   Focus Research, Inc.http://www.focusresearch.com/
   8080 Beckett Center Drive #203   513-860-3570 vox
   West Chester, OH 45069   513-860-3579 fax
\_/

Re: parrot compilation failure in Tru64

[Jarkko Hietaniemi]

On Sat, Sep 15, 2001 at 08:16:36PM +0100, Simon Cozens wrote:
> On Sat, Sep 15, 2001 at 08:43:19PM +0300, Jarkko Hietaniemi wrote:
> > Never mind 'portable' for now, currently it's not even *working* on
> > 64-bit platforms
> 
> That as may be, I'd like to make sure we start fixing it in the
> right direction rather than the wrong one. :)

Whichever way we go, you cannot dereference entities of alignment
eight at alignment four.

> Simon

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

Re: [patch] A few fixes to the Jako compiler

[Gregor N. Purdy]

All --


> If the assembler patch I submitted a little while ago goes in, I'll
> commit these changes to the Jako compiler. They fix a bug in assignment
> handling and add some more conditionals to while and if. Also it goes
> back to using implicit opcodes in a few cases that were broken before
> the assembler patch.

I just committed these changes.

 
Regards,
  
-- Gregor
 _ 
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)'  \

   Gregor N. Purdy  [EMAIL PROTECTED]
   Focus Research, Inc.http://www.focusresearch.com/
   8080 Beckett Center Drive #203   513-860-3570 vox
   West Chester, OH 45069   513-860-3579 fax
\_/

Re: [patch] New comparison ops + better op inference

[Gregor N. Purdy]

All --

> In working to make Jako be able to handle while (i < 0) as well as
> while (i < n), I added a bunch of integer and numerical comparison
> ops. I also tinkered with the assembler's op inferencing to get it
> to pick the ops I intended.
> 
> The attached patch also contains my label parsing fix to the
> assembler (posted earlier by itself).
> 
> With this patch in place, I'll be able to commit the new Jako
> compiler and updated examples.

I just committed these changes.


Regards,
 
-- Gregor
 _ 
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)'  \

   Gregor N. Purdy  [EMAIL PROTECTED]
   Focus Research, Inc.http://www.focusresearch.com/
   8080 Beckett Center Drive #203   513-860-3570 vox
   West Chester, OH 45069   513-860-3579 fax
\_/

Re: Parrot's mascot

[Gregor N. Purdy]

Rocco --


> > > I'd like to suggest that the Parrot image we've seen associated with
> > > Perl6 be 
> > 
> > this: http://pettalk.zapp.com.au/images/Africangrey.jpg
> 
> I can't seem to find a picture of a Norwegian Blue anywhere.

Maybe that's because its an EX-parrot!

http://www.intriguing.com/mp/_pictures/compdiff/norwegia.jpg
http://www.pythonet.org/pet-shop.html


Regards,

-- Gregor
 _ 
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)'  \

   Gregor N. Purdy  [EMAIL PROTECTED]
   Focus Research, Inc.http://www.focusresearch.com/
   8080 Beckett Center Drive #203   513-860-3570 vox
   West Chester, OH 45069   513-860-3579 fax
\_/

Re: Parrot's mascot

[Gregor N. Purdy]

Simon --

> > I'd like to suggest that the Parrot image we've seen associated with
> > Perl6 be 
> 
> this: http://pettalk.zapp.com.au/images/Africangrey.jpg

I also found this site: http://www.resonans.net/jako/


Regards,

-- Gregor
 _ 
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)'  \

   Gregor N. Purdy  [EMAIL PROTECTED]
   Focus Research, Inc.http://www.focusresearch.com/
   8080 Beckett Center Drive #203   513-860-3570 vox
   West Chester, OH 45069   513-860-3579 fax
\_/

Re: parrot compilation failure in Tru64

[Philip Kendall]

On Sat, Sep 15, 2001 at 02:28:25PM -0500, Gibbs Tanton - tgibbs wrote:
> > Never mind 'portable' for now, currently it's not even *working* on
> > 64-bit platforms
> 
> You might try putting an ! after the l in the assembler pack type and see if
> that fixes things.

'q' did the trick a few versions ago -- it's needed in a couple of other
places as in the assembler as well.

> Right now, it is going to be putting opcodes out in 32
> bits.  Since Tru64 is 64 bits, a long is going to be 64 bits.  Contrarywise,
> you might also try using int as the IV type instead of long.

That won't work though, due to our typecasting between pointers and IVs.
I did at one stage patch the entire thing to use int32_t for the
bytecode rather than IV, but...

 as Simon has said, we need to work out what we want to do to
fix this before we all go off fixing it various ways.

Phil

-- 
  Philip Kendall <[EMAIL PROTECTED]>
  http://www.srcf.ucam.org/~pak21/

[patch] New comparison ops + better op inference

[Gregor N. Purdy]

All --

In working to make Jako be able to handle while (i < 0) as well as
while (i < n), I added a bunch of integer and numerical comparison
ops. I also tinkered with the assembler's op inferencing to get it
to pick the ops I intended.

The attached patch also contains my label parsing fix to the
assembler (posted earlier by itself).

With this patch in place, I'll be able to commit the new Jako
compiler and updated examples.


Regards,

-- Gregor
 _ 
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)'  \

   Gregor N. Purdy  [EMAIL PROTECTED]
   Focus Research, Inc.http://www.focusresearch.com/
   8080 Beckett Center Drive #203   513-860-3570 vox
   West Chester, OH 45069   513-860-3579 fax
\_/

Re: coding standard

[Simon Cozens]

On Sat, Sep 15, 2001 at 03:11:33PM -0500, Gibbs Tanton - tgibbs wrote:
> Ok everyone, I have changed all of the .c and .h files to match the coding
> standard.  I also changed all instances of Perl_Interp to Parrot_Interp.  I
> want to give everyone a chance to yell NOOO
> before I commit.

This is cool. Commit it now, let people yell later. :)

-- 
 The dumb joke of the day is: "Call Microsoft. When the operator
answers, "Microsoft, may I help you?" respond: "I can't understand you.
You're breaking up."

Re: Minor "cleanup" patch to interpreter.*

[Simon Cozens]

On Sat, Sep 15, 2001 at 03:56:55PM -0400, Michael Fischer wrote:
> I also removed the DO_OP macro as it seems unnecessary
> for the current case, but perhaps I undervalue it?

You do. I'm suspecting that this will eventually be used
to construct machine-specific op dispatchers to help us
optimize for platforms where, say, a switch is better than
a function pointer call.

But I could be pulling that out of my ass.

Simon

[PATCH] testsuite

[Mattia Barbon]

> I have a question on your test suite.
 
> Would backticks not be more portable then trying to figure out how to
> redirect STDOUT on each OS?  To me, it would just be simpler to use the 
No, I don't need to "figure out", I just execute a
perl -e ".redirections...;system '$command'";
where redirections is a series of
close FH / open FH1, ">&FH2" / open FH, "file";
( the is_win32() ? "NUL:" : "/dev/null"; is the *only*
part that needs "figuring out", and can be ( at will )
substituted by and "open FH, "> junkfile_since_we_dont_have_devnull";

> --ouput flag of the assembler to create the .pbc file, and then use
> backticks to capture the output of the interpreter. 
Well, in the case of the assembler output flag, yes, but the problem 
is really STDERR [1], that is not captured by backticks. Now that I 
think of it, IPC::Open3 might do the trick nicely, but looking at
his page I fear that it could  actually be more difficult than it
seems [2], so I'll just stick with this ( unless someone has
better ideas, of course )

Regards
Mattia

[1] from perldoc perlop
Because backticks do not affect standard error, use shell file 
descriptor syntax (assuming the shell supports this) if you care to 
address this. To capture a command's STDERR and STDOUT together:

[2] from perldoc IPC::Open3
If you try to read from the child's stdout writer and their stderr 
writer, you'll have problems with blocking, which means you'll want 
to use {HYPERLINK "../../lib/Pod/perlfunc.html" \l 
"item_select"}select() or the IO::Select, which means you'd best use 
{HYPERLINK "../../lib/Pod/perlfunc.html" \l "item_sysread"}sysread() 
instead of {HYPERLINK "../../lib/Pod/perlfunc.html" \l 
"item_readline"}readline() for normal stuff.

RE: parrot compilation failure in Tru64

[Gibbs Tanton - tgibbs]

> Never mind 'portable' for now, currently it's not even *working* on
> 64-bit platforms

You might try putting an ! after the l in the assembler pack type and see if
that fixes things.  Right now, it is going to be putting opcodes out in 32
bits.  Since Tru64 is 64 bits, a long is going to be 64 bits.  Contrarywise,
you might also try using int as the IV type instead of long.

Tanton

Re: parrot compilation failure in Tru64

[Simon Cozens]

On Sat, Sep 15, 2001 at 08:43:19PM +0300, Jarkko Hietaniemi wrote:
> Never mind 'portable' for now, currently it's not even *working* on
> 64-bit platforms

That as may be, I'd like to make sure we start fixing it in the
right direction rather than the wrong one. :)

Simon

RE: coding standards

[Gibbs Tanton - tgibbs]

I don't know, I always liked seeing them separate.  I'll change it to $Id:$
to take up less space. 

-Original Message-
From: Russ Allbery
To: [EMAIL PROTECTED]
Sent: 9/15/2001 2:08 PM
Subject: Re: coding standards

Gibbs Tanton <- tgibbs <[EMAIL PROTECTED]>> writes:

>  *  CVS Info
>  * $RCSfile: $
>  * $Revision: $
>  * $Date: $

If you're going to include all that, why not just use $Id$, which
contains
all of that information?

-- 
Russ Allbery ([EMAIL PROTECTED])

Re: parrot compilation failure in Tru64

[Sam Tregar]

On Sat, 15 Sep 2001, Philip Kendall wrote:

> My personal view would be that the gains due to portable bytecode would
> be outweighed by the amount of cruft we'd have to put into the
> interpreter to get them. As Nicholas Clark and someone else who's name
> I've forgotten[1] mentioned, there are platforms (eg Cray) which don't
> have a native 32-bit integer type.

No cruft need go into the interpreter.  We can preprocess any given
bytecode format into a native format.  These preprocessors can be entirely
separate from the interpreter.

The gains here are pretty important - with a portable bytecode modules can
be distributed pre-compiled, bytecode can be generated on one platform and
used on another (think embedding) and all manner of network computing
silliness becomes possible.

Yes, some platforms will need some costly pre-processing in order to use
other platforms' bytecode.  However, the 95% case of just needing some
byte-swapping will work with almost no penalty at all.  The remaining 5%
that need to resize the data will still work, albeit with a startup
penalty.  Easy things easy, hard things possible, right?

-sam

[patch] A few fixes to the Jako compiler

[Gregor N. Purdy]

All --

If the assembler patch I submitted a little while ago goes in, I'll
commit these changes to the Jako compiler. They fix a bug in assignment
handling and add some more conditionals to while and if. Also it goes
back to using implicit opcodes in a few cases that were broken before
the assembler patch.


Regards,

-- Gregor
 _ 
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)'  \

   Gregor N. Purdy  [EMAIL PROTECTED]
   Focus Research, Inc.http://www.focusresearch.com/
   8080 Beckett Center Drive #203   513-860-3570 vox
   West Chester, OH 45069   513-860-3579 fax
\_/


Index: jako_compiler.pl
===
RCS file: /home/perlcvs/parrot/little_languages/jako_compiler.pl,v
retrieving revision 1.3
diff -u -r1.3 jako_compiler.pl
--- jako_compiler.pl2001/09/15 00:42:07 1.3
+++ jako_compiler.pl2001/09/15 19:05:42
@@ -202,27 +202,29 @@
   my $prefix = "_W$block_count";
   push @block_stack, { TYPE => 'while', NEXT => $line, PREFIX => $prefix };
 
-  #
-  # TODO: Note that the assembler wasn't inferring the opcode qualifiers, so we had
-  # to code them explicitly. We should remove the qualifiers as soon as the
-  # assembler is fixed.
-  #
-
   if ($cond =~ m/^(.*)\s*==\s*(.*)$/) {
 my @args = map_args($1, $2);
-printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "eq_i_ic", "$args[0], $args[1], 
${prefix}_REDO, ${prefix}_LAST";
+printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "eq", "$args[0], $args[1], 
+${prefix}_REDO, ${prefix}_LAST";
 printf "%s_REDO:\n", $prefix;
   } elsif ($cond =~ m/^(.*)\s*!=\s*(.*)$/) {
 my @args = map_args($1, $2);
-printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "ne_i_ic", "$args[0], $args[1], 
${prefix}_REDO, ${prefix}_LAST";
+printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "ne", "$args[0], $args[1], 
+${prefix}_REDO, ${prefix}_LAST";
 printf "%s_REDO:\n", $prefix;
   } elsif ($cond =~ m/^(.*)\s*<=\s*(.*)$/) {
 my @args = map_args($1, $2);
-printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "le_i_ic", "$args[0], $args[1], 
${prefix}_REDO, ${prefix}_LAST";
+printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "le", "$args[0], $args[1], 
+${prefix}_REDO, ${prefix}_LAST";
 printf "%s_REDO:\n", $prefix;
+  } elsif ($cond =~ m/^(.*)\s*<\s*(.*)$/) {
+my @args = map_args($1, $2);
+printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "lt", "$args[0], $args[1], 
+${prefix}_REDO, ${prefix}_LAST";
+printf "%s_REDO:\n", $prefix;
   } elsif ($cond =~ m/^(.*)\s*>=\s*(.*)$/) {
+my @args = map_args($1, $2);
+printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "ge", "$args[0], $args[1], 
+${prefix}_REDO, ${prefix}_LAST";
+printf "%s_REDO:\n", $prefix;
+  } elsif ($cond =~ m/^(.*)\s*>\s*(.*)$/) {
 my @args = map_args($1, $2);
-printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "ge_i_ic", "$args[0], $args[1], 
${prefix}_REDO, ${prefix}_LAST";
+printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "gt", "$args[0], $args[1], 
+${prefix}_REDO, ${prefix}_LAST";
 printf "%s_REDO:\n", $prefix;
   } else {
 printf(STDERR "jako: Syntax error. Unrecognized condition in while on line 
%d.\n", $line);
@@ -242,28 +244,30 @@
   my $prefix = "_I$block_count";
   push @block_stack, { TYPE => 'if', NEXT => $line, PREFIX => $prefix };
 
-  #
-  # TODO: Note that the assembler wasn't inferring the opcode qualifiers, so we had
-  # to code them explicitly. We should remove the qualifiers as soon as the
-  # assembler is fixed.
-  #
-
   if ($cond =~ m/^(.*)\s*==\s*(.*)$/) {
 my @args = map_args($1, $2);
-printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "eq_i_ic", "$args[0], $args[1], 
${prefix}_REDO, ${prefix}_LAST";
+printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "eq", "$args[0], $args[1], 
+${prefix}_REDO, ${prefix}_LAST";
 printf "%s_REDO:\n", $prefix;
   } elsif ($cond =~ m/^(.*)\s*!=\s*(.*)$/) {
 my @args = map_args($1, $2);
-printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "ne_i_ic", "$args[0], $args[1], 
${prefix}_REDO, ${prefix}_LAST";
+printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "ne", "$args[0], $args[1], 
+${prefix}_REDO, ${prefix}_LAST";
 printf "%s_REDO:\n", $prefix;
   } elsif ($cond =~ m/^(.*)\s*<=\s*(.*)$/) {
+my @args = map_args($1, $2);
+printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "le", "$args[0], $args[1], 
+${prefix}_REDO, ${prefix}_LAST";
+printf "%s_REDO:\n", $prefix;
+  } elsif ($cond =~ m/^(.*)\s*<\s*(.*)$/) {
 my @args = map_args($1, $2);
-printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "le_i_ic", "$args[0], $args[1], 
${prefix}_REDO, ${prefix}_LAST";
+printf "%-12s %-8s %s\n", "${prefix}_NEXT:", "lt", "$args[0], $args[1], 
+${prefix}_REDO, ${prefix}_LAST";
 printf "%s_REDO:\n", $prefix;
   } elsif ($cond =~ m/^(.

Re: coding standards

[Russ Allbery]

Gibbs Tanton <- tgibbs <[EMAIL PROTECTED]>> writes:

>  *  CVS Info
>  * $RCSfile: $
>  * $Revision: $
>  * $Date: $

If you're going to include all that, why not just use $Id$, which contains
all of that information?

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Microbenchmark JVM<->PVM

[Gregor N. Purdy]

Leon --

> Sky asked me if anyone had done any simple benchmarks comparing JVM
> and PVM at this point. Now, I know we're still at an early stage and
> haven't really looked at speed, but a trivial counting and simple
> arithmetic benchmark:

Here's an implementation of the code in Jako. I haven't checked in
the version of the compiler that compiles it yet because there's a
patch that needs to be applied to the assembler first. I'm also
attaching the bench.pasm file the compiler generates.


Regards,

-- Gregor
 _ 
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)'  \

   Gregor N. Purdy  [EMAIL PROTECTED]
   Focus Research, Inc.http://www.focusresearch.com/
   8080 Beckett Center Drive #203   513-860-3570 vox
   West Chester, OH 45069   513-860-3579 fax
\_/


#
# bench.jako
#
# Based on Bench.java posted to [EMAIL PROTECTED] by
# Leon Brocard <[EMAIL PROTECTED]> on 2001-09-15. Note that the
# only differences between the Java version and the Jako
# version are:
#
#   * 'var int ...' vs 'int ...' for variable declaration.
#
#   * The commented-out print line (which is simpler in Jako).
#
#   * The presence of the 'end' statement at the...well...at the
# end.
#
#   * The use of the variable n instead of the constant 1
# in the conditions of the while loops.
#
# Copyright (C) 2001 Gregor N. Purdy. All rights reserved.
# This program is free software. It is subject to the same
# license as Perl itself.
#

var int q = 1;
var int w = 1;
var int i = 1;
var int j = 1;

var int n = 1;

while (q < n) {
  w = 1;

  while (w < n) {
i++;
j += i;
w++;
#print("$q, $w\n");
  }

  q++;
}

end



# This file produced by the Jako Compiler
#
# bench.jako
#
# Based on Bench.java posted to [EMAIL PROTECTED] by
# Leon Brocard <[EMAIL PROTECTED]> on 2001-09-15. Note that the
# only differences between the Java version and the Jako
# version are:
#
#   * 'var int ...' vs 'int ...' for variable declaration.
#
#   * The commented-out print line (which is simpler in Jako).
#
#   * The presence of the 'end' statement at the...well...at the
# end.
#
#   * The use of the variable n instead of the constant 1
# in the conditions of the while loops.
#
# Copyright (C) 2001 Gregor N. Purdy. All rights reserved.
# This program is free software. It is subject to the same
# license as Perl itself.
#

# q: I1
 set  I1, 1
# w: I2
 set  I2, 1
# i: I3
 set  I3, 1
# j: I4
 set  I4, 1

# n: I5
 set  I5, 1

_W1_NEXT:lt   I1, I5, _W1_REDO, _W1_LAST
_W1_REDO:
 set  I2, 1

_W2_NEXT:lt   I2, I5, _W2_REDO, _W2_LAST
_W2_REDO:
 inc  I3
 add  I4, I4, I3
 inc  I2
#print("$q, $w\n");
 branch   _W2_NEXT
_W2_LAST:

 inc  I1
 branch   _W1_NEXT
_W1_LAST:

 end 

[patch] Small mod to assemble.pl to allow uppercase and underscoresin labels

[Gregor N. Purdy]

All --

The labels autogenerated by the Jako compiler use uppercase characters
and underscores. This patch makes the opcode inference logic in the
assembler happy with that situation. It also prints out the qualified
opcode it inferred when it fails to find a matching opcode.


Regards,

-- Gregor
 _ 
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)'  \

   Gregor N. Purdy  [EMAIL PROTECTED]
   Focus Research, Inc.http://www.focusresearch.com/
   8080 Beckett Center Drive #203   513-860-3570 vox
   West Chester, OH 45069   513-860-3579 fax
\_/


Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.21
diff -u -r1.21 assemble.pl
--- assemble.pl 2001/09/15 15:45:28 1.21
+++ assemble.pl 2001/09/15 18:37:07
@@ -121,7 +121,7 @@
} elsif(m/^((-?\d+)|(0b[01]+)|(0x[0-9a-f]+))$/i) {
# integer
push @arg_t,'ic';
-   } elsif(m/^[a-z][\w]*$/i) {
+   } elsif(m/^[A-Za-z_][\w]*$/i) {
# label
push @arg_t,'ic';
} else {
@@ -146,7 +146,7 @@
last;
}
}
-error("No opcode $opcode in <$_>") if(!$found_op);
+error("No opcode $opcode (tried $test) in <$_>") if(!$found_op);
 }
 if (@args != $opcodes{$opcode}{ARGS}) {
 error("Wrong arg count--got ".scalar(@args)." needed 
".$opcodes{$opcode}{ARGS});

Re: parrot compilation failure in Tru64

[Philip Kendall]

On Sat, Sep 15, 2001 at 06:33:18PM +0100, Simon Cozens wrote:
> 
> We also need to think about endianness. Urgh.
> 
> This is something I ought to seek consensus on. (And possibly a ruling from
> Dan.)
> 
> Do we *expect* Parrot bytecode to be portable? My gut reaction would be to
> say no, but I can see the arguments either way.

My personal view would be that the gains due to portable bytecode would
be outweighed by the amount of cruft we'd have to put into the
interpreter to get them. As Nicholas Clark and someone else who's name
I've forgotten[1] mentioned, there are platforms (eg Cray) which don't
have a native 32-bit integer type.

OTOH, my impression is that Dan is favouring at least some sort of
bytecode portability.

Phil

-- 
  Philip Kendall <[EMAIL PROTECTED]>
  http://www.srcf.ucam.org/~pak21/

RE: Difficulties

[Gibbs Tanton - tgibbs]

Oh yeah...good point...:)

This patch has been applied.
Thanks! 

-Original Message-
From: Will Coleda
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED] '
Sent: 9/15/2001 12:33 PM
Subject: Re: Difficulties

Um... with the current setup, there IS no Makefile until you run
Configure.pl, so I really don't see how that's possible. =-)

Gibbs Tanton - tgibbs wrote:
> 
> The README really doesn't have to mention Configure.pl because when
you do
> make test_prog it will run Configure.pl for you (at least it is
supposed to
> :)
 <> 

Re: parrot compilation failure in Tru64

[Jarkko Hietaniemi]

On Sat, Sep 15, 2001 at 06:33:18PM +0100, Simon Cozens wrote:
> On Sat, Sep 15, 2001 at 06:32:57PM +0100, Philip Kendall wrote:
> > I posted a couple of bodge fixes from this, but I haven't done much in
> > the past couple of days... do we want to use a 32 bit type for reading
> > in bytecode or convert the 32 bit on-disc format into a 64 bit format in
> > memory before reading it on a platform with 64 bit IVs?
> 
> We also need to think about endianness. Urgh.
> 
> This is something I ought to seek consensus on. (And possibly a ruling from
> Dan.)
> 
> Do we *expect* Parrot bytecode to be portable? My gut reaction would be to

Never mind 'portable' for now, currently it's not even *working* on
64-bit platforms

> say no, but I can see the arguments either way.
> 
> Simon

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

Re: parrot compilation failure in Tru64

[Simon Cozens]

On Sat, Sep 15, 2001 at 06:32:57PM +0100, Philip Kendall wrote:
> I posted a couple of bodge fixes from this, but I haven't done much in
> the past couple of days... do we want to use a 32 bit type for reading
> in bytecode or convert the 32 bit on-disc format into a 64 bit format in
> memory before reading it on a platform with 64 bit IVs?

We also need to think about endianness. Urgh.

This is something I ought to seek consensus on. (And possibly a ruling from
Dan.)

Do we *expect* Parrot bytecode to be portable? My gut reaction would be to
say no, but I can see the arguments either way.

Simon

Re: Difficulties

[Will Coleda]

Um... with the current setup, there IS no Makefile until you run
Configure.pl, so I really don't see how that's possible. =-)

Gibbs Tanton - tgibbs wrote:
> 
> The README really doesn't have to mention Configure.pl because when you do
> make test_prog it will run Configure.pl for you (at least it is supposed to
> :)

Re: parrot compilation failure in Tru64

[Philip Kendall]

On Sat, Sep 15, 2001 at 04:44:47PM +0100, Simon Cozens wrote:
> 
> And segfaults here:
> 
> (gdb) run test.pbc
> Starting program: /var/tmp/parrot/test_prog test.pbc
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x120007388 in read_constants_table (program_code=0x11b48) at bytecode.c:66
> 66  IV len = GRAB_IV(program_code);
> (gdb) quit
> 
> Don't know why. :(

[Apologies if this is out of date -- I'm currently massively behind on
 perl6-internals]

If this is with 64 bit IVs, this is the problem I hit a while back --
we're reading in 32 bit quantities from disc, but 64 bits at a time, so
everything goes completely pear shaped.

I posted a couple of bodge fixes from this, but I haven't done much in
the past couple of days... do we want to use a 32 bit type for reading
in bytecode or convert the 32 bit on-disc format into a 64 bit format in
memory before reading it on a platform with 64 bit IVs?

Cheers,

Phil

-- 
  Philip Kendall <[EMAIL PROTECTED]>
  http://www.srcf.ucam.org/~pak21/

Re: Parrot's mascot

[Rocco Caputo]

On Sat, Sep 15, 2001 at 02:27:22PM +0100, Simon Cozens wrote:
> On Fri, Sep 14, 2001 at 07:49:50PM -0400, Gregor N. Purdy wrote:
> > I'd like to suggest that the Parrot image we've seen associated with
> > Perl6 be 
> 
> this: http://pettalk.zapp.com.au/images/Africangrey.jpg

I can't seem to find a picture of a Norwegian Blue anywhere.

-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net

Re: Microbenchmark JVM<->PVM

[Jarkko Hietaniemi]

Don't have Blackdown installed but here are some timing and profiling
results (linux/x86, compiled with -pg, 'gprof test_prog' output,
remembering the caveat of profiling always skewing the measurements):

ugli:/tmp/jhi/parrot ; time ./test_prog j.pbc
r 119,14s u 119,14s s 0,00s 100% "./test_prog j.pbc"
ugli:/tmp/jhi/parrot ; 

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total   
 time   seconds   secondscalls  ms/call  ms/call  name
 33.82 19.3419.341 19340.00 57190.00  runops
 26.81 34.6715.33 99980001 0.00 0.00  Parrot_op_add_i
 22.33 47.4412.77 199970001 0.00 0.00  Parrot_op_inc_i
 17.05 57.19 9.75 1 0.00 0.00  Parrot_op_lt_i_ic
  0.00 57.19 0.0010003 0.00 0.00  Parrot_op_set_i
  0.00 57.19 0.001 0.00 0.00  Parrot_op_branch_ic
  0.00 57.19 0.006 0.00 0.00  Parrot_op_set_i_ic
  0.00 57.19 0.005 0.00 0.00  mem_allocate_aligned
  0.00 57.19 0.004 0.00 0.00  mem_sys_allocate
  0.00 57.19 0.001 0.00 0.00  Parrot_clear_p
  0.00 57.19 0.001 0.00 0.00  check_magic
  0.00 57.19 0.001 0.00 0.00  init_bytecode
  0.00 57.19 0.001 0.00 0.00  init_world
  0.00 57.19 0.001 0.00 0.00  make_interpreter
  0.00 57.19 0.001 0.00 0.00  mem_setup_allocator
  0.00 57.19 0.001 0.00 0.00  read_constants_table
  0.00 57.19 0.001 0.00 0.00  read_fixup_table
  0.00 57.19 0.001 0.00 0.00  string_compute_strlen
  0.00 57.19 0.001 0.00 0.00  string_init
  0.00 57.19 0.001 0.00 0.00  string_make
  0.00 57.19 0.001 0.00 0.00  string_native_compute_strlen
  0.00 57.19 0.001 0.00 0.00  string_native_vtable

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

Re: parrot compilation failure in Tru64

[Jarkko Hietaniemi]

On Sat, Sep 15, 2001 at 04:44:47PM +0100, Simon Cozens wrote:
> On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote:
> > The question is why was it wrong after a fresh checkout? (also in Linux)
> 
> No idea. Is make_op_header.pl run? Does op.h contain the #define's?
> 
> > Another observation is that after 'rm op.h; make op.h' the thing
> > builds but with some gnashing of the teeth:
> 
> And segfaults here:
> 
> (gdb) run test.pbc
> Starting program: /var/tmp/parrot/test_prog test.pbc
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x120007388 in read_constants_table (program_code=0x11b48) at bytecode.c:66
> 66  IV len = GRAB_IV(program_code);
> (gdb) quit
> 
> Don't know why. :(

I think it's very simply that one cannot deref a void** as a long*,
because of memory alignment restrictions (MEM_ALIGNBYTES is 8 in alpha).

> Simon

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

Re: parrot compilation failure in Tru64

[Jarkko Hietaniemi]

On Sat, Sep 15, 2001 at 04:44:47PM +0100, Simon Cozens wrote:
> On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote:
> > The question is why was it wrong after a fresh checkout? (also in Linux)
> 
> No idea. Is make_op_header.pl run? Does op.h contain the #define's?

This is eerie-- I now did a fresh checkout both on Tru64 and Linux
and op.h gets rebuilt correctly.  I suspect gremlins.

> > Another observation is that after 'rm op.h; make op.h' the thing
> > builds but with some gnashing of the teeth:

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

Re: parrot compilation failure in Tru64

[Jarkko Hietaniemi]

On Sat, Sep 15, 2001 at 04:44:47PM +0100, Simon Cozens wrote:
> On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote:
> > The question is why was it wrong after a fresh checkout? (also in Linux)
> 
> No idea. Is make_op_header.pl run? Does op.h contain the #define's?

I'll try a new checkout.

> > Another observation is that after 'rm op.h; make op.h' the thing
> > builds but with some gnashing of the teeth:
> 
> And segfaults here:
> 
> (gdb) run test.pbc
> Starting program: /var/tmp/parrot/test_prog test.pbc
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x120007388 in read_constants_table (program_code=0x11b48) at bytecode.c:66
> 66  IV len = GRAB_IV(program_code);
> (gdb) quit
> 
> Don't know why. :(

Well, GRAB_IV looks suspiciously unportable to me.  Will investigate.

> Simon

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

Re: parrot compilation failure in Tru64

[Simon Cozens]

On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote:
> The question is why was it wrong after a fresh checkout? (also in Linux)

No idea. Is make_op_header.pl run? Does op.h contain the #define's?

> Another observation is that after 'rm op.h; make op.h' the thing
> builds but with some gnashing of the teeth:

And segfaults here:

(gdb) run test.pbc
Starting program: /var/tmp/parrot/test_prog test.pbc

Program received signal SIGSEGV, Segmentation fault.
0x120007388 in read_constants_table (program_code=0x11b48) at bytecode.c:66
66  IV len = GRAB_IV(program_code);
(gdb) quit

Don't know why. :(

Simon

Re: parrot compilation failure in Tru64

[Jarkko Hietaniemi]

On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote:
> On Sat, Sep 15, 2001 at 04:35:49PM +0100, Simon Cozens wrote:
> > On Sat, Sep 15, 2001 at 06:18:38PM +0300, Jarkko Hietaniemi wrote:
> > >  do { foo [ 0 ] = end ; foo [ 1 ] = set_i_ic ; foo [ 2 ] = set_i ; foo [ 3 ] 
>= add_i ; foo [ 4 ] = sub_i ; foo [ 5 ] = mul_i ; foo [ 6 ] = div_i ; foo [ 7 ] = ...
> > 
> > Your op.h needs rebuilding. It builds fine on Tru64 here.
> 
> The question is why was it wrong after a fresh checkout? (also in Linux)
> 
> Another observation is that after 'rm op.h; make op.h' the thing
> builds but with some gnashing of the teeth:
> 
> cc: Warning: interpreter.c, line 97: In this statement, the referenced type of the 
>pointer value "Parrot_op_end" is "function (pointer to long, pointer to struct 
>Perl_Interp) returning pointer to long", which is not compatible with "void". 
>(ptrmismatch)
> BUILD_TABLE(foo);
> ^

Urgle.  Celebrated too early -- it builds but then:

kosh:/tmp/jhi/parrot ; ./test_prog test.pbc   
zsh: 5870 segmentation fault (core dumped)  ./test_prog test.pbc
kosh:/tmp/jhi/parrot ; gdb ./test_prog core.test_prog.kosh.0 
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (alpha-dec-osf4.0), Copyright 1996 Free Software Foundation, Inc...
Core was generated by `test_prog'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/shlib/libgdbm.so...done.
Reading symbols from /usr/shlib/libdb.so...done.
Reading symbols from /usr/shlib/libm.so...done.
Reading symbols from /usr/shlib/libiconv.so...done.
Reading symbols from /usr/shlib/libc.so...done.
#0  0x120007748 in read_constants_table (program_code=0x11408)
at bytecode.c:66
66 IV len = GRAB_IV(program_code);
(gdb) where
#0  0x120007748 in read_constants_table (program_code=0x11408)
at bytecode.c:66
#1  0x120007950 in init_bytecode (program_code=0x8000101b8) at bytecode.c:154
#2  0x120008434 in main (argc=2, argv=0x114c8) at test_main.c:75
(gdb) 

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

RE: Difficulties

[Gibbs Tanton - tgibbs]

 
I haven't had any problem with my instead of use vars...can you send me the
test program that blows up?
-Original Message-
From: Uri Guttman
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: 9/15/2001 8:57 AM
Subject: Re: Difficulties

> "BD" == Brent Dax <[EMAIL PROTECTED]> writes:

  BD> use vars qw(%opcode $fingerprint);#or strict will throw a
tantrum

so why didn't 'my' work. those are file globals from what i can tell. my
causes interpreter.c to blow up. use vars fixes it.

uri


-- 
Uri Guttman  -  [EMAIL PROTECTED]  --
http://www.sysarch.com
SYStems ARCHitecture and Stem Development --
http://www.stemsystems.com
Search or Offer Perl Jobs  --
http://jobs.perl.org

Re: parrot compilation failure in Tru64

[Jarkko Hietaniemi]

On Sat, Sep 15, 2001 at 04:35:49PM +0100, Simon Cozens wrote:
> On Sat, Sep 15, 2001 at 06:18:38PM +0300, Jarkko Hietaniemi wrote:
> >  do { foo [ 0 ] = end ; foo [ 1 ] = set_i_ic ; foo [ 2 ] = set_i ; foo [ 3 ] = 
>add_i ; foo [ 4 ] = sub_i ; foo [ 5 ] = mul_i ; foo [ 6 ] = div_i ; foo [ 7 ] = ...
> 
> Your op.h needs rebuilding. It builds fine on Tru64 here.

The question is why was it wrong after a fresh checkout? (also in Linux)

Another observation is that after 'rm op.h; make op.h' the thing
builds but with some gnashing of the teeth:

cc: Warning: interpreter.c, line 97: In this statement, the referenced type of the 
pointer value "Parrot_op_end" is "function (pointer to long, pointer to struct 
Perl_Interp) returning pointer to long", which is not compatible with "void". 
(ptrmismatch)
BUILD_TABLE(foo);
^

> Simon

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

Re: parrot compilation failure in Tru64

[Jarkko Hietaniemi]

Well, I must have checked out at a bad moment since Linux+gcc 2.95.2
is not faring much better:

make test_prog|&head
cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -I..-c -o interpreter.o interpreter.c
interpreter.c: In function `make_interpreter':
interpreter.c:97: `end' undeclared (first use in this function)
interpreter.c:97: (Each undeclared identifier is reported only once
interpreter.c:97: for each function it appears in.)
interpreter.c:97: `set_i_ic' undeclared (first use in this function)
interpreter.c:97: `set_i' undeclared (first use in this function)
interpreter.c:97: `add_i' undeclared (first use in this function)
interpreter.c:97: `sub_i' undeclared (first use in this function)
interpreter.c:97: `mul_i' undeclared (first use in this function)
...

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

Re: parrot compilation failure in Tru64

[Simon Cozens]

On Sat, Sep 15, 2001 at 06:18:38PM +0300, Jarkko Hietaniemi wrote:
>  do { foo [ 0 ] = end ; foo [ 1 ] = set_i_ic ; foo [ 2 ] = set_i ; foo [ 3 ] = 
>add_i ; foo [ 4 ] = sub_i ; foo [ 5 ] = mul_i ; foo [ 6 ] = div_i ; foo [ 7 ] = ...

Your op.h needs rebuilding. It builds fine on Tru64 here.

Simon

Re: RFC: Bytecode file format

[Jarkko Hietaniemi]

On Sat, Sep 15, 2001 at 04:17:34PM +0100, Nicholas Clark wrote:
> On Fri, Sep 14, 2001 at 06:11:35PM -0400, Dan Sugalski wrote:
> > What we're doing is making sure the common case, the bytecode on disk being 
> > used by the platform that owns the drive, is as fast as possible. We're 
> > also making sure that we don't make it so you can't trade bytecode files 
> > around, nor that you can't mount the same filesystem with perl utility code 
> > on your Solaris, HP-UX, Tru64, and x86 Linux systems simultaneously.
> 
> Will we be able to make "FAT" binaries for these cases, so that 1 file
> can have more than 1 type of bytecode in it for the various platforms
> that will mount the common files?

It's pretty much up to the bytecode loader.  If we design the format
right the loader can just keep skipping sections until it finds
headers that it feels comfortable with.

> Nicholas Clark

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

parrot compilation failure in Tru64

[Jarkko Hietaniemi]

[just (Sat 11:15 EET) checked-out copy]

(After running Configure.pl) make test_prog halts at:

cc -std -fprm d -ieee -D_INTRINSICS -DLANGUAGE_C -I..-c -o interpreter.o 
interpreter.c
cc: Error: interpreter.c, line 97: In this statement, "end" is not declared. 
(undeclared)
BUILD_TABLE(foo);
^
cc: Error: interpreter.c, line 97: In this statement, "set_i_ic" is not declared. 
(undeclared)
BUILD_TABLE(foo);
^

and so on for each and every op.  Looking at the preprocessed code:

  {
void **foo;
foo = mem_sys_allocate(2048 * sizeof(void *));

 do { foo [ 0 ] = end ; foo [ 1 ] = set_i_ic ; foo [ 2 ] = set_i ; foo [ 3 ] = 
add_i ; foo [ 4 ] = sub_i ; foo [ 5 ] = mul_i ; foo [ 6 ] = div_i ; foo [ 7 ] = ...

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

Re: Microbenchmark JVM<->PVM

[Dan Sugalski]

At 09:23 PM 9/15/2001 +0900, Masatake E. Hori wrote:
> > piglet$ time java Bench
> > 1.470u 0.080s 0:01.59 97.4%   0+0k 0+0io 5784pf+0w
> > piglet$ time ./test_prog run.pbc
> > 40.080u 0.030s 0:42.07 95.3%  0+0k 0+0io 137pf+0w
>
>Maybe you got a Just-In-Time compiler?
>I turned mine off and I got,
>
>hamlet{193}: time java Bench
>16.442u 0.093s 0:22.88 72.2%16+2233k 0+0io 0pf+0w
>
>hamlet{288}: time ./test_prog test.pbc
>23.373u 0.015s 0:31.59 74.0%20+248k 0+0io 1pf+0w
>
>Still, a little slower.

Slower, but better. We'll work on that. I can think of a few things to 
speed this up--I'll poke around some.

Could someone throw a -O3 in the makefile CFLAGS, rebuild Parrot, and time 
again?

Dan

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

Re: Difficulties

[Uri Guttman]

> "BD" == Brent Dax <[EMAIL PROTECTED]> writes:

  BD> use vars qw(%opcode $fingerprint);#or strict will throw a tantrum

so why didn't 'my' work. those are file globals from what i can tell. my
causes interpreter.c to blow up. use vars fixes it.

uri


-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Search or Offer Perl Jobs  --  http://jobs.perl.org

Re: Difficulties

[Uri Guttman]

> "WC" == Will Coleda <[EMAIL PROTECTED]> writes:

  WC> The README doesn't mention Configure.pl (minor doc patch follows), and
  WC> Parrot::Opcode is requiring perl5.6, which makes my 5.5.3 quite unhappy. 

i noticed both of those problems.

i found Opcode.pm has a use 5.6.0 and it uses our. i don't see a need
for our there when my will do. dan replied to me and said parrot should
work from 5.004_04.

  WC> Are folks intentially using 5.6 constructs? I'll consider
  WC> generating a patch to make things work with 5.5.3 if this was an
  WC> act of convenience rather than benevolent despotism. =-)

here is a patch for that. (my first one!)

uri


Index: Parrot/Opcode.pm
===
RCS file: /home/perlcvs/parrot/Parrot/Opcode.pm,v
retrieving revision 1.3
diff -u -r1.3 Opcode.pm
--- Parrot/Opcode.pm2001/09/15 00:57:42 1.3
+++ Parrot/Opcode.pm2001/09/15 13:47:26
@@ -1,12 +1,12 @@
 package Parrot::Opcode;
 
-use 5.6.0;
+use 5.004 ;
 use strict;
 use Symbol;
 use Digest::MD5 qw(&md5_hex);
 
-our %opcode;
-our $fingerprint;
+my %opcode;
+my $fingerprint;
 
 sub _load {
 my $file = @_ ? shift : "opcode_table";




-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Search or Offer Perl Jobs  --  http://jobs.perl.org

Re: Parrot's mascot

[Simon Cozens]

On Fri, Sep 14, 2001 at 07:49:50PM -0400, Gregor N. Purdy wrote:
> I'd like to suggest that the Parrot image we've seen associated with
> Perl6 be 

this: http://pettalk.zapp.com.au/images/Africangrey.jpg

Simon

Re: Internet Virtual Machine?

[Simon Cozens]

On Sat, Sep 15, 2001 at 04:14:16PM +0300, Jarkko Hietaniemi wrote:
> On Sat, Sep 15, 2001 at 01:34:06AM -0700, Randal L. Schwartz wrote:
> > So is there anything we can leverage from
> > http://ivm.sourceforge.net/
> 
> They use the word 'empower'.   I think they lost the credibility game
> right there.

But Randal used 'leverage', so I think that makes us even.

Re: RFC: Bytecode file format

[Jarkko Hietaniemi]

On Fri, Sep 14, 2001 at 04:42:21PM -0400, Dan Sugalski wrote:
> At 03:10 PM 9/14/2001 -0500, Brian Wheeler wrote:
> >I've been thinking alot about the bytecode file format lately.  Its
> >going to get really gross really fast when we start adding other
> >(optional) sections to the code.
> >
> >So, with that in mind, here's what I propose:
> >
> >* All data sizes are in longwords (4 bytes) because that's just the way
> >things are :)
> 
> Nope. At the very least, a bytecode file needs to start with:
> 
> 8-byte word:endianness (magic value 0x123456789abcdef0)

Actually I think that if we use the magic word 0x01234567abcdef
(and 0x01234567 on 32-bit platforms) we can more easily do the
appropriate byte shuffling in the bytecode translator.

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

RE: [PATCH] testsuite and Win32 compilation

[Benjamin Stuhl]

--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Gibbs Tanton - tgibbs:
> # ## +#if defined(WIN32)
> # ## +program_code = malloc( file_stat.st_size );
> # ## +#else
> #
> # Also, since more than win32 is not going to have mmap,
> # perhaps you could add
> # a Configure #define for HAS_MMAP or something like
> that.
> # Then you could
> # test the cc compiler to check for mmap availability.
> 
> Configure sets up a bunch of HAS_HEADER_FOO macros in
> parrot/config.h,
> including HAS_HEADER_MEMORY (undef on my Win32 system). 
> Would this be
> the correct file?

I'd recommend HAS_HEADER_SYSMMAN (and if anyone saw it, I
posted a patch yesterday that started making header
includes actually be dependent on the configure macros).

-- BKS

__
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

Re: Microbenchmark JVM<->PVM

[Masatake E. Hori]

> piglet$ time java Bench
> 1.470u 0.080s 0:01.59 97.4%   0+0k 0+0io 5784pf+0w
> piglet$ time ./test_prog run.pbc
> 40.080u 0.030s 0:42.07 95.3%  0+0k 0+0io 137pf+0w

Maybe you got a Just-In-Time compiler?
I turned mine off and I got,

hamlet{193}: time java Bench
16.442u 0.093s 0:22.88 72.2%16+2233k 0+0io 0pf+0w

hamlet{288}: time ./test_prog test.pbc
23.373u 0.015s 0:31.59 74.0%20+248k 0+0io 1pf+0w

Still, a little slower.


University of Tsukuba, Institute of Geoscience, Doctoral Program.
Masatake Edward Hori ([EMAIL PROTECTED])

Re: Microbenchmark JVM<->PVM

[Leon Brocard]

Masatake E. Hori sent the following bits through the ether:

> > piglet$ time java Bench
> > 1.470u 0.080s 0:01.59 97.4% 0+0k 0+0io 5784pf+0w
> > piglet$ time ./test_prog run.pbc
> > 40.080u 0.030s 0:42.07 95.3%0+0k 0+0io 137pf+0w
> 
> Maybe you got a Just-In-Time compiler?

Oh, I hadn't realised blackdown had that. Now a smaller difference:

[acme@piglet parrot]$ time java -Xint Bench
16.430u 0.080s 0:18.17 90.8%0+0k 0+0io 5783pf+0w

Didn't want to panic you all, Leon
-- 
Leon Brocard.http://www.astray.com/
Iterative Software...http://www.iterative-software.com/

... ebius tagline. This is a moebius tagline. This is a mo...

Re: Microbenchmark JVM<->PVM

[Simon Cozens]

On Sat, Sep 15, 2001 at 12:16:55PM +0100, Leon Brocard wrote:
> piglet$ time java Bench
> 1.470u 0.080s 0:01.59 97.4%   0+0k 0+0io 5784pf+0w
> piglet$ time ./test_prog run.pbc
> 40.080u 0.030s 0:42.07 95.3%  0+0k 0+0io 137pf+0w

We're really 40 times slower than Blackdown? Shite. What're
we doing wrong?

Simon

Re: coding standards

[Simon Cozens]

On Fri, Sep 14, 2001 at 11:45:36PM -0500, Gibbs Tanton - tgibbs wrote:
> Sorry...forgot the tabs...this one should be right. 

Thanks, applied.

Re: HOLD IT!

[Simon Cozens]

On Sat, Sep 15, 2001 at 01:44:25AM -0700, Brent Dax wrote:
> We're getting lost in a maze of twisty little Configure versions, all
> different.  Can we get a freeze on changes to Configure and associated
> files until we can get this sorted out?

You're the Configure pumpking. I'll only take changes to Configure
from you. Does that make sense?

Simon

Microbenchmark JVM<->PVM

[Leon Brocard]

Sky asked me if anyone had done any simple benchmarks comparing JVM
and PVM at this point. Now, I know we're still at an early stage and
haven't really looked at speed, but a trivial counting and simple
arithmetic benchmark:

piglet$ time java Bench
1.470u 0.080s 0:01.59 97.4% 0+0k 0+0io 5784pf+0w
piglet$ time ./test_prog run.pbc
40.080u 0.030s 0:42.07 95.3%0+0k 0+0io 137pf+0w

Source files attached so I can humiliate myself in public at a later
stage when someone points out I've done something stupid

Leon

ps my jvm is j2sdk-1.3.1-FCS from blackdown on linux
ps2 oh, and are we calling it pvm? parrotvm?
-- 
Leon Brocard.http://www.astray.com/
Iterative Software...http://www.iterative-software.com/

... I am serious. And don't call me Shirley


class Bench {
public static void main (String args[]) {
int q = 1;
int w = 1;
int i = 1;
int j = 1;
while(q < 1) {
w = 1;
while(w < 1) {
i++;
j += i;
w++;
//  System.out.print(q + ", " + w + "\n");
}
q++;
}
}
}



set_i_ic I1, 1
set_i I63, I1
set_i_ic I1, 1
set_i I62, I1
set_i_ic I1, 1
set_i I61, I1
set_i_ic I1, 1
set_i I60, I1
set I4, 1
set I7, 1
branch_ic LAAA
LAAE:   set_i I62, 1
branch_ic LAAB
LAAC:   inc_i I61
add_i I60, I60, I61
inc_i I62
LAAB:   lt_i_ic I62, I4, LAAC, LAAD
LAAD:   inc_i I63
LAAA:   lt_i_ic I63, I7, LAAE, LAAF
LAAF:   end

RE: [PATCH] testsuite and Win32 compilation

[Mattia Barbon]

> ## +#if defined(WIN32)
> ## +program_code = malloc( file_stat.st_size );
> ## +#else
> 
> #Should we be using malloc, or are we supposed to use our own allocator?
> #(I haven't been munging in the C, so I don't really know--it just looks
> #a little suspicious.)
> 
> In memory.{h,c} there is a mem_sys_allocate(IV) that I would suggest.
Of course you're right.
New patch Attached

The attached patch replaces things.diff ( testsuite.diff should be
OK )

Regards
Mattia


The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

    File information ---
 File:  win32.diff
 Date:  15 Sep 2001, 10:35
 Size:  5043 bytes.
 Type:  Unknown

 win32.diff

Re: RFC: Bytecode file format

[Leon Brocard]

Simon Cozens sent the following bits through the ether:

> If you don't know what Python's CodeObjects look like, I suggest
> you go see it now.

I've been spendind a lot of time recently looking at the Java
classfile specification. Yes, they were trying to optimise for space,
but there are some interesting pieces. For example, the actual
bytecode for a method is a "Code" attribute[1] attached to the method
(other attributes such as line number information etc. can also be
part of it). The constant pool is the scary part, but interesting. Why
not have a look, although we may want to generalise a bit more:

http://java.sun.com/docs/books/vmspec/html/ClassFile.doc.html

Leon

[1] No, attributes aren't limited to four characters. Let's
be modern about this...
-- 
Leon Brocard.http://www.astray.com/
Iterative Software...http://www.iterative-software.com/

... Error 15 - Unable to exit Windows. Try the door

RE: Difficulties

[Brent Dax]

Damien Neil:
# On Sat, Sep 15, 2001 at 01:52:26AM -0700, Brent Dax wrote:
# > use vars qw(%opcode $fingerprint);  #or strict will throw a tantrum
# 
# Not necessary--the patch changes those variables to lexicals.
# There wasn't any strong reason for them to be package vars.

Oh, duh... *smacks his forehead*

--Brent Dax
[EMAIL PROTECTED]

They *will* pay for what they've done.

Re: Difficulties

[Damien Neil]

On Sat, Sep 15, 2001 at 01:52:26AM -0700, Brent Dax wrote:
> use vars qw(%opcode $fingerprint);#or strict will throw a tantrum

Not necessary--the patch changes those variables to lexicals.
There wasn't any strong reason for them to be package vars.

   - Damien

RE: Difficulties

[Brent Dax]

Damien Neil:
# On Sat, Sep 15, 2001 at 01:15:57AM -0700, Brent Dax wrote:
# > As for the 5.6 thing...I think we're supposed to support 5.005 and
# > above.  Can you tell what Parrot::Opcode needs it for?  
# (And if it's for
# > 'our', I'm going to punch someone... :^) )
# 
# Er...I think it IS for our, actually. :>  I'm so used to using it, I
# didn't realize I was introducing a 5.6ism.  The silly thing is, I
# deliberately avoided using "open(my $fh, $file)" to keep from 
# requiring
# 5.6...

*THWAP*

# I notice that someone did add a "use 5.6.0" to Parrot::Opcode--here's
# a patch which removes it, and the offending ours.
# 
# Index: Parrot/Opcode.pm
# ===
# RCS file: /home/perlcvs/parrot/Parrot/Opcode.pm,v
# retrieving revision 1.3
# diff -u -r1.3 Opcode.pm
# --- Parrot/Opcode.pm  2001/09/15 00:57:42 1.3
# +++ Parrot/Opcode.pm  2001/09/15 08:33:48
# @@ -1,12 +1,11 @@
#  package Parrot::Opcode;
#  
# -use 5.6.0;
#  use strict;
#  use Symbol;
#  use Digest::MD5 qw(&md5_hex);

use vars qw(%opcode $fingerprint);  #or strict will throw a tantrum

#  
# -our %opcode;
# -our $fingerprint;
# +my %opcode;
# +my $fingerprint;
#  
#  sub _load {
#  my $file = @_ ? shift : "opcode_table";

--Brent Dax
[EMAIL PROTECTED]

They *will* pay for what they've done.

Re: Difficulties

[Damien Neil]

On Sat, Sep 15, 2001 at 01:15:57AM -0700, Brent Dax wrote:
> As for the 5.6 thing...I think we're supposed to support 5.005 and
> above.  Can you tell what Parrot::Opcode needs it for?  (And if it's for
> 'our', I'm going to punch someone... :^) )

Er...I think it IS for our, actually. :>  I'm so used to using it, I
didn't realize I was introducing a 5.6ism.  The silly thing is, I
deliberately avoided using "open(my $fh, $file)" to keep from requiring
5.6...

I notice that someone did add a "use 5.6.0" to Parrot::Opcode--here's
a patch which removes it, and the offending ours.

   - Damien


Index: Parrot/Opcode.pm
===
RCS file: /home/perlcvs/parrot/Parrot/Opcode.pm,v
retrieving revision 1.3
diff -u -r1.3 Opcode.pm
--- Parrot/Opcode.pm2001/09/15 00:57:42 1.3
+++ Parrot/Opcode.pm2001/09/15 08:33:48
@@ -1,12 +1,11 @@
 package Parrot::Opcode;
 
-use 5.6.0;
 use strict;
 use Symbol;
 use Digest::MD5 qw(&md5_hex);
 
-our %opcode;
-our $fingerprint;
+my %opcode;
+my $fingerprint;
 
 sub _load {
 my $file = @_ ? shift : "opcode_table";

Internet Virtual Machine?

[Randal L. Schwartz]

So is there anything we can leverage from

http://ivm.sourceforge.net/

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

RE: [PATCH] testsuite and Win32 compilation

[Brent Dax]

Gibbs Tanton - tgibbs:
# ## +#if defined(WIN32)
# ## +program_code = malloc( file_stat.st_size );
# ## +#else
#
# Also, since more than win32 is not going to have mmap,
# perhaps you could add
# a Configure #define for HAS_MMAP or something like that.
# Then you could
# test the cc compiler to check for mmap availability.

Configure sets up a bunch of HAS_HEADER_FOO macros in parrot/config.h,
including HAS_HEADER_MEMORY (undef on my Win32 system).  Would this be
the correct file?

--Brent Dax
[EMAIL PROTECTED]

They *will* pay for what they've done.

HOLD IT!

[Brent Dax]

We're getting lost in a maze of twisty little Configure versions, all
different.  Can we get a freeze on changes to Configure and associated
files until we can get this sorted out?

--Brent Dax
[EMAIL PROTECTED]

They *will* pay for what they've done.

RE: Difficulties

[Brent Dax]

Will Coleda:
# The README doesn't mention Configure.pl (minor doc patch follows), and
# Parrot::Opcode is requiring perl5.6, which makes my 5.5.3
# quite unhappy.

I think I sent in a patch to README to mention Configure.pl yesterday.
Let's see if I can find it...

# From: Brent Dax [mailto:[EMAIL PROTECTED]]
# Sent: Friday, September 14, 2001 12:17
# To: [EMAIL PROTECTED]
# Subject: [patch README] Update README to reflect new Configure script
#
#
# --- c:\old_parrot\READMEFri Sep 14 12:13:42 2001
# +++ README  Mon Sep 10 09:56:28 2001
# @@ -34,11 +34,6 @@
#  For now, unpack your Parrot tarball, (if you're reading this, you've
#  probably already done that) type
#
# +   perl Configure.pl
# +
# +to run the Configure script.  This will generate a config.h header, a
# +Parrot::Config module, and a Makefile.  Next type
# +
#  make test_prog
#
#  and the test interpreter should build.

Did nobody notice this?  If so, why not?

As for the 5.6 thing...I think we're supposed to support 5.005 and
above.  Can you tell what Parrot::Opcode needs it for?  (And if it's for
'our', I'm going to punch someone... :^) )

--Brent Dax
[EMAIL PROTECTED]

They *will* pay for what they've done.

RE: [proposed] Moving *.h to include/parrot/ right away

[Brent Dax]

Gregor N. Purdy:
# With the appropriate modification to Makefile.in as well (diff
# attached)? I don't remember seeing anyone particularly upset by it.
# [[ UPDATE: REALLY ATTACHED THIS TIME ]]

The correct modification isn't in Makefile.in, it's in Configure.pl.
You'll want to change

ccflags => $Config{ccflags}

to

#ADD NEW C COMPILER FLAGS HERE
#Just add any additional flags into the quote marks.
#Leave any flags currently there as-is unless you're
#replacing them with something better.
ccflags => $Config{ccflags}." -I./include"

.  (I'm not giving a diff here because it seems that things have gotten
really out of whack with Configure and associated files--everyone seems
to have their own versions floating around.)  I also suggest we change
the line in Makefile.in that looks something like:

C_FLAGS = ${ccflags}

to exactly

#DO NOT ADD FLAGS HERE
#Add them in Configure.pl--search for the comment "ADD NEW C COMPILER
FLAGS HERE"
C_FLAGS = ${ccflags}

so people don't keep making the same mistakes.

# If not, I'd be happy to do it. It'll take just a few minutes...

I suggest you create the new directory structure in a tarball first, and
send it to myself and anyone else who's interested in this so we can
check it before you commit.  This is a large change in the layout; there
are a thousand subtle ways to mess up without noticing it immediately.
Many eyes make bugs shallow, right? :^)

--Brent Dax
[EMAIL PROTECTED]

They *will* pay for what they've done.