Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote: > Nothing should read out of interp_guts.h. That's autogenerated from > opcode_table. Or it was yesterday, but things might've changed. :) Sorry, but things have changed. This is now where the op number assignments are stored. Simon
Re: Speaking of namespaces...
On Monday 10 September 2001 09:27 pm, Dan Sugalski wrote: > > Parse opcode_table. Sync up your source first, there have been some > changes to the format in the last few hours. I'll wait on those changes before delving back into the assembler for the simplified instruction handling. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Speaking of namespaces...
At 06:02 PM 9/10/2001 -0700, Damien Neil wrote: >On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote: > > >I'm thinking of writing something to generate a Parrot::Opcode.pm > > >module, so code doesn't need to parse opcode_table and interp_guts.h. > > >Sound reasonable? > > > > Yes, please do. I knew we needed one the second time I needed to parse > > opcode_table, I just haven't stopped long enough to be lazy and still > > program. (In those cases I came to a full stop...) > >OK, I'll do that sometime tonight. Should it parse opcode_table, >or should it be generated with the contents of opcode_table? Parse opcode_table. Sync up your source first, there have been some changes to the format in the last few hours. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote: > >I'm thinking of writing something to generate a Parrot::Opcode.pm > >module, so code doesn't need to parse opcode_table and interp_guts.h. > >Sound reasonable? > > Yes, please do. I knew we needed one the second time I needed to parse > opcode_table, I just haven't stopped long enough to be lazy and still > program. (In those cases I came to a full stop...) OK, I'll do that sometime tonight. Should it parse opcode_table, or should it be generated with the contents of opcode_table? - Damien
Re: Speaking of namespaces...
At 05:49 PM 9/10/2001 -0700, Damien Neil wrote: >On Mon, Sep 10, 2001 at 08:48:48PM -0400, Dan Sugalski wrote: > > At 04:56 PM 9/10/2001 -0700, Brent Dax wrote: > > >This patch seems to work on the FreeBSD box I have access to. Now to > > >figure out what's causing all those 'use of uninitialized value at > > >assembler.pl line 81' messages... > > > > It's the blank lines in opcode_table. The assembler (and disassembler) at > > some point didn't grok 'em. Patches have been applied, but you might've > > checked out before that happened. > >No, in this case, it's my fault. I didn't realize the assembler >reads op name/number mappings out of interp_guts.h, so my patch >broke the assembler. Nothing should read out of interp_guts.h. That's autogenerated from opcode_table. Or it was yesterday, but things might've changed. :) >I'm thinking of writing something to generate a Parrot::Opcode.pm >module, so code doesn't need to parse opcode_table and interp_guts.h. >Sound reasonable? Yes, please do. I knew we needed one the second time I needed to parse opcode_table, I just haven't stopped long enough to be lazy and still program. (In those cases I came to a full stop...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 08:48:48PM -0400, Dan Sugalski wrote: > At 04:56 PM 9/10/2001 -0700, Brent Dax wrote: > >This patch seems to work on the FreeBSD box I have access to. Now to > >figure out what's causing all those 'use of uninitialized value at > >assembler.pl line 81' messages... > > It's the blank lines in opcode_table. The assembler (and disassembler) at > some point didn't grok 'em. Patches have been applied, but you might've > checked out before that happened. No, in this case, it's my fault. I didn't realize the assembler reads op name/number mappings out of interp_guts.h, so my patch broke the assembler. I'm thinking of writing something to generate a Parrot::Opcode.pm module, so code doesn't need to parse opcode_table and interp_guts.h. Sound reasonable? - Damien
RE: Speaking of namespaces...
At 04:56 PM 9/10/2001 -0700, Brent Dax wrote: >This patch seems to work on the FreeBSD box I have access to. Now to >figure out what's causing all those 'use of uninitialized value at >assembler.pl line 81' messages... It's the blank lines in opcode_table. The assembler (and disassembler) at some point didn't grok 'em. Patches have been applied, but you might've checked out before that happened. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Speaking of namespaces...
Damien Neil: # On Mon, Sep 10, 2001 at 04:04:20PM -0700, Damien Neil wrote: # > The following quick-and-dirty patch appears to work. This prefixes # > all opcode functions with "Parrot_op_". I'd have made the prefix # > configurable, but the opcode generation is spread across three # > different files. # # Oops--that breaks the assembler. This patch fixes the assembler to # work with the prior patch. That explains it! :^) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Speaking of namespaces...
Damien Neil: # On Mon, Sep 10, 2001 at 06:58:23PM -0400, Dan Sugalski wrote: # > At 03:52 PM 9/10/2001 -0700, Damien Neil wrote: # > >Parrot fails to work in very obscure ways on FreeBSD. After some # > >poking around, I tracked the problem to the "end" op--this appears # > >to conflict with something inside libc. Renaming the op fixes the # > >problem. # > # > Ah, that's what was killing the build on Nat's machine. # Patch, by chance? # # The following quick-and-dirty patch appears to work. This prefixes # all opcode functions with "Parrot_op_". I'd have made the prefix # configurable, but the opcode generation is spread across three # different files. # # (Aside: What's the best way to generate a useful patch with cvs? # The following comes from "cvs -q diff -u".) This patch seems to work on the FreeBSD box I have access to. Now to figure out what's causing all those 'use of uninitialized value at assembler.pl line 81' messages... --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 04:04:20PM -0700, Damien Neil wrote:
> The following quick-and-dirty patch appears to work. This prefixes
> all opcode functions with "Parrot_op_". I'd have made the prefix
> configurable, but the opcode generation is spread across three
> different files.
Oops--that breaks the assembler. This patch fixes the assembler to
work with the prior patch.
- Damien
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.6
diff -u -u -r1.6 assemble.pl
--- assemble.pl 2001/09/10 21:26:08 1.6
+++ assemble.pl 2001/09/10 23:43:30
@@ -15,7 +15,7 @@
open GUTS, "interp_guts.h";
my $opcode;
while () {
-next unless /\tx\[(\d+)\] = ([a-z_]+);/;
+next unless /\tx\[(\d+)\] = Parrot_op_([a-z_]+);/;
$opcodes{$2}{CODE} = $1;
}
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 06:58:23PM -0400, Dan Sugalski wrote:
> At 03:52 PM 9/10/2001 -0700, Damien Neil wrote:
> >Parrot fails to work in very obscure ways on FreeBSD. After some
> >poking around, I tracked the problem to the "end" op--this appears
> >to conflict with something inside libc. Renaming the op fixes the
> >problem.
>
> Ah, that's what was killing the build on Nat's machine. Patch, by chance?
The following quick-and-dirty patch appears to work. This prefixes
all opcode functions with "Parrot_op_". I'd have made the prefix
configurable, but the opcode generation is spread across three
different files.
(Aside: What's the best way to generate a useful patch with cvs?
The following comes from "cvs -q diff -u".)
- Damien
Index: build_interp_starter.pl
===
RCS file: /home/perlcvs/parrot/build_interp_starter.pl,v
retrieving revision 1.2
diff -u -u -r1.2 build_interp_starter.pl
--- build_interp_starter.pl 2001/09/10 21:26:09 1.2
+++ build_interp_starter.pl 2001/09/10 23:07:08
@@ -27,7 +27,7 @@
my($name) = split /\s+/;
my $num = $count;
$num = 0 if $name eq 'end';
-print INTERP "\tx[$num] = $name; \\\n";
+print INTERP "\tx[$num] = Parrot_op_$name; \\\n";
$count++ unless $name eq 'end';
}
print INTERP "} while (0);\n";
Index: make_op_header.pl
===
RCS file: /home/perlcvs/parrot/make_op_header.pl,v
retrieving revision 1.3
diff -u -u -r1.3 make_op_header.pl
--- make_op_header.pl 2001/09/10 21:26:09 1.3
+++ make_op_header.pl 2001/09/10 23:07:08
@@ -6,7 +6,7 @@
next if /^\s*#/ or /^\s*$/;
chomp;
($name, undef) = split /\t/, $_;
-print "IV *$name(IV *, struct Perl_Interp *);\n";
+print "IV *Parrot_op_$name(IV *, struct Perl_Interp *);\n";
}
BEGIN {
Index: process_opfunc.pl
===
RCS file: /home/perlcvs/parrot/process_opfunc.pl,v
retrieving revision 1.3
diff -u -u -r1.3 process_opfunc.pl
--- process_opfunc.pl 2001/09/10 21:26:09 1.3
+++ process_opfunc.pl 2001/09/10 23:07:08
@@ -105,7 +105,7 @@
my $line = shift;
my ($name) = $line =~ /AUTO_OP\s+(\w+)/;
-print OUTPUT "IV *$name(IV cur_opcode[], struct Perl_Interp *interpreter) {\n";
+print OUTPUT "IV *Parrot_op_$name(IV cur_opcode[], struct Perl_Interp
+*interpreter) {\n";
return($name, " return cur_opcode + "
. $opcode{$name}{RETURN_OFFSET}. ";\n}\n");
}
@@ -114,7 +114,7 @@
my $line = shift;
my ($name) = $line =~ /MANUAL_OP\s+(\w+)/;
-print OUTPUT "IV *$name(IV cur_opcode[], struct Perl_Interp *interpreter) {\n";
+print OUTPUT "IV *Parrot_op_$name(IV cur_opcode[], struct Perl_Interp
+*interpreter) {\n";
print OUTPUT " IV return_offset = 1;\n";
return($name, " return cur_opcode + return_offset;\n}\n");
}
Index: test.pbc
===
RCS file: /home/perlcvs/parrot/test.pbc,v
retrieving revision 1.2
diff -u -u -r1.2 test.pbc
Binary files /tmp/cvsqe7MSGr3cy and test.pbc differ
