Jako patch
This enables typecasting between I and N registers, fixes up the
error messages, and makes var num not require an assignment.
I note that some pseudo-ops don't work, and mod doesn't work
as a pseudo op with a constant; nor does pow and similar functions
work at all. :( Thinking about how to make these better...
Simon
? factor.jako
Index: jakoc
===
RCS file: /home/perlcvs/parrot/little_languages/jakoc,v
retrieving revision 1.5
diff -d -u -r1.5 jakoc
--- jakoc 2001/09/17 12:49:31 1.5
+++ jakoc 2001/09/18 09:11:46
@@ -339,7 +339,18 @@
if ($ident{$name}) {
if ($type eq '*') {
if ($ident{$value}) {
-printf %-12s %-8s %s\n, '', 'set', $ident{$name}{REG},
$ident{$value}{REG};
+if ($ident{$name}{TYPE} ne $ident{$value}{TYPE}) {
+ if ($ident{$name}{TYPE} eq N and $ident{$value}{TYPE} eq I) {
+printf %-12s %-8s %s\n, '', 'iton', $ident{$name}{REG},
+$ident{$value}{REG};
+ } elsif ($ident{$name}{TYPE} eq I and $ident{$value}{TYPE} eq N) {
+printf %-12s %-8s %s\n, '', 'ntoi', $ident{$name}{REG},
+$ident{$value}{REG};
+ } else {
+printf(STDERR jako: Cannot assign type '%s' to type '%s' on line %d.\n,
+$ident{$value}{TYPE}, $ident{$name}{TYPE}, $line);
+ }
+} else {
+printf %-12s %-8s %s\n, '', 'set', $ident{$name}{REG},
+$ident{$value}{REG};
+}
} else {
printf(STDERR jako: Assignment from undefined variable '%s' on line %d.\n,
$value, $line);
@@ -402,7 +413,7 @@
printf %-12s %-8s %s\n, '', $name, $arg;
}
} else {
-printf(STDERR jako: Unrecognized function '$name' on line %d.\n, $name, $line);
+printf(STDERR jako: Unrecognized function '%s' on line %d.\n, $name, $line);
}
}
@@ -419,7 +430,7 @@
@args = map_args($dest, @args);
printf %-12s %-8s %s\n, '', $name, join(, , @args);
} else {
-printf(STDERR jako: Unrecognized function '$name' on line %d.\n, $name, $line);
+printf(STDERR jako: Unrecognized function '%s' on line %d.\n, $name, $line);
}
}
@@ -675,7 +686,7 @@
#
if ((m/^var\s+(i)nt(eger)?\s+([A-Za-z][A-Za-z0-9_]*)(\s*=\s*(\d+))?$/) ||
- (m/^var\s+(n)um(ber)?\s+([A-Za-z][A-Za-z0-9_]*)(\s*=\s*(\d+(\.\d+)))$/) ||
+ (m/^var\s+(n)um(ber)?\s+([A-Za-z][A-Za-z0-9_]*)(\s*=\s*(\d+(\.\d+)))?$/) ||
(m/^var\s+(s)tr(ing)?\s+([A-Za-z][A-Za-z0-9_]*)(\s*=\s*(\[^\\\]*(?:\\.[^\\\]*)*\))?$/))
{
declare_var($3, uc($1));
assign_var($3, uc($1), $5) if defined $5;
--
Reporter (to Mahatma Gandhi): Mr Gandhi, what do you think of Western
Civilization?
Gandhi: I think it would be a good idea.
Re: cvs snapshots
On Tue 18 Sep 2001 10:52, Mattia Barbon [EMAIL PROTECTED] wrote: On Tue, 18 Sep 2001, H.Merijn Brand wrote: On Mon 17 Sep 2001 23:08, Ask Bjoern Hansen [EMAIL PROTECTED] wrote: oops, I forgot to tell anyone. I made CVS export and tar up a snapshot every 6 hours. It is available at http://cvs.perl.org/snapshots/parrot/ Any chance on rsync? If so, I might set up another smoke suite to bother you with reports :) I wantd it too ( just waited for the Win32 changes to be integrated int the perl one, to do a thing at a time ), but I can start sooner, of course If Mattia keeps the test suite in shape, I /will/ try to initiate a smoke. At first this sounds simple, but when the base conf uses the perl conf that is used for the perl that is called on configure.pl, I will either have to change some of the flags used (for 64bit env's) or rebuilt perl for each parrot smoke. Which in fact would be fun to integrate into the bleadperl smoke :) that is, test parrot for every bleadperl conf tested. H, think, think, think ... Now you can do perl Configure.pl --defaults --define ccflags=... --define ld=cc --define cc=gcc --define libs=-lfoo for each and every flag, and they will ovrride the perl ones ( in fact I use this to compile a MinGW parrot using ActivePerl ) And yes, I was thinking of smoke when I submitted that patch... WRT smoking, I can made a Parrot smoking suite modifying the perl one, since I have lots of time ( it's nice to be a student :-) ) Consider it your's :) I will try to *integrate* it in my hybrid perl5 smoke and test parrot for every bleadperl configuration. Yummie, sounds like fun. Now only I have to enable the Unix host to connect to cvs.perl.org (everything is closed), but I managed for ftp.linux.activestate.com, and I'll manage again! -- H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.6.1, 5.7.1 629 on HP-UX 10.20 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro WinCE 2.11. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: [PATCH] Bytecode bounds checking and TRACE_OPS
Simon Cozens sent the following bits through the ether: My view is that if you screw up writing assembly code, you should be thankful that you get the protection of a segfault. Indeed, but why not warn about it. The JVM does this by checking that the bytecodes are wellformed during its bytecode verification stage (before it runs the bytecode). It does some simple checks to see if the bytecode is doing reasonable things (no halting problem here, move along). Something for later, perhaps. Leon -- Leon Brocard.http://www.astray.com/ Iterative Software...http://www.iterative-software.com/ ... All generalizations are false, including this one
Re: Jako patch
Thanks. Applied.
On Tue, 18 Sep 2001, Simon Cozens wrote:
This enables typecasting between I and N registers, fixes up the
error messages, and makes var num not require an assignment.
I note that some pseudo-ops don't work, and mod doesn't work
as a pseudo op with a constant; nor does pow and similar functions
work at all. :( Thinking about how to make these better...
Simon
? factor.jako
Index: jakoc
===
RCS file: /home/perlcvs/parrot/little_languages/jakoc,v
retrieving revision 1.5
diff -d -u -r1.5 jakoc
--- jakoc 2001/09/17 12:49:31 1.5
+++ jakoc 2001/09/18 09:11:46
@@ -339,7 +339,18 @@
if ($ident{$name}) {
if ($type eq '*') {
if ($ident{$value}) {
-printf %-12s %-8s %s\n, '', 'set', $ident{$name}{REG},
$ident{$value}{REG};
+if ($ident{$name}{TYPE} ne $ident{$value}{TYPE}) {
+ if ($ident{$name}{TYPE} eq N and $ident{$value}{TYPE} eq I) {
+printf %-12s %-8s %s\n, '', 'iton', $ident{$name}{REG},
$ident{$value}{REG};
+ } elsif ($ident{$name}{TYPE} eq I and $ident{$value}{TYPE} eq N) {
+printf %-12s %-8s %s\n, '', 'ntoi', $ident{$name}{REG},
$ident{$value}{REG};
+ } else {
+printf(STDERR jako: Cannot assign type '%s' to type '%s' on line
%d.\n,
+$ident{$value}{TYPE}, $ident{$name}{TYPE}, $line);
+ }
+} else {
+printf %-12s %-8s %s\n, '', 'set', $ident{$name}{REG},
$ident{$value}{REG};
+}
} else {
printf(STDERR jako: Assignment from undefined variable '%s' on line %d.\n,
$value, $line);
@@ -402,7 +413,7 @@
printf %-12s %-8s %s\n, '', $name, $arg;
}
} else {
-printf(STDERR jako: Unrecognized function '$name' on line %d.\n, $name,
$line);
+printf(STDERR jako: Unrecognized function '%s' on line %d.\n, $name, $line);
}
}
@@ -419,7 +430,7 @@
@args = map_args($dest, @args);
printf %-12s %-8s %s\n, '', $name, join(, , @args);
} else {
-printf(STDERR jako: Unrecognized function '$name' on line %d.\n, $name,
$line);
+printf(STDERR jako: Unrecognized function '%s' on line %d.\n, $name, $line);
}
}
@@ -675,7 +686,7 @@
#
if ((m/^var\s+(i)nt(eger)?\s+([A-Za-z][A-Za-z0-9_]*)(\s*=\s*(\d+))?$/) ||
- (m/^var\s+(n)um(ber)?\s+([A-Za-z][A-Za-z0-9_]*)(\s*=\s*(\d+(\.\d+)))$/) ||
+ (m/^var\s+(n)um(ber)?\s+([A-Za-z][A-Za-z0-9_]*)(\s*=\s*(\d+(\.\d+)))?$/) ||
(m/^var\s+(s)tr(ing)?\s+([A-Za-z][A-Za-z0-9_]*)(\s*=\s*(\[^\\\]*(?:\\.[^\\\]*)*\))?$/))
{
declare_var($3, uc($1));
assign_var($3, uc($1), $5) if defined $5;
--
Reporter (to Mahatma Gandhi): Mr Gandhi, what do you think of Western
Civilization?
Gandhi: I think it would be a good idea.
Number bug
piglet$ cat minus.pasm set N1, -2 print N1 piglet$ ./assemble.pl minus.pasm Error (1): No opcode set (tried set_n_ic, set_n) in set N1, -2 This should probably work. Unfortunately, this involves more work on the assembler than I have knowledge of it so far. Leon ps test suite for inc coming up once this is fixed -- Leon Brocard.http://www.astray.com/ Nanoware...http://www.nanoware.org/ ... And he disappeared in a puff of logic
Re: cvs snapshots
On Tue 18 Sep 2001 00:54, Ask Bjoern Hansen [EMAIL PROTECTED] wrote: On Tue, 18 Sep 2001, H.Merijn Brand wrote: On Mon 17 Sep 2001 23:08, Ask Bjoern Hansen [EMAIL PROTECTED] wrote: oops, I forgot to tell anyone. I made CVS export and tar up a snapshot every 6 hours. It is available at http://cvs.perl.org/snapshots/parrot/ Any chance on rsync? If so, I might set up another smoke suite to bother you with reports :) rsync -av cvs.perl.org::parrot-HEAD parrot it's only updated every 6th hour. Maybe I'll get time to get it to update more often (but not create a snapshot) tonight. From all my machines I get i2:/l1/pro/3gl/CPAN/parrot 104 rsync -avz rsync://cvs.perl.org::parrot-HEAD/ . failed to connect to cvs.perl.org - Can't assign requested address i2:/l1/pro/3gl/CPAN/parrot 105 rsync -avz rsync://216.246.96.150::parrot-HEAD/ . failed to connect to 216.246.96.150 - Can't assign requested address i2:/l1/pro/3gl/CPAN/parrot 106 (And this machine has (temporary) no restrictions to the outside world) ActiveSync rsyncs fine using rsync -avz rsync://ftp.linux.activestate.com/perl-current/ . -- H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.6.1, 5.7.1 629 on HP-UX 10.20 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro WinCE 2.11. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
_BUILD_ARG_TABLE, _BUILD_NAME_TABLE undefined
On OS X: % make test_prog perl make_op_header.pl opcode_table include/parrot/op.h cc -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE \ -fno-strict-aliasing -I.. -I./include -g -o test_main.o -c \ test_main.c cc -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE \ -fno-strict-aliasing -I.. -I./include -g -o global_setup.o \ -c global_setup.c perl build_interp_starter.pl cc -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE \ -fno-strict-aliasing -I.. -I./include -g -o \ interpreter.o -c interpreter.c cc -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE \ -fno-strict-aliasing -I.. -I./include -g -o parrot.o -c \ parrot.c cc -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE \ -fno-strict-aliasing -I.. -I./include -g -o register.o -c \ register.c perl process_opfunc.pl basic_opcodes.ops cc -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE \ -fno-strict-aliasing -I.. -I./include -g -o basic_opcodes.o \ -c basic_opcodes.c cc -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE \ -fno-strict-aliasing -I.. -I./include -g -o memory.o -c \ memory.c cc -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE \ -fno-strict-aliasing -I.. -I./include -g -o bytecode.o -c \ bytecode.c cc -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE \ -fno-strict-aliasing -I.. -I./include -g -o string.o -c \ string.c cc -g -pipe -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE \ -fno-strict-aliasing -I.. -I./include -g -o strnative.o -c \ strnative.ccc -lm -lc -o test_prog global_setup.o \ interpreter.o parrot.o register.o basic_opcodes.o memory.o \ bytecode.o string.o strnative.o test_main.o /usr/bin/ld: Undefined symbols: _BUILD_ARG_TABLE _BUILD_NAME_TABLE make: *** [test_prog] Error 1
sizeof(IV)
Are we assuming that sizeof(IV) = sizeof(char*). If so, we should probably assert this somewhere in the configure system. Tanton
[PATCH]pedantic
This patch allows parrot to compile cleanly under the -pedantic flag of gcc.
It removes the lvalue casts in GRAB_IV and DO_OP. GRAB_IV I had to add a
variable that was an IV** to hold the program code in each function that
used GRAB_IV. With DO_OP I just changed the lvalue cast to an rvalue cast.
Let me know of any improvements I could make.
Index: build_interp_starter.pl
===
RCS file: /home/perlcvs/parrot/build_interp_starter.pl,v
retrieving revision 1.9
diff -u -u -r1.9 build_interp_starter.pl
--- build_interp_starter.pl 2001/09/18 01:20:43 1.9
+++ build_interp_starter.pl 2001/09/18 14:38:59
@@ -62,7 +62,7 @@
#define DO_OP(w,x,y,z) do { \\
x = (void *)z-opcode_funcs; \\
-(void *)y = x[*w]; \\
+y = (IV* (*)())x[*w]; \\
w = (y)(w,z); \\
} while (0);
EOI
Index: bytecode.c
===
RCS file: /home/perlcvs/parrot/bytecode.c,v
retrieving revision 1.10
diff -u -u -r1.10 bytecode.c
--- bytecode.c 2001/09/17 17:38:14 1.10
+++ bytecode.c 2001/09/18 14:39:00
@@ -31,7 +31,7 @@
#include parrot/parrot.h
-#define GRAB_IV(x) *((IV*)*x)++
+#define GRAB_IV(x) *(*x)++
/*
@@ -51,8 +51,9 @@
static int
check_magic(void** program_code, long* program_size) {
+IV** pcode = (IV**)program_code;
program_size -= sizeof(IV);
-return (GRAB_IV(program_code) == PARROT_MAGIC);
+return (GRAB_IV(pcode) == PARROT_MAGIC);
}
/*
@@ -74,7 +75,8 @@
static void
read_constants_table(void** program_code, long* program_size)
{
-IV len = GRAB_IV(program_code);
+IV ** pcode = (IV**)program_code;
+IV len = GRAB_IV(pcode);
IV num;
IV i = 0;
@@ -85,24 +87,24 @@
return;
}
-num = GRAB_IV(program_code);
+num = GRAB_IV(pcode);
len -= sizeof(IV);
*program_size -= sizeof(IV);
Parrot_string_constants = mem_allocate_aligned(num * sizeof(STRING*));
while (len 0) {
-IV flags= GRAB_IV(program_code);
-IV encoding = GRAB_IV(program_code);
-IV type = GRAB_IV(program_code);
-IV buflen = GRAB_IV(program_code);
+IV flags= GRAB_IV(pcode);
+IV encoding = GRAB_IV(pcode);
+IV type = GRAB_IV(pcode);
+IV buflen = GRAB_IV(pcode);
int pad;
len -= 4 * sizeof(IV);
*program_size -= 4 * sizeof(IV);
-Parrot_string_constants[i++] = string_make(*program_code /* ouch
*/, buflen, encoding, flags, type);
-(char*)*program_code += buflen;
+Parrot_string_constants[i++] = string_make((char*)*pcode /* ouch
*/, buflen, encoding, flags, type);
+*pcode = (IV*)((char*)*pcode + buflen);
len -= buflen;
*program_size -= buflen;
@@ -111,7 +113,7 @@
if (pad) {
pad=sizeof(IV)-pad;
len -= pad;
- (char*)*program_code += pad;
+ *pcode = (IV*)((char*)*pcode + pad);
*program_size -= pad;
}
num--;
@@ -140,10 +142,11 @@
static void
read_fixup_table(void** program_code, long* program_size)
{
-IV len = GRAB_IV(program_code);
+IV** pcode = (IV**)program_code;
+IV len = GRAB_IV(pcode);
*program_size -= sizeof(IV);
/* For now, just skip over it */
-((IV*)*program_code) += len;
+*pcode += len;
*program_size -= len;
}
Re: bytecode and sizeof(IV)
On Tue, Sep 18, 2001 at 10:48:25AM -0400, Andy Dougherty wrote: When trying to configure parrot with an IV = 'long long' (64-bit) but with int, long, and pointers only 32-bit, I get either This isn't Parrot bytecode! (on SPARC) or a segfault (on i686). Segfault in alpha even when IVs and pointers are both 8 bytes since the code tries to dereference the pointers (to read IVs) at four byte offsets. I'd offer a patch, but I'm not sure which end of the process we want to change. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: bytecode and sizeof(IV)
On Tue, Sep 18, 2001 at 05:52:24PM +0300, Jarkko Hietaniemi wrote: Segfault in alpha even when IVs and pointers are both 8 bytes since the code tries to dereference the pointers (to read IVs) at four byte offsets. Yep, and the latest pedantic patch doesn't help. Also, I'm seeing this, which is weird: ld -ldbm -ldb -lm -liconv -o test_prog global_setup.o interpreter.o parrot.o register.o basic_opcodes.o memory.o bytecode.o string.o strnative.o test_main.o ld: Error: Undefined: exit _iob fprintf fputs strncmp _OtsDivide64 printf time acos asin atan atan2 cosh exp log log10 pow sinh tan tanh cos sin _OtsRemainder64 malloc __CFE_print_puts free realloc _OtsMoveMinimum _OtsZero _OtsMove mmap stat open errno strcmp *** Exit 1 -- The UNIX system is harder to use than a toaster. -Kaare Christian
RE: bytecode and sizeof(IV)
You probably don't want to use ld as your linker. You should try cc instead. -Original Message- From: Simon Cozens To: [EMAIL PROTECTED] Sent: 9/18/2001 9:46 AM Subject: Re: bytecode and sizeof(IV) On Tue, Sep 18, 2001 at 05:52:24PM +0300, Jarkko Hietaniemi wrote: Segfault in alpha even when IVs and pointers are both 8 bytes since the code tries to dereference the pointers (to read IVs) at four byte offsets. Yep, and the latest pedantic patch doesn't help. Also, I'm seeing this, which is weird: ld -ldbm -ldb -lm -liconv -o test_prog global_setup.o interpreter.o parrot.o register.o basic_opcodes.o memory.o bytecode.o string.o strnative.o test_main.o ld: Error: Undefined: exit _iob fprintf fputs strncmp _OtsDivide64 printf time acos asin atan atan2 cosh exp log log10 pow sinh tan tanh cos sin _OtsRemainder64 malloc __CFE_print_puts free realloc _OtsMoveMinimum _OtsZero _OtsMove mmap stat open errno strcmp *** Exit 1 -- The UNIX system is harder to use than a toaster. -Kaare Christian
RE: [PATCH]pedantic
Ignore this patch as I think I have a better way to fix it.
-Original Message-
From: Gibbs Tanton - tgibbs
To: '[EMAIL PROTECTED] '
Sent: 9/18/2001 9:44 AM
Subject: [PATCH]pedantic
This patch allows parrot to compile cleanly under the -pedantic flag of
gcc.
It removes the lvalue casts in GRAB_IV and DO_OP. GRAB_IV I had to add
a
variable that was an IV** to hold the program code in each function that
used GRAB_IV. With DO_OP I just changed the lvalue cast to an rvalue
cast.
Let me know of any improvements I could make.
Index: build_interp_starter.pl
===
RCS file: /home/perlcvs/parrot/build_interp_starter.pl,v
retrieving revision 1.9
diff -u -u -r1.9 build_interp_starter.pl
--- build_interp_starter.pl 2001/09/18 01:20:43 1.9
+++ build_interp_starter.pl 2001/09/18 14:38:59
@@ -62,7 +62,7 @@
#define DO_OP(w,x,y,z) do { \\
x = (void *)z-opcode_funcs; \\
-(void *)y = x[*w]; \\
+y = (IV* (*)())x[*w]; \\
w = (y)(w,z); \\
} while (0);
EOI
Index: bytecode.c
===
RCS file: /home/perlcvs/parrot/bytecode.c,v
retrieving revision 1.10
diff -u -u -r1.10 bytecode.c
--- bytecode.c 2001/09/17 17:38:14 1.10
+++ bytecode.c 2001/09/18 14:39:00
@@ -31,7 +31,7 @@
#include parrot/parrot.h
-#define GRAB_IV(x) *((IV*)*x)++
+#define GRAB_IV(x) *(*x)++
/*
@@ -51,8 +51,9 @@
static int
check_magic(void** program_code, long* program_size) {
+IV** pcode = (IV**)program_code;
program_size -= sizeof(IV);
-return (GRAB_IV(program_code) == PARROT_MAGIC);
+return (GRAB_IV(pcode) == PARROT_MAGIC);
}
/*
@@ -74,7 +75,8 @@
static void
read_constants_table(void** program_code, long* program_size)
{
-IV len = GRAB_IV(program_code);
+IV ** pcode = (IV**)program_code;
+IV len = GRAB_IV(pcode);
IV num;
IV i = 0;
@@ -85,24 +87,24 @@
return;
}
-num = GRAB_IV(program_code);
+num = GRAB_IV(pcode);
len -= sizeof(IV);
*program_size -= sizeof(IV);
Parrot_string_constants = mem_allocate_aligned(num *
sizeof(STRING*));
while (len 0) {
-IV flags= GRAB_IV(program_code);
-IV encoding = GRAB_IV(program_code);
-IV type = GRAB_IV(program_code);
-IV buflen = GRAB_IV(program_code);
+IV flags= GRAB_IV(pcode);
+IV encoding = GRAB_IV(pcode);
+IV type = GRAB_IV(pcode);
+IV buflen = GRAB_IV(pcode);
int pad;
len -= 4 * sizeof(IV);
*program_size -= 4 * sizeof(IV);
-Parrot_string_constants[i++] = string_make(*program_code /*
ouch
*/, buflen, encoding, flags, type);
-(char*)*program_code += buflen;
+Parrot_string_constants[i++] = string_make((char*)*pcode /*
ouch
*/, buflen, encoding, flags, type);
+*pcode = (IV*)((char*)*pcode + buflen);
len -= buflen;
*program_size -= buflen;
@@ -111,7 +113,7 @@
if (pad) {
pad=sizeof(IV)-pad;
len -= pad;
- (char*)*program_code += pad;
+ *pcode = (IV*)((char*)*pcode + pad);
*program_size -= pad;
}
num--;
@@ -140,10 +142,11 @@
static void
read_fixup_table(void** program_code, long* program_size)
{
-IV len = GRAB_IV(program_code);
+IV** pcode = (IV**)program_code;
+IV len = GRAB_IV(pcode);
*program_size -= sizeof(IV);
/* For now, just skip over it */
-((IV*)*program_code) += len;
+*pcode += len;
*program_size -= len;
}
Re: bytecode and sizeof(IV)
On Tue, Sep 18, 2001 at 11:10:36AM -0500, Gibbs Tanton - tgibbs wrote: You probably don't want to use ld as your linker. You should try cc instead. Then that's a bug in Configure! :) -- If that makes any sense to you, you have a big problem. -- C. Durance, Computer Science 234
[PATCH] MANIFEST update.
The following patch adds some missing files to MANIFEST. It also re-sorts it for easier maintenance. It's probably a good idea to periodically run perl -MExtUtils::Manifest -e 'ExtUtils::Manifest::fullcheck' (or equivalent) to keep the MANIFEST in sync. --- parrot/MANIFEST Mon Sep 17 21:20:43 2001 +++ parrot-andy/MANIFESTTue Sep 18 13:30:16 2001 @@ -1,11 +1,11 @@ -Configure.pl Config_pm.in -Makefile.in +Configure.pl MANIFEST +Makefile.in Parrot/Opcode.pm Parrot/PackFile.pm -Parrot/PackFile/Constant.pm Parrot/PackFile/ConstTable.pm +Parrot/PackFile/Constant.pm Parrot/PackFile/FixupTable.pm Parrot/Test.pm README @@ -14,46 +14,53 @@ basic_opcodes.ops build_interp_starter.pl bytecode.c -include/parrot/bytecode.h config_h.in disassemble.pl docs/opcodes.pod docs/overview.pod +docs/parrot_assembly.pod docs/parrotbyte.pod docs/strings.pod docs/vtables.pod +global_setup.c +hints/mswin32.pl +include/parrot/bytecode.h include/parrot/events.h include/parrot/exceptions.h -global_setup.c include/parrot/global_setup.h -interpreter.c include/parrot/interpreter.h include/parrot/io.h +include/parrot/memory.h +include/parrot/parrot.h +include/parrot/register.h +include/parrot/stacks.h +include/parrot/string.h +include/parrot/strnative.h +interpreter.c +little_languages/Makefile +little_languages/bench.jako +little_languages/euclid.jako +little_languages/fact.jako +little_languages/fib.jako +little_languages/hello.jako +little_languages/jakoc make_op_header.pl memory.c -include/parrot/memory.h opcheck.pl opcode_table parrot.c -include/parrot/parrot.h process_opfunc.pl register.c -include/parrot/register.h -include/parrot/stacks.h string.c -include/parrot/string.h strnative.c -include/parrot/strnative.h +t/Makefile +t/euclid.pasm +t/harness +t/jump.pasm +t/local_label.pasm +t/op/basic.t +t/op/string.t t/test.pasm t/test2.pasm t/test3.pasm -t/euclid.pasm -t/jump.pasm test_main.c -little_languages/euclid.jako -little_languages/jakoc -little_languages/Makefile -little_languages/fact.jako -little_languages/fib.jako -little_languages/hello.jako -little_languages/bench.jako -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
[PATCH] Tiny Configure patch
Now that the *.h files are in their correct home, we don't need
the -I.. flag. It could even pick up *wrong* versions of the header files
in a neighboring directory.
--- parrot/Configure.pl Mon Sep 17 21:20:43 2001
+++ parrot-andy/Configure.plTue Sep 18 13:36:52 2001
@@ -64,7 +64,7 @@
nv = ($Config{nvtype}||'double'),
cc = $Config{cc},
#ADD C COMPILER FLAGS HERE
- ccflags = $Config{ccflags}. -I.. -I./include,
+ ccflags = $Config{ccflags}. -I./include,
libs = $Config{libs},
perl = $^X,
cc_debug = '-g',
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
[PATCH Makefile.in] RE: [doughera@lafayette.edu: Re: bytecode and sizeof(IV)]
Easy Makefile.in patch. I was worried that Win32 might need the linker
(the change to $(LD) was submitted as part of a Win32 compatibility
patch) but that doesn't seem to be the case. I don't have a MinGW
toolkit installed, however--can someone check that it works there? It
also works on a BSD box, so I'm applying.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- ..\..\parrot-cvs\parrot\Makefile.in Tue Sep 18 10:54:52 2001
+++ Makefile.in Tue Sep 18 10:53:54 2001
@@ -28,7 +28,7 @@
$(CC) -shared $(C_LIBS) -o $@ $(O_FILES)
$(TEST_PROG): test_main$(O) $(O_FILES)
- $(LD) $(C_LIBS) ${ld_debug} ${ld_out}$(TEST_PROG) $(O_FILES)
test_main$(O)
+ $(CC) $(C_LIBS) $(CFLAGS) -o $(TEST_PROG) $(O_FILES)
test_main$(O)
test_main$(O): $(H_FILES)
RE: [PATCH] Tiny Configure patch
Andy Dougherty: # Now that the *.h files are in their correct home, we don't need # the -I.. flag. It could even pick up *wrong* versions of the # header files # in a neighboring directory. Thanks, applied. --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
The core platforms list
Okay, folks, the following platforms are considered core for the parrot interpreter. That means we need to run on all of them for any release of the interpreter to be considerd OK. They are: Linux (x86) CygWin Win32 Tru64 OpenVMS (Alpha) Solaris (Sparc) FreeBSD (x86) If a platform's not here it's not because we don't want to run on it, rather it's because we can't guarantee the manpower to make it right. (If we can, then new platforms can and will come on board) So remember, all the world is not *X*, for any value of X you might have... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The core platforms list
On Tue, Sep 18, 2001 at 02:43:07PM -0400, Dan Sugalski wrote: Okay, folks, the following platforms are considered core for the parrot interpreter. That means we need to run on all of them for any release of the interpreter to be considerd OK. They are: [...] Solaris (Sparc) 32 bit, 64 bit or both? Phil -- Philip Kendall [EMAIL PROTECTED] http://www.srcf.ucam.org/~pak21/
Re: The core platforms list
On Tue, Sep 18, 2001 at 02:43:07PM -0400, Dan Sugalski wrote: If a platform's not here it's not because we don't want to run on it, rather it's because we can't guarantee the manpower to make it right. (If we can, then new platforms can and will come on board) I can handle Linux (PowerPC). There shouldn't be much difference from x86 except the byte ordering, I hope. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Maybe they hooked you up with one of those ass-making magazines. -- brian d. foy as misheard by Michael G Schwern
Re: The core platforms list
On Tue, Sep 18, 2001 at 02:43:07PM -0400, Dan Sugalski wrote: Linux (x86) CygWin Win32 Tru64 OpenVMS (Alpha) Solaris (Sparc) FreeBSD (x86) To clarify: we're *not* saying these are the only platforms we care about. Parrot *will* run on many, many more platforms than the above. And yes, if it doesn't run nicely on yours, we'll patch it (sorry, *you*'ll patch it :) until it does. But if it doesn't play nice on those platforms, we don't ship; and one of the committers - probably me, since I'm theoretically herding this bunch of cats - screwed up. The point of the list is to encourage people to think about portability. -- I'm a person, not a piece of property. Happily, I'm both! - Lionel and Stephen Harris.
[COMMIT] Reworked disassemble.pl
All -- I reworked the disassembler to use the PackFile::* classes, and made some fixes to the classes themselves. Still to come: * Refactor most of the disassembler code into the PackFile classes themselves. * Rework the disassembler to generate labels for branch targets. * Make the disassembler generate output that can be fed right back in to the assembler. * I sure would like to rename 'disassembler.pl' to 'dpasm' or 'pdasm' and assemble.pl to 'pasm' for Parrot Assembler. * Should these and other Perl scripts really go in a 'scripts' subdirectory? 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 \_/
[PATCH] Win32/perl 5.004/other
This patch contains different things.
If you prefer three smaller patches,
just speak, I'll resend.
* Configure.pl
* 5.004_04 does not have $Config{_o}, $Config{_exe},
use obj_ext, and exe_ext
* Use ExtUtils::Manifest for manifest parsing
( now you can put blank lines/comments/
file descriptions in MANIFEST )
* add rm_f configuration variable
( WIndows, as usual, is different )
* MANIFEST, MANIFEST.SKIP
* updates, skip CVS-related files
in fullcheck
* Makefile.in
* some cleanup
* new targets:
distclean, to remove configure-generated files
fullcheck, to do a ExtUtils::Manifest::fullcheck
* hints/mswin32.pl
* added rm_f
* test_main.c
* renamed _read to read
Regards
Mattia
diff -r -u -2 -N -xCVS -x.#* -xop.h -x*.orig -x*.rej -x*~ parrot.cvs/Configure.pl
parrot/Configure.pl
--- parrot.cvs/Configure.pl Tue Sep 18 21:45:08 2001
+++ parrot/Configure.pl Tue Sep 18 21:43:04 2001
@@ -7,4 +7,5 @@
use Config;
use Getopt::Long;
+use ExtUtils::Manifest;
my( $opt_debugging, $opt_defaults, $opt_version, $opt_help ) = ( 0, 0, 0, 0 );
@@ -69,10 +70,11 @@
perl = $^X,
cc_debug = '-g',
- o ='.o', # object files extension
- exe = $Config{_exe},
+ o =$Config{obj_ext}, # object files extension
+ exe = $Config{exe_ext},
ld = $Config{ld},
ld_out = '-o ', # ld output file
ld_debug = '', # include debug info in executable
debugging =$opt_debugging,
+ rm_f = 'rm -f',# remove files
);
@@ -211,11 +213,10 @@
sub check_manifest {
+ my $files = ExtUtils::Manifest::maniread( 'MANIFEST' );
my $not_ok;
- open(MANIFEST, MANIFEST);
- while(MANIFEST) {
- chomp;
- unless(-e $_) {
- print File $_ is missing!\n;
+ foreach my $i ( keys %$files ) {
+ unless( -e $i) {
+ print File $i is missing!\n;
$not_ok=1;
}
diff -r -u -2 -N -xCVS -x.#* -xop.h -x*.orig -x*.rej -x*~ parrot.cvs/MANIFEST
parrot/MANIFEST
--- parrot.cvs/MANIFEST Tue Sep 18 14:53:20 2001
+++ parrot/MANIFEST Tue Sep 18 15:53:06 2001
@@ -3,5 +3,7 @@
Makefile.in
MANIFEST
+MANIFEST.SKIP
Parrot/Opcode.pm
+Parrot/Test.pm
Parrot/PackFile.pm
Parrot/PackFile/Constant.pm
@@ -23,4 +25,6 @@
docs/strings.pod
docs/vtables.pod
+docs/parrot_assembly.pod
+hints/mswin32.pl
include/parrot/events.h
include/parrot/exceptions.h
@@ -50,4 +54,9 @@
t/euclid.pasm
t/jump.pasm
+t/local_label.pasm
+t/Makefile
+t/harness
+t/op/basic.t
+t/op/string.t
test_main.c
little_languages/euclid.jako
diff -r -u -2 -N -xCVS -x.#* -xop.h -x*.orig -x*.rej -x*~ parrot.cvs/MANIFEST.SKIP
parrot/MANIFEST.SKIP
--- parrot.cvs/MANIFEST.SKIPThu Jan 1 01:00:00 1970
+++ parrot/MANIFEST.SKIPTue Sep 18 15:42:04 2001
@@ -0,0 +1,3 @@
+[Cc][Vv][Ss]/
+\.\#.*[\d\.]+
+\.cvsignore
diff -r -u -2 -N -xCVS -x.#* -xop.h -x*.orig -x*.rej -x*~ parrot.cvs/Makefile.in
parrot/Makefile.in
--- parrot.cvs/Makefile.in Tue Sep 18 21:45:08 2001
+++ parrot/Makefile.in Tue Sep 18 21:43:04 2001
@@ -1,3 +1,4 @@
O = ${o}
+RM_F = ${rm_f}
INC=include/parrot
@@ -18,5 +19,5 @@
TEST_PROG = test_prog${exe}
-.c.o:
+.c$(O):
$(CC) $(CFLAGS) -o $@ -c $
@@ -60,11 +61,17 @@
$(PERL) make_op_header.pl opcode_table $(INC)/op.h
-config.h: Configure.pl config_h.in
+$(INC)/config.h: Configure.pl config_h.in
$(PERL) Configure.pl
clean:
- rm -f *$(O) *.s basic_opcodes.c $(INC)/interp_guts.h $(INC)/op.h $(TEST_PROG)
+ $(RM_F) *$(O) *.s basic_opcodes.c $(INC)/interp_guts.h $(INC)/op.h $(TEST_PROG)
-test:
+distclean: clean
+ $(RM_F) Parrot/Config.pm include/parrot/config.h
+
+fullcheck:
+ $(PERL) -MExtUtils::Manifest=fullcheck -e fullcheck
+
+test: $(TEST_PROG)
$(PERL) t/harness
diff -r -u -2 -N -xCVS -x.#* -xop.h -x*.orig -x*.rej -x*~ parrot.cvs/hints/mswin32.pl
parrot/hints/mswin32.pl
--- parrot.cvs/hints/mswin32.pl Mon Sep 17 00:06:44 2001
+++ parrot/hints/mswin32.pl Tue Sep 18 22:05:58 2001
@@ -3,4 +3,6 @@
my $is_mingw = grep { $c{cc} eq $_ } ( qw(gcc gcc.exe) );
+$c{rm_f} = '$(PERL) -MExtUtils::Command -e rm_f';
+
if( $is_msvc ) {
$c{o} = '.obj';
@@ -10,4 +12,6 @@
}
elsif( $is_mingw ) {
+$c{o} = '.o';
+$c{perl} =~ tr{\\}{/}; # GNU make hates \
$c{ld} = 'gcc';
# if your perl is ActivePerl, then libs are .lib files,
@@ -15,3 +19,3 @@
$c{libs} = ' ' if $c{libs} =~ m/\.lib\s/i;
}
-}
\ No newline at end of file
+}
diff -r -u -2 -N -xCVS -x.#* -xop.h -x*.orig -x*.rej -x*~ parrot.cvs/process_opfunc.pl
parrot/process_opfunc.pl
---
Generate Parrot::OpcodeTable?
All -- It seems to me that we should have a Parrot::OpcodeTable module that is auto-generated rather than having the assembler and disassembler read in the opcode_table file itself. We can install OpcodeTable.pm just like any other module when folks install the assembler and disassembler. We still need the current Opcode.pm, but I wonder if it should be in Parrot::Private::OpcodeTable or Parrot::BuildUtil::OpcodeTable or something... 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 Makefile.in] RE: [doughera@lafayette.edu: Re: bytecode and sizeof(IV)]
Easy Makefile.in patch. I was worried that Win32 might need the linker (the change to $(LD) was submitted as part of a Win32 compatibility patch) but that doesn't seem to be the case. I don't have a MinGW Fine here Regards Mattia
[PATCH] changing IV to opcode_t!!
Earlier there was some discussion about changing
typedef long IV
to
typedef union {
IV i;
void* p;
} opcode_t;
This patch does that. I have tested it on cygwin, solaris 5.8, and solaris
8. I would love someone to test it on Tru64 and Win32.
If this is NO LONGER WANTED, just let me know.
Thanks!
Tanton
patch.dat
Re: Generate Parrot::OpcodeTable?
On Tue, Sep 18, 2001 at 04:15:45PM -0400, Gregor N. Purdy wrote: It seems to me that we should have a Parrot::OpcodeTable module that is auto-generated rather than having the assembler and disassembler read in the opcode_table file itself. Yes; I can't remember why I thought this was a good idea, but it is. Oh yes, it can be found in @INC, whereas assemble and disassemble currently look for opcode_table in the current directory; this makes it hard for people to write Parrot code outside of parrot/. Simon -- `And when you've been *plonk*ed by Simon C., you've been *plonked* by someone who knows when, and why, and how.' - Mike Andrews, asr
Re: [PATCH] changing IV to opcode_t!!
On Tue, Sep 18, 2001 at 03:31:11PM -0500, Gibbs Tanton - tgibbs wrote: 8. I would love someone to test it on Tru64 and Win32. Testing anything on Tru64 is currently impossible, as Jarkko has pointed out. I'm still trying to wrap my branes around how to fix that. However, it compiles. I say apply it. Incidentally, Parrot's now compiling on Tru64 a lot more cleanly that it's ever done. -- Feed me on TOASTIES! There's no HALL for PHILOSOPHERS ON FRIDAYS. - Henry Braun is Oxford Zippy
RE: [PATCH] changing IV to opcode_t!!
Applied. -Original Message- From: Simon Cozens To: Gibbs Tanton - tgibbs Cc: '[EMAIL PROTECTED]' Sent: 9/18/2001 3:53 PM Subject: Re: [PATCH] changing IV to opcode_t!! On Tue, Sep 18, 2001 at 03:31:11PM -0500, Gibbs Tanton - tgibbs wrote: 8. I would love someone to test it on Tru64 and Win32. Testing anything on Tru64 is currently impossible, as Jarkko has pointed out. I'm still trying to wrap my branes around how to fix that. However, it compiles. I say apply it. Incidentally, Parrot's now compiling on Tru64 a lot more cleanly that it's ever done. -- Feed me on TOASTIES! There's no HALL for PHILOSOPHERS ON FRIDAYS. - Henry Braun is Oxford Zippy
RE: [PATCH] Win32/perl 5.004/other
Mattia Barbon:
# This patch contains different things.
# If you prefer three smaller patches,
# just speak, I'll resend.
#
# * Configure.pl
# * 5.004_04 does not have $Config{_o}, $Config{_exe},
# use obj_ext, and exe_ext
# * Use ExtUtils::Manifest for manifest parsing
# ( now you can put blank lines/comments/
# file descriptions in MANIFEST )
# * add rm_f configuration variable
# ( WIndows, as usual, is different )
# * MANIFEST, MANIFEST.SKIP
# * updates, skip CVS-related files
# in fullcheck
# * Makefile.in
# * some cleanup
# * new targets:
# distclean, to remove configure-generated files
# fullcheck, to do a ExtUtils::Manifest::fullcheck
# * hints/mswin32.pl
# * added rm_f
# * test_main.c
# * renamed _read to read
I can't speak for the C bits, but the Configure and Friends changes look
okay. Someone else should check the C stuff (and maybe double-check the
MANIFEST and MANIFEST.SKIP changes) before it's applied.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
Some tests
The attached file contains tests for all Parrot integer ops. - Damien #! perl -w use Parrot::Test tests = 26; output_is(CODE, OUTPUT, set_i_ic); # XXX: Need a test for writing outside the set of available # registers. Parrot doesn't check for this at the moment. set I0, 0x12345678 print I0 print \\n set I31, 0x9abcdef1 print I31 print \\n set I1, 2147483647 print I1 print \\n set I2, -2147483648 print I2 print \\n set I3, 4294967295 print I3 print \\n CODE 305419896 -1698898191 2147483647 -2147483648 -1 OUTPUT output_is(CODE, OUTPUT, set_i); set I0, 0x77665544 set I1, I0 print I1 print \\n CODE 2003195204 OUTPUT output_is(CODE, OUTPUT, add_i); set I0, 0x11223344 add I1, I0, I0 print I1 print \\n add I2, I0, I1 print I2 print \\n add I2, I2, I2 print I2 print \\n set I3, 2147483647 set I4, 1 add I5, I3, I4 print I5 print \\n set I6, -1 add I7, I5, I6 print I7 print \\n CODE 574908040 862362060 1724724120 -2147483648 2147483647 OUTPUT output_is(CODE, OUTPUT, sub_i); set I0, 0x12345678 set I1, 0x01234567 sub I2, I0, I1 print I2 print \\n CODE 286331153 OUTPUT output_is(CODE, OUTPUT, mul_i); set I0, 7 set I1, 29 mul I2, I0, I1 print I2 print \\n CODE 203 OUTPUT output_is(CODE, OUTPUT, div_i); set I0, 0x set I1, 0x div I2, I0, I1 print I2 print \\n set I0, 11 set I1, 2 div I2, I0, I1 print I2 print \\n set I0, 9 set I1, -4 div I2, I0, I1 print I2 print \\n CODE 3 5 -2 OUTPUT output_is(CODE, OUTPUT, mod_i); set I0, 17 set I1, 5 mod I2, I0, I1 print I2 print \\n set I0, -57 set I1, 10 mod I2, I0, I1 print I2 print \\n CODE 2 -7 OUTPUT output_is(CODE, OUTPUT, eq_i_ic); set I0, 0x12345678 set I1, 0x12345678 set I2, 0x76543210 eq I0, I1, ONE, ERROR print bad\\n ONE: print ok 1\\n eq I1, I2, ERROR, TWO print bad\\n TWO: print ok 2\\n end ERROR: print bad\\n CODE ok 1 ok 2 OUTPUT output_is(CODE, OUTPUT, eq_ic_ic); set I0, -42 eq I0, 42, ERROR, ONE print bad\\n ONE: print ok 1\\n eq I0, -42, TWO, ERROR print bad\\n TWO: print ok 2\\n end ERROR: print bad\\n CODE ok 1 ok 2 OUTPUT output_is(CODE, OUTPUT, ne_i_ic); set I0, 0xa0b0c0d0 set I1, 0xa0b0c0d0 set I2, 0 ne I0, I2, ONE, ERROR print bad\\n ONE: print ok 1\\n ne I0, I1, ERROR, TWO print bad\\n TWO: print ok 2\\n end ERROR: print bad\\n CODE ok 1 ok 2 OUTPUT output_is(CODE, OUTPUT, ne_ic_ic); set I0, 427034409 ne I0, 427034409, ERROR, ONE print bad\\n ONE: print ok 1\\n ne I0, 427034408, TWO, ERROR print bad\\n TWO: print ok 2\\n end ERROR: print bad\\n CODE ok 1 ok 2 OUTPUT output_is(CODE, OUTPUT, lt_i_ic); set I0, 2147483647 set I1, -2147483648 set I2, 0 set I3, 0 lt I1, I0, ONE, ERROR print bad\\n ONE: print ok 1\\n lt I0, I1, ERROR, TWO print bad\\n TWO: print ok 2\\n lt I2, I3, ERROR, THREE print bad\\n THREE: print ok 3\\n end ERROR: print bad\\n CODE ok 1 ok 2 ok 3 OUTPUT output_is(CODE, OUTPUT, lt_ic_ic); set I0, 2147483647 set I1, -2147483648 set I2, 0 lt I0, -2147483648, ERROR, ONE print bad\\n ONE: print ok 1\\n lt I1, 2147483647, TWO, ERROR print bad\\n TWO: print ok 2\\n lt I0, 0, ERROR, THREE print bad\\n THREE: print ok 3\\n end ERROR: print bad\\n CODE ok 1 ok 2 ok 3 OUTPUT output_is(CODE, OUTPUT, le_i_ic); set I0, 2147483647 set I1, -2147483648 set I2, 0 set I3, 0 le I1, I0, ONE, ERROR print bad\\n ONE: print ok 1\\n le
RE: A task for the interested
Dan Sugalski:
# One of the things that the configure script needs to do is
# generate the
# opcode dispatch macro to either be a giant switch statement (with a
# fallthrough default to handle cases we don't know about) or
# the function
# table dispatch we have now.
If somebody codes up the alternate dispatch, I can easily modify
Configure.pl, config_h.in and the hints files to handle it. Something
like this, perhaps:
#define USE_${dispatch}_DISPATCH
#ifdef USE_switch_DISPATCH
#define DISPATCHER
switch-based dispatcher code here
#else
#define DISPATCHER
function table-based dispatcher code here
#endif
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
Re: A task for the interested
On Tue, Sep 18, 2001 at 02:32:32PM -0700, Brent Dax wrote: If somebody codes up the alternate dispatch, I can easily modify Configure.pl, config_h.in and the hints files to handle it. Something like this, perhaps: Something like that, but the Right Way would be to rewrite DO_OP in interp_guts.h Simon -- } /* the next line is indented funny to preserve old indentation */ - plan9 has a bad day
Re: A task for the interested
On Tue, Sep 18, 2001 at 03:55:23PM -0400, Dan Sugalski wrote: Anyone care to take a shot at it? Having an extra overridable column in the opcode_table file (so we know which opcodes are overridable, and thus can't be in the switch) would be a good thing while you were at it... I will do this tonight, if nobody else gets to it first. - Damien
Re: Some tests
On Tue, Sep 18, 2001 at 02:14:39PM -0700, Damien Neil wrote: The attached file contains tests for all Parrot integer ops. - Damien THANK YOU! (Applied) -- Calm down, it's *only* ones and zeroes.
Re: [PATCH] MANIFEST update.
On Tue, Sep 18, 2001 at 01:38:58PM -0400, Andy Dougherty wrote: The following patch adds some missing files to MANIFEST. It also re-sorts it for easier maintenance. It's probably a good idea to periodically run perl -MExtUtils::Manifest -e 'ExtUtils::Manifest::fullcheck' (or equivalent) to keep the MANIFEST in sync. Thanks, applied. -- Old Japanese proverb: There are two kinds of fools -- those who never climb Mt. Fuji, and those who climb it twice.
RE: A task for the interested
Simon Cozens:
# On Tue, Sep 18, 2001 at 02:32:32PM -0700, Brent Dax wrote:
# If somebody codes up the alternate dispatch, I can easily modify
# Configure.pl, config_h.in and the hints files to handle it.
# Something
# like this, perhaps:
#
# Something like that, but the Right Way would be to rewrite DO_OP in
# interp_guts.h
So, something more like this?
~~
--- ..\..\parrot-cvs\parrot\config_h.in Fri Sep 14 09:40:36 2001
+++ config_h.in Tue Sep 18 14:44:48 2001
@@ -24,7 +24,14 @@
#define MASK_CHUNK_LOW_BITS 0xf000
+#define USE_DISPATCH_${dispatch}
+#ifdef USE_DISPATCH_SWITCH
+# undef DO_OP
+# define DO_OP code here
+#endif
+
+
${headers}
--- ..\..\parrot-cvs\parrot\build_interp_starter.pl Tue Sep 18
10:54:52 2001
+++ build_interp_starter.pl Tue Sep 18 14:48:26 2001
@@ -59,12 +59,13 @@
#
print INTERP EOI;
-
-#define DO_OP(w,x,y,z) do { \\
-x = (void *)z-opcode_funcs; \\
-(void *)y = x[*w]; \\
-w = (y)(w,z); \\
- } while (0);
+#ifndef DO_OP
+# define DO_OP(w,x,y,z) do { \\
+ x = (void *)z-opcode_funcs; \\
+ (void *)y = x[*w]; \\
+ w = (y)(w,z); \\
+} while (0);
+#endif
EOI
# Spit out the OPCODE_FINGERPRINT macro
~~~
(With, of course, the correct code put in config_h.in, and various
changes and additions to the hints/ folder to automagically suggest the
right dispatch to use.)
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
Bytecode safety
Proposed: Parrot should never crash due to malformed bytecode. When choosing between execution speed and bytecode safety, safety should always win. Careful op design and possibly a validation pass before execution will hopefully keep the speed penalty to a minimum. Yes, no? - Damien
RE: Bytecode safety
I would vote no. HOWEVER, I would think that the user should have the option to turn on checking for malformed bytecode (i.e. Safe mode). In the default case, I think the bytecode should be assumed well formed and no extra checking be performed. -Original Message- From: Damien Neil To: [EMAIL PROTECTED] Sent: 9/18/2001 4:37 PM Subject: Bytecode safety Proposed: Parrot should never crash due to malformed bytecode. When choosing between execution speed and bytecode safety, safety should always win. Careful op design and possibly a validation pass before execution will hopefully keep the speed penalty to a minimum. Yes, no? - Damien
Re: Bytecode safety
On Tue, Sep 18, 2001 at 02:37:43PM -0700, Damien Neil wrote: Proposed: Parrot should never crash due to malformed bytecode. Haven't we done this argument? :) I'd vote no, FWIW. -- Dames lie about anything - just for practice. -Raymond Chandler
Re: Bytecode safety
On Tue, Sep 18, 2001 at 10:40:30PM +0100, Simon Cozens wrote: On Tue, Sep 18, 2001 at 02:37:43PM -0700, Damien Neil wrote: Proposed: Parrot should never crash due to malformed bytecode. Haven't we done this argument? :) Sort of, while talking about other things. I wanted to drag it out to stand on its own. : - Damien
Transcendental Math Function Tests
I have added trans.t to t/op/. It contains tests for all 18 transcendental math functions. BTW, did we ever decide on a naming scheme for operators...I named all of the math functions against the grain (although I didn't realize it at the time)...for example sin_n_n instead of sin_n. Does this need to be changed? I'll be glad to do it. Tanton
Re: Bytecode safety
On Tue, 18 Sep 2001, Damien Neil wrote: Proposed: Parrot should never crash due to malformed bytecode. When choosing between execution speed and bytecode safety, safety should always win. I don't see this as a safety issue. There's nothing unsafe about crashing. It's just not as pretty as putting up a big ol' YOUR BYTECODE IS SNOOKERED message. Having that message is not worth even a 1% degradation in runtime speed. Careful op design and possibly a validation pass before execution will hopefully keep the speed penalty to a minimum. Sounds great, but make it a separate program that gets run optionally with the default being to not run it. Validating variable-length instructions takes non-trival time and having it outside the normal execution path will allow to indulge in whatever costly-code analysis you desire. -sam
RE: A task for the interested
Simon Cozens:
# On Tue, Sep 18, 2001 at 02:51:35PM -0700, Brent Dax wrote:
# So, something more like this?
#
# Urh, how can I put this? No.
#
# I *really* want to avoid macro hackery - undef'ing this and
# then testing if it's defined and then redefining it, and
# urgh, urgh, urgh. No.
#
# I was thinking more like:
#
# +++ build_interp_starter.pl Tue Sep 18 14:48:26 2001
# @@ -59,12 +59,13 @@
# #
#
# if ($Config{dispatch} eq fpointer) {
# print INTERP EOI;
# -#define DO_OP(w,x,y,z) do { \\
# -x = (void *)z-opcode_funcs; \\
# -(void *)y = x[*w]; \\
# -w = (y)(w,z); \\
# - } while (0);
# EOI
# } elsif ($config{dispatch} eq switch) {
#print INTERP EOI;
# #define DO_OP(w,x,y,z) do { \\
# switch(*w) {...\\
# ...
# EOF
# } elsif ( ...
Okay, that's actually not too hard--just add a 'use Parrot::Config;' to
the top and check something in %PConfig. Alright.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
Re: bytecode and sizeof(IV)
Simon Cozens [EMAIL PROTECTED] writes: Yep, and the latest pedantic patch doesn't help. Also, I'm seeing this, which is weird: ld -ldbm -ldb -lm -liconv -o test_prog global_setup.o interpreter.o parrot.o register.o basic_opcodes.o memory.o bytecode.o string.o strnative.o test_main.o Definitely bugs in Configure there; cc has to be used as the linker or -lc isn't added (and possibly some of the other crt.o files too), and libraries have to be after all the object files. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: A task for the interested
On Tuesday 18 September 2001 03:55 pm, Dan Sugalski wrote: One of the things that the configure script needs to do is generate the opcode dispatch macro to either be a giant switch statement (with a fallthrough default to handle cases we don't know about) or the function table dispatch we have now. FWIW, having the function dispatch table as the default case in a switch wasn't a big win in my initial testing. The savings came from an initial test to decide to switch or lookup, but that requires the non-overrideable to be blocked so that they're easily tested (ie, opcodes 0-n). Parrot's performance does seem to differ from my initial testing, though, so you may want to benchmark it every which way. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Bytecode safety
Gibbs Tanton - tgibbs [EMAIL PROTECTED] writes: I would vote no. HOWEVER, I would think that the user should have the option to turn on checking for malformed bytecode (i.e. Safe mode). In the default case, I think the bytecode should be assumed well formed and no extra checking be performed. Something akin to gcc's --enable-checking strikes me as a really good idea. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
RE: bytecode and sizeof(IV)
Russ Allbery: # Simon Cozens [EMAIL PROTECTED] writes: # # Yep, and the latest pedantic patch doesn't help. Also, I'm seeing # this, which is weird: # # ld -ldbm -ldb -lm -liconv -o test_prog global_setup.o # interpreter.o parrot.o register.o basic_opcodes.o memory.o # bytecode.o string.o strnative.o test_main.o # # Definitely bugs in Configure there; cc has to be used as the # linker or -lc # isn't added (and possibly some of the other crt.o files too), and # libraries have to be after all the object files. I've already patched Makefile.in to fix this. --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
t/op/integer.t is IMHO wrong
set I2, -2147483648 print I2 print \\n set I3, 4294967295 print I3 print \\n end CODE 305419896 -1698898191 2147483647 -2147483648 -1 OUTPUT I think that especting 4294967295 == -1 because they have the same bit pattern ( on two's complement 32 bit machines ) is wrong Regards Mattia
Number tests
...and here are tests for the number ops. - Damien #! perl -w use Parrot::Test tests = 23; output_is(CODE, OUTPUT, set_n_nc); set N0, 1.0 set N1, 4.0 set N2, 16.0 set N3, 64.0 set N4, 256.0 set N5, 1024.0 set N6, 4096.0 set N7, 16384.0 set N8, 65536.0 set N9, 262144.0 set N10, 1048576.0 set N11, 4194304.0 set N12, 16777216.0 set N13, 67108864.0 set N14, 268435456.0 set N15, 1073741824.0 set N16, 4294967296.0 set N17, 17179869184.0 set N18, 68719476736.0 set N19, 274877906944.0 set N20, 1099511627776.0 set N21, 4398046511104.0 set N22, 17592186044416.0 set N23, 70368744177664.0 set N24, 281474976710656.0 set N25, 1.12589990684262e+15 set N26, 4.5035996273705e+15 set N27, 1.8014398509482e+16 set N28, 7.20575940379279e+16 set N29, 2.88230376151712e+17 set N30, 1.15292150460685e+18 set N31, 4.61168601842739e+18 print N0 print \\n print N1 print \\n print N2 print \\n print N3 print \\n print N4 print \\n print N5 print \\n print N6 print \\n print N7 print \\n print N8 print \\n print N9 print \\n print N10 print \\n print N11 print \\n print N12 print \\n print N13 print \\n print N14 print \\n print N15 print \\n print N16 print \\n print N17 print \\n print N18 print \\n print N19 print \\n print N20 print \\n print N21 print \\n print N22 print \\n print N23 print \\n print N24 print \\n print N25 print \\n print N26 print \\n print N27 print \\n print N28 print \\n print N29 print \\n print N30 print \\n print N31 print \\n CODE 1.00 4.00 16.00 64.00 256.00 1024.00 4096.00 16384.00 65536.00 262144.00 1048576.00 4194304.00 16777216.00 67108864.00 268435456.00 1073741824.00 4294967296.00 17179869184.00 68719476736.00 274877906944.00 1099511627776.00 4398046511104.00 17592186044416.00 70368744177664.00 281474976710656.00 1125899906842620.00 4503599627370500.00 18014398509482000.00 72057594037927904.00 288230376151712000.00 1152921504606850048.00 4611686018427389952.00 OUTPUT output_is(CODE, OUTPUT, add_n); set N0, 1.0 add N1, N0, N0 print N1 print \\n add N2, N0, N1 print N2 print \\n add N2, N2, N2 print N2 print \\n CODE 2.00 3.00 6.00 OUTPUT output_is(CODE, OUTPUT, sub_i); set N0, 424242.0 set N1, 4200.0 sub N2, N0, N1 print N2 print \\n CODE 420042.00 OUTPUT output_is(CODE, OUTPUT, mul_i); set N0, 2.0 mul N1, N0, N0 mul N1, N1, N0 mul N1, N1, N0 mul N1, N1, N0 mul N1, N1, N0 mul N1, N1, N0 mul N1, N1, N0 print N1 print \\n CODE 256.00 OUTPUT output_is(CODE, OUTPUT, div_i); set N0, 10.0 set N1, 2.0 div N2, N0, N1 print N2 print \\n set N3, 7.0 set N4, 2.0 div N3, N3, N4 print N3 print \\n set N5, 9.0 set N6, -4.0 div N7, N5, N6 print N7 print \\n CODE 5.00 3.50 -2.25 OUTPUT output_is(CODE, OUTPUT, eq_n_ic); set N0, 5.01 set N1, 5.01 set N2, 5.02 eq N0, N1, ONE, ERROR print bad\\n ONE: print ok 1\\n eq N1, N2, ERROR, TWO print bad\\n TWO: print ok 2\\n end ERROR: print bad\\n CODE ok 1 ok 2 OUTPUT output_is(CODE, OUTPUT, eq_nc_ic); set N0, 1.01 eq N0, 1.00, ERROR, ONE print bad\\n ONE: print ok 1\\n eq N0, 1.01, TWO, ERROR print bad\\n TWO: print ok 2\\n end ERROR: print bad\\n CODE ok 1 ok 2 OUTPUT output_is(CODE,
Re: t/op/integer.t is IMHO wrong
On Wed, Sep 19, 2001 at 12:51:43AM +0200, Mattia Barbon wrote: I think that especting 4294967295 == -1 because they have the same bit pattern ( on two's complement 32 bit machines ) is wrong I was wondering how long it would take for someone to notice that. : If anyone feels like defining a policy on what Parrot does with out-of-range numbers, and what happens on integer overflow, I'll submit patches to the tests to check against it. I'd rather we didn't just modify the tests to never trigger overflow conditions, however; that's just sweeping the issue under the rug. - Damien
Re: t/op/integer.t is IMHO wrong
On Wed, Sep 19, 2001 at 12:51:43AM +0200, Mattia Barbon wrote: I think that especting 4294967295 == -1 because they have the same bit pattern ( on two's complement 32 bit machines ) is wrong Oh shit, here we go again. Nick Clark, where are you? -- Thus spake the master programmer: After three days without programming, life becomes meaningless. -- Geoffrey James, The Tao of Programming
Re: Number tests
On Tue, Sep 18, 2001 at 03:52:42PM -0700, Damien Neil wrote: ...and here are tests for the number ops. Thanks, applied. -- A formal parsing algorithm should not always be used. -- D. Gries
Tests
All the tests are great! But, could everyone please remember to put an end at the end of each assembly test...cygwin doesn't like it if you don't. I think I've patched all the ones up to this point. Thanks! Tanton
Re: Tests
On Tue, Sep 18, 2001 at 06:12:48PM -0500, Gibbs Tanton - tgibbs wrote: All the tests are great! But, could everyone please remember to put an end at the end of each assembly test...cygwin doesn't like it if you don't. I think I've patched all the ones up to this point. Oops. Sorry about that; I thought I had seen a patch go through to make the ends optional. - Damien
naming conventions on opcodes
There was a thread on this recently, but I'm not sure what was resolved. Do we have a standard naming convention for opcodes? Personally, I'd like to see that we stick with (what I thought was) the original plan: a nice, simple ruleset that produces long but predictable names. - the opcode name starts with a short mnemonic prefix (e.g. mul) - every argument adds an '_x', where the exact value of 'x' is determined by the type of the args So, yes, you'd get 'mul_i_ic_ic', but who cares? It's not really that hard to type, and it is absolutely unambiguous. If you want to make the interpreter magically deduce the full opcode name from the prefix, that's cool, too. Just my 1 penny, Dave
Re: Bytecode safety
At 02:37 PM 9/18/2001 -0700, Damien Neil wrote: Proposed: Parrot should never crash due to malformed bytecode. When choosing between execution speed and bytecode safety, safety should always win. Careful op design and possibly a validation pass before execution will hopefully keep the speed penalty to a minimum. Yes, no? Yes and no. The default dispatch loop shouldn't check. The Safe dispatch loop (note the caps there... :) should check. Checking is more than just a plain safety issue. There are resource checks, different jump op functions, and a variety of disabled or paranoid things in there. It's a non-trivial problem, but it is one that we should, and must, address at some point. I hadn't planned on doing it so soon, but if someone's so inclined, that'd be great. :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: naming conventions on opcodes
At 04:31 PM 9/18/2001 -0700, Dave Storrs wrote: So, yes, you'd get 'mul_i_ic_ic', but who cares? It's not really that hard to type, and it is absolutely unambiguous. If you want to make the interpreter magically deduce the full opcode name from the prefix, that's cool, too. More to the point, it needs typing exactly twice--once in the .ops file that defines the opcode function body, and once in opcode_table. The assembler, of course, uses the smaller name. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: naming conventions on opcodes
On Tue, Sep 18, 2001 at 07:52:06PM -0400, Dan Sugalski wrote: More to the point, it needs typing exactly twice--once in the .ops file that defines the opcode function body, and once in opcode_table. The assembler, of course, uses the smaller name. Three times: And once to name the test case. : - Damien
RE: Bytecode safety
Proposed: Parrot should never crash due to malformed bytecode. When choosing between execution speed and bytecode safety, safety should always win. Careful op design and possibly a validation pass before execution will hopefully keep the speed penalty to a minimum. We can use similar model as Java bytecode. Because of poor design, the Java bytecode requires exponential algorithm to verify the bytecode, mainly caused by weak-typing on local variables (where all other parts of Java runtime are strongly typed), and the notorious jsr/ret bytecode. We should avoid the same kind of mistakes. The bytecode verification should be about O(n * ln(n)). Hong
RE: [PATCH] changing IV to opcode_t!!
Do we want the opcode to be so complicated? I thought we are
going to use this kind of thing for generic pointers. The p
member of opcode does not make any sense to me.
Hong
Earlier there was some discussion about changing typedef long IV
to
typedef union {
IV i;
void* p;
} opcode_t;
RE: [PATCH] changing IV to opcode_t!!
Ok...let me try to get this straight and I'll repatch...
opcode_t should be something that will represent the native opcode type. In
most cases it should just be long; however, there might be special systems
where it is somehting different (int, long long, etc...). IV should be a
union with a long and void* member so that we can cast from a long to a
pointer.
Is that correct?
-Original Message-
From: Hong Zhang
To: '[EMAIL PROTECTED]'
Sent: 9/18/2001 8:47 PM
Subject: RE: [PATCH] changing IV to opcode_t!!
Do we want the opcode to be so complicated? I thought we are
going to use this kind of thing for generic pointers. The p
member of opcode does not make any sense to me.
Hong
Earlier there was some discussion about changing typedef long IV
to
typedef union {
IV i;
void* p;
} opcode_t;
Re: [PATCH] changing IV to opcode_t!!
On Tue, Sep 18, 2001 at 06:47:38PM -0700, Hong Zhang wrote:
Do we want the opcode to be so complicated? I thought we are
going to use this kind of thing for generic pointers. The p
member of opcode does not make any sense to me.
Alignment.
Hong
Earlier there was some discussion about changing typedef long IV
to
typedef union {
IV i;
void* p;
} opcode_t;
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
RE: autotest
Brent Dax: # Okay, here's the results of my lame imitation of smoke # testing--a script # (highly customized for my machine) called autotest. Here's the results of a run on FreeBSD. It looks like something is broken in the integer test. (It's not my script--I get the same errors when I run `make test' manually.) --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done. autotest started at Wed Sep 19 00:00:36 2001. Starting CVS update...done. Summary- --- GCC/FreeBSD Normal: BROKEN GCC/FreeBSD Debugging: BROKEN Details- --- Configuration GCC/FreeBSD Normal is BROKEN. Step: make test STDOUT output: perl t/harness t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/26 tests, 96.15% okay t/op/number.ok, 2/23 skipped: various reasons t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans..ok Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/integer.t1 256261 3.85% 1 4 subtests skipped. *** Error code 2 Stop in /usr/home/brentdax/parrot. STDERR output: # Failed test (Parrot/Test.pm at line 73) # got: '305419896 -1698898191 2147483647 -2147483648 2147483647 ' # expected: '305419896 -1698898191 2147483647 -2147483648 -1 ' # Looks like you failed 1 tests of 26. Failed 1/5 test scripts, 80.00% okay. 1/74 subtests failed, 98.65% okay. Configuration GCC/FreeBSD Debugging is BROKEN. Step: make test STDOUT output: perl t/harness t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/26 tests, 96.15% okay t/op/number.ok, 2/23 skipped: various reasons t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans..ok Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/integer.t1 256261 3.85% 1 4 subtests skipped. *** Error code 2 Stop in /usr/home/brentdax/parrot. STDERR output: # Failed test (Parrot/Test.pm at line 73) # got: '305419896 -1698898191 2147483647 -2147483648 2147483647 ' # expected: '305419896 -1698898191 2147483647 -2147483648 -1 ' # Looks like you failed 1 tests of 26. Failed 1/5 test scripts, 80.00% okay. 1/74 subtests failed, 98.65% okay.
Purify machine
What type of machine is the hourly purify running on. It keeps dieing with a SIGBUS on most set_n_nc calls (meaning invalid alignment). This is really bad. I would like to know the type of an NV as well as the sizeof NV, sizeof IV, and sizeof void*. Thanks! Tanton
