moving integer constants to the constant table
This patch moves integer constants to the constant table if the size chosen for integers is not the same as the size chosen for opcodes. It will work whether or not the size is greater or less. HOWEVER, I experience problems on Tru64 when I set INTVAL to int instead of long because it wasn't large enough to hold a pointer and the casts from pointer to INTVAL in memory.c, strnative.c and register.c failed. That has nothing to do with this patch, only that we do not check to see if the integer is as big as a pointer. I'll try to patch that later. This patch, on the other hand, works fine on CygWin, Solaris 5.8, and Tru64. I would like to get other people's feedback on whether or not it works for some of the other systems. Summary of what changed: 1.) All assembler pack types are now $pack_type{op} except for an explicit intval. The intval pack type is only used in NON bytecode areas (such as the constant table). All bytecode is $pack_type{op}. 2.) Integer and number constants are no longer changed to the form [nc:N], but instead are just N as nothing acutally needed the [nc:N] format. 3.) Fixed some inconsistencies between PackFile and packfile.c in the way the string constants were handled (it relied on op and intval to be the same length) 4.) Used INT_CONST in basic_opcodes.ops wherever an ic was used. 5.) If sizeof('opcode') == sizeof('intval') then all integer constants are inline, otherwise, they are out of line. 6.) The constant table still uses intval exclusively for its sizes and such. 7.) Labels are still treated as integers and as such can now end up in the constants table. 8.) Evaluating numeric and integer constants in the assembler is now postponed until the type of the constant is known so that 0 can still become a FLOATVAL constant without having to type 0.0 Any and all feedback is appreciated. Thanks! Tanton patch.dat
Re: Manifest constants?
On Tue, 2001-10-02 at 08:23, Dan Sugalski wrote: > >Is 'pi' a string to be looked up in a table at assemble time and > >converted to an "intrinsic constant table index" > > Yes. At some point the assembler needs to have a way to declare named > constants, we just haven't gotten there yet. > How about the attached patch? It adds these directives: DCI, DCN, DCP, DCS for "Define Constant (Integer, Number, PMC, String)" It (currently) works by abusing the equates. In the cases of Integer and PMC, it is exactly equivalent. In the case of Number and String, the value of the equate is [sc:#] or [nc:#] which is the index into the look up table. It could easily be expanded to store these constant names somewhere other than the equate hash. Since we're anticipating the release of 0.02, I didn't apply it, and I'd like feedback on it. Brian Index: Parrot/Assembler.pm === RCS file: /home/perlcvs/parrot/Parrot/Assembler.pm,v retrieving revision 1.3 diff -u -r1.3 Assembler.pm --- Parrot/Assembler.pm 2001/10/03 23:58:41 1.3 +++ Parrot/Assembler.pm 2001/10/04 00:29:23 @@ -670,7 +670,8 @@ sub has_asm_directive { return $_[0] =~ /^[_a-zA-Z]\w*\s+macro\s+.+$/i || - $_[0] =~ /^[_a-zA-Z]\w*\s+equ\s+.+$/i; + $_[0] =~ /^[_a-zA-Z]\w*\s+equ\s+.+$/i || +$_[0] =~ /^[_a-zA-Z]\w*\s+dc[inps]\s+.+$/i ; } @@ -678,8 +679,10 @@ =head2 handle_asm_directive -Processes macros and equ directives. equ directives get stored in an equ hash. -Macros store all program lines in an array. +Processes macro definitions, dc* declarations, and equ directives. equ +directives get stored in an equ hash. Macros store all program lines in an +array. dc* declarations create a constant and an equ which refers to the +constant. NOTE: This function modifies @program. @@ -691,6 +694,26 @@ my( $name, $data ) = ($1, $2); $equate{$name} = $data; return 1; + } + elsif( $line =~ /^([_a-zA-Z]\w*)\s+dc([inps])\s+(.+)$/i ) { + my( $name, $type, $data ) = ($1, $2, $3); + if( $type eq "i" ) { + # TODO: we cheat on integers, since they really don't go in the + # constants table. + $equate{$name} = $data; + } + elsif( $type eq "n" ) { + $equate{$name} = constantize_number($data); + } + elsif( $type eq "p") { + # TODO: what does a PMC constant look like? + $equate{$name} = $data; + } + elsif( $type eq "s") { + $data=~s/^"(.+)"$/$1/; + $equate{$name} = constantize_string($data); + } + return 1; } elsif( $line =~ /^([_a-zA-Z]\w*)\s+macro\s+(.+)$/i ) { # a macro definition
[PATCH] Proposed 'myconfig' script
Here's a patch to include a 'myconfig' script in the parrot distribution, similar to the one in perl5's distribution. The output looks something like: Summary of my parrot configuration: Platform where perl 5.007002 was built: osname=linux, osvers=2.2.17, archname=sparc64-linux-64int uname=linux dendrite 2.2.17 #1 tue jul 4 14:22:29 edt 2000 sparc64 unknown byteorder=87654321 Compiler: cc=cc, ccflags=-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include debugging=0 intvalsize=8,packtype_i=q, intval=long long numvalsize=8,packtype_n=d, numval=double opcode_t_size=8, packtype_op=q, opcode_t=long long Linker and Libraries: ld=cc libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil Here's the patch. Note that I changed Configure.pl and test_c.in to use the new names 'intval' and 'numval' so that they are reported correctly in the myconfig output. The strange structure is so that it works as perl5's myconfig works. It's a script, so running ./myconfig works. It's also a plain text file that can be mailed and contains the same information. diff -r -N -u parrot/Configure.pl parrot-andy/Configure.pl --- parrot/Configure.pl Tue Oct 2 10:01:30 2001 +++ parrot-andy/Configure.plWed Oct 3 16:54:43 2001 @@ -61,10 +61,10 @@ #defaults for them. #XXX Figure out better defaults my(%c)=( - iv => ($Config{ivtype} ||'long'), + intval => ($Config{ivtype} ||'long'), intvalsize => undef, - nv => ($Config{nvtype} ||'double'), + numval => ($Config{nvtype} ||'double'), numvalsize => undef, opcode_t => ($Config{ivtype} ||'long'), @@ -105,8 +105,8 @@ 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("And your floats?", 'nv'); +prompt("How big would you like integers to be?", 'intval'); +prompt("And your floats?", 'numval'); prompt("What is your native opcode type?", 'opcode_t'); unless( $c{debugging} ) { @@ -182,6 +182,11 @@ buildconfigpm(); # and the types file buildfile("Types_pm", "Parrot"); +# and ./myconfig +# This should perhaps be changed into some sort of myconfig_in file to fit in +# with the rest of the Configure.pl scheme. +do 'myconfig.PL' or warn("Error generating myconfig."); + print <<"END"; diff -r -N -u parrot/MANIFEST parrot-andy/MANIFEST --- parrot/MANIFEST Sun Sep 30 16:25:22 2001 +++ parrot-andy/MANIFESTWed Oct 3 16:54:43 2001 @@ -49,6 +49,7 @@ little_languages/jakoc make_op_header.pl memory.c +myconfig.PL opcheck.pl opcode_table packfile.c diff -r -N -u parrot/Makefile.in parrot-andy/Makefile.in --- parrot/Makefile.in Mon Oct 1 18:00:23 2001 +++ parrot-andy/Makefile.in Wed Oct 3 16:56:07 2001 @@ -69,6 +69,7 @@ clean: $(RM_F) *$(O) *.s basic_opcodes.c $(INC)/interp_guts.h $(INC)/op.h $(TEST_PROG) + $(RM_F) myconfig test: $(PERL) t/harness diff -r -N -u parrot/config_h.in parrot-andy/config_h.in --- parrot/config_h.in Tue Oct 2 10:01:30 2001 +++ parrot-andy/config_h.in Wed Oct 3 16:54:43 2001 @@ -6,8 +6,8 @@ #if !defined(PARROT_CONFIG_H_GUARD) #define PARROT_CONFIG_H_GUARD -typedef ${iv} INTVAL; -typedef ${nv} FLOATVAL; +typedef ${intval} INTVAL; +typedef ${numval} FLOATVAL; typedef ${opcode_t} opcode_t; diff -r -N -u parrot/myconfig.PL parrot-andy/myconfig.PL --- parrot/myconfig.PL Wed Dec 31 19:00:00 1969 +++ parrot-andy/myconfig.PL Wed Oct 3 16:55:04 2001 @@ -0,0 +1,55 @@ +#!/usr/local/bin/perl -w +use strict; +use Parrot::Config; +use Config; + +my $file = "myconfig"; +open OUT,">$file" or die "Can't create $file: $!"; +print "Extracting $file (with variable substitutions)\n"; + +print OUT <<"!GROK!THIS!"; +$Config{'startperl'} -w +eval 'exec perl -S \$0 "\$@"' + if 0; +!GROK!THIS! +print OUT <<'NO_SUBS'; +# This script is designed to provide a handy summary of the configuration +# information being used to build parrot. + +# XXX System ID stuff we grab from perl's Configure. (Note this describes +# where this perl was built. It might well have been built on a different +# system. Better eventually to determine this sort of stuff during +# parrot's configuration.) + +# XXX Note that the text lines /^Summary of/ .. /^\s*\$/ should perhaps +# be copied into Parrot::Config.pm, analagously to the way it's done +# in perl5. + +use strict; +use Parrot::Config; +use Config; # Perl5's Config. + +NO_SUBS + +print OUT <<"!GROK!THIS!"; +print <<'NO_SUBS'; +Summary of my parrot configuration: + Platform where perl $] was built: +osname=$Config{osname}, osvers=$Config{osvers}, archname=$Config{archname} +
Re: Parrot 0.0.2
[EMAIL PROTECTED] (Simon Cozens) writes: > Any objections to a release today? How's Cygwin and Win32 looking? except that `make test` always just tells me tat `test' is up to date, then both cygwin and darwin looks good. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
RE: SV: OpenVMS
Michael G Schwern: # On Wed, Oct 03, 2001 at 07:09:06PM +0100, Simon Cozens wrote: # > On Wed, Oct 03, 2001 at 01:55:39PM -0400, Dan Sugalski wrote: # > > If you want to wait, that's fine. I don't think I'm going # to get untangled # > > for another day or three, though. # > # > Waiting might also help to shake out whatever's wrong with # Win2K. Maybe # > it's just Brent's system being funny. (And I'd try playing # with Compaq # > Test Drive's OpenVMS system, but I can't find gzip, vmstar # or, unfortunately, # > perl. And damn, it's been a long time since I used DCL.) # # Unpleasent things happen with 5.005_03 ... # Okay. Now I'm gonna probe Perl 5's configuration to see # what headers you have around. This could take a bit on slow # machines... # Out of memory! # Out of memory! # %SYSTEM-F-ABORT, abort Oof. It probably doesn't like the 'grep {/pattern/} keys %Config' very much. Replace: foreach(grep {/pattern/} keys %Config) { blah blah blah with: while($_=each %Config) { next unless /pattern/; blah blah blah (untested) and it ought to work okay. (Fill in the correct /pattern/, of course.) # bleadperl 12109 is slightly less unpleasent. # # Okay. Now I'm gonna probe Perl 5's configuration to see # what headers you have around. This could take a bit on slow # machines... # # Alright, now I'm gonna check some stuff by compiling and running # a small C program. This could take a bit... # Use of uninitialized value in concatenation (.) or string at # configure.pl line 137. # %DCL-W-VALREQ, missing qualifier or keyword value - supply # all required values \INCLUDE\ # C compiler died! at configure.pl line 137. # %RMS-E-FNF, file not found Yeah, that whole test.c thing is highly Unix-centric. I'll probably wrap it up in a function so hints files can override its behavior. If you can't figure out how to adapt what's there for VMS, you can always replace the split() with the actual values of the things. (Yucky, I know, but it would at least work.) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
Re: [BUG] Mandlebrot core
On Wed, 2001-10-03 at 14:43, Leon Brocard wrote: > Leon Brocard sent the following bits through the ether: > > > It's all greek to me, Leon > > The following bytecode: > > 0075 [01d4]: 0032 0008 000a 0008 >gt_nc_ic N8, [nc:10], L2 > > is wrong. It shouldn't be [nc:10]. 10 is the numeric constant which > should have been in the constant table ([nc:10] refers to the 10th > constant, there are only constants 0-6 hence the crash), so I point > the finger at the assembler (of which I little). But I know more about > debugging coredumps now, honest. Its sort of the assembler, but an easy fix is to make the constant "10.0" instead of 10. Brian > > Leon > -- > Leon Brocard.http://www.astray.com/ > Nanoware...http://www.nanoware.org/ > > ... I tried to think but nothing happened!
Re: SV: OpenVMS
On Wed, Oct 03, 2001 at 07:09:06PM +0100, Simon Cozens wrote: > On Wed, Oct 03, 2001 at 01:55:39PM -0400, Dan Sugalski wrote: > > If you want to wait, that's fine. I don't think I'm going to get untangled > > for another day or three, though. > > Waiting might also help to shake out whatever's wrong with Win2K. Maybe > it's just Brent's system being funny. (And I'd try playing with Compaq > Test Drive's OpenVMS system, but I can't find gzip, vmstar or, unfortunately, > perl. And damn, it's been a long time since I used DCL.) Unpleasent things happen with 5.005_03 $ perl Configure.pl Subroutine ln redefined at /perl_root/lib/ExtUtils/Manifest.pm line 27. Parrot Configure Copyright (C) 2001 Yet Another Society Since you're running this script, you obviously have Perl 5--I'll be pulling some defaults from its configuration. First, I'm gonna check the manifest, to make sure you got a complete Parrot kit. Okay, we found everything. Next you'll need to answer a few questions about your system. Rules are the same as Perl 5's Configure--defaults are in square brackets, and you can hit enter to accept them. What C compiler do you want to use? [CC/DECC] How about your linker? [Link] What flags would you like passed to your C compiler? [/float=ieee/Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList -I./include] Which libraries would you like your C compiler to include? [] How big would you like integers to be? [long] And your floats? [double] What is your native opcode type? [long] Okay. Now I'm gonna probe Perl 5's configuration to see what headers you have around. This could take a bit on slow machines... Out of memory! Out of memory! %SYSTEM-F-ABORT, abort bleadperl 12109 is slightly less unpleasent. Okay. Now I'm gonna probe Perl 5's configuration to see what headers you have around. This could take a bit on slow machines... Alright, now I'm gonna check some stuff by compiling and running a small C program. This could take a bit... Use of uninitialized value in concatenation (.) or string at configure.pl line 137. %DCL-W-VALREQ, missing qualifier or keyword value - supply all required values \INCLUDE\ C compiler died! at configure.pl line 137. %RMS-E-FNF, file not found -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One 36 haikus would scare the shit out of me. Thank goodness for paste! -- Schwern
Re: [BUG] Mandlebrot core
Leon Brocard sent the following bits through the ether: > It's all greek to me, Leon The following bytecode: 0075 [01d4]: 0032 0008 000a 0008 gt_nc_ic N8, [nc:10], L2 is wrong. It shouldn't be [nc:10]. 10 is the numeric constant which should have been in the constant table ([nc:10] refers to the 10th constant, there are only constants 0-6 hence the crash), so I point the finger at the assembler (of which I little). But I know more about debugging coredumps now, honest. Leon -- Leon Brocard.http://www.astray.com/ Nanoware...http://www.nanoware.org/ ... I tried to think but nothing happened!
Re: Parrot 0.0.2
On Wed, Oct 03, 2001 at 12:08:54PM -0700, Benjamin Stuhl wrote: > # got: 'failure > ' What no debugging print output? -- We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -- Larry Wall
[BUG] Mandlebrot core
Simon Cozens sent the following bits through the ether: > No release today, folks. False alarm. You know, I think I have a case for adding my Mandlebrot generator to the test suite. 'Cos it coredumps on my PIII Linux laptop ;-) I have no C debugging skills, but grab it from the bottom of http://www.parrotcode.org/examples/ and with any luck you'll get something like: [acme@piglet parrot]$ ./assemble.pl mandlebrot.pasm > run.pbc [acme@piglet parrot]$ ./test_prog run.pbc Segmentation fault (core dumped) [acme@piglet parrot]$ gdb ./test_prog core ... #0 0x0804b759 in Parrot_op_gt_nc_ic (cur_opcode=0x806143c, interpreter=0x8055048) at basic_opcodes.c:413 413 if (interpreter->num_reg->registers[cur_opcode[1]] > interpreter->code->const_table->constants[cur_opcode[2]]->number) { (gdb) bt #0 0x0804b759 in Parrot_op_gt_nc_ic (cur_opcode=0x806143c, interpreter=0x8055048) at basic_opcodes.c:413 #1 0x08048d70 in runops_notrace_core (interpreter=0x8055048) at interpreter.c:66 #2 0x08048fd6 in runops_generic (core=0x8048cf8 , interpreter=0x8055048) at interpreter.c:147 #3 0x0804905e in runops (interpreter=0x8055048, code=0x80610b8) at interpreter.c:172 #4 0x0804ec96 in main (argc=2, argv=0xbb64) at test_main.c:103 #5 0x400c5177 in __libc_start_main (main=0x804e89c , argc=2, ubp_av=0xbb64, init=0x80488e4 <_init>, fini=0x804ed10 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbb5c) at ../sysdeps/generic/libc-start.c:129 It's all greek to me, Leon -- Leon Brocard.http://www.astray.com/ Nanoware...http://www.nanoware.org/ ... "1001 Things To Do With Whipped Cream", LGLB (1995)
RE: Parrot 0.0.2
--- Brent Dax <[EMAIL PROTECTED]> wrote: > > > --Brent Dax > [EMAIL PROTECTED] > Configure pumpking for Perl 6 > > They *will* pay for what they've done. > > # -Original Message- > # From: Simon Cozens [mailto:[EMAIL PROTECTED]] > # Sent: Wednesday, October 03, 2001 09:51 > # To: Brent Dax > # Cc: [EMAIL PROTECTED] > # Subject: Re: Parrot 0.0.2 > # > # > # OK, let's try and clear this up. > # > # On Wed, Oct 03, 2001 at 09:39:32AM -0700, Brent Dax > wrote: > # > # got: 'Seem to have negative Nx > # > not ok > # > ' > # > # expected: 'Seem to have negative Nx > # > Seem to have positive Nx after pop > # > ' > # > # Don't know what's going on here. > # > # > t/op/string.NOK 4# Failed test > (Parrot/Test.pm at line 74) > # > # got: 'Error: Control left bounds of > byte-code > # block (now at > # > location > # > 31)! > # > # There isn't an "end" on that test. Fixed. > # > # > # got: 'failure > # > ' > # > # Since there was no other output, this failed: > # timeI0 > # ge I0, 0, OK1 > # > # Now that's anyone's guess. > # > # I've added some debugging prints, can you try a resync? I resynced at 3:05pm EDT today, and I'm seeing the same errors (Pentium III, Win2k): C:\parrot>perl t/harness t/op/basic..ok t/op/bitwiseok t/op/integerok t/op/number.ok t/op/stacks.NOK 5# Failed test (Parrot/Test.pm at line 74) # got: 'Seem to have negative Nx not ok ' # expected: 'Seem to have negative Nx Seem to have positive Nx after pop ' t/op/stacks.ok 9/9# Looks like you failed 1 tests of 9. t/op/stacks.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 5 Failed 1/9 tests, 88.89% okay (-3 skipped tests: 5 okay, 55.56%) t/op/string.ok, 1/11 skipped: TODO: printing empty string reg segfaults t/op/time...NOK 2# Failed test (Parrot/Test.pm at line 74) # got: 'failure ' # expected: 'ok, (!= 1970) Grateful Dead not ok, (now>before) timelords need not apply ' # Looks like you failed 1 tests of 2. t/op/time...dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 2 Failed 1/2 tests, 50.00% okay t/op/trans..ok Failed Test Status Wstat Total Fail Failed List of Failed t/op/stacks.t 1 256 91 11.11% 5 t/op/time.t1 256 21 50.00% 2 4 subtests skipped. Failed 2/8 test scripts, 75.00% okay. 2/100 subtests failed, 98.00% okay. -- BKS __ Do You Yahoo!? NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1
Re: SV: OpenVMS
On Wed, Oct 03, 2001 at 01:55:39PM -0400, Dan Sugalski wrote: > If you want to wait, that's fine. I don't think I'm going to get untangled > for another day or three, though. Waiting might also help to shake out whatever's wrong with Win2K. Maybe it's just Brent's system being funny. (And I'd try playing with Compaq Test Drive's OpenVMS system, but I can't find gzip, vmstar or, unfortunately, perl. And damn, it's been a long time since I used DCL.) No release today, folks. False alarm. -- With the arrest of Dimitry Sklyarov it has become apparent that it is not safe for non US software engineers to visit the United States. - Alan Cox
Re: SV: OpenVMS
At 06:49 PM 10/3/2001 +0100, Simon Cozens wrote: >On Wed, Oct 03, 2001 at 01:52:05PM -0400, Dan Sugalski wrote: > > If we don't build on VMS it's not a show-stopper for 0.02. > >I think it is. There's not much point having a core platforms >list if we selectively ignore it. :( Well, like any other rule you occasionally get a pass. :) If you want to wait, that's fine. I don't think I'm going to get untangled for another day or three, though. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: SV: OpenVMS
On Wed, Oct 03, 2001 at 01:52:05PM -0400, Dan Sugalski wrote: > If we don't build on VMS it's not a show-stopper for 0.02. I think it is. There's not much point having a core platforms list if we selectively ignore it. :( -- * DrForr digs around for a fresh IV drip bag and proceeds to hook up. Coffee port. Firewalled, like everything else around here.
RE: Parrot 0.0.2
--Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done. # -Original Message- # From: Simon Cozens [mailto:[EMAIL PROTECTED]] # Sent: Wednesday, October 03, 2001 09:51 # To: Brent Dax # Cc: [EMAIL PROTECTED] # Subject: Re: Parrot 0.0.2 # # # OK, let's try and clear this up. # # On Wed, Oct 03, 2001 at 09:39:32AM -0700, Brent Dax wrote: # > # got: 'Seem to have negative Nx # > not ok # > ' # > # expected: 'Seem to have negative Nx # > Seem to have positive Nx after pop # > ' # # Don't know what's going on here. # # > t/op/string.NOK 4# Failed test (Parrot/Test.pm at line 74) # > # got: 'Error: Control left bounds of byte-code # block (now at # > location # > 31)! # # There isn't an "end" on that test. Fixed. # # > # got: 'failure # > ' # # Since there was no other output, this failed: # timeI0 # ge I0, 0, OK1 # # Now that's anyone's guess. # # I've added some debugging prints, can you try a resync? I tried it and ended up with something weird: C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot>pmake test Reading C:/Perl/site/lib/Make.pm Reading C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot\makefile C:\Perl\bin\perl.exe t/harness t/op/basic..ok t/op/bitwiseok t/op/integerok t/op/number.ok t/op/stacks.NOK 5# Failed test (Parrot/Test.pm at line 74) # got: 'Seem to have negative Nx not ok ' (etc, as before) Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/stacks.t1 256 91 11.11% 5 t/op/time.t 1 256 21 50.00% 2 4 subtests skipped. Failed 2/8 test scripts, 75.00% okay. 2/100 subtests failed, 98.00% okay. Code 65280 from C:\Perl\bin\perl.exe t/harness at C:/Perl/site/lib/Make.pm line 265. C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot>perl t/harness t/op/basic..ok t/op/bitwiseok t/op/integerok t/op/number.ok t/op/stacks.ok, 3/9 skipped: various reasons t/op/string.ok, 1/11 skipped: TODO: printing empty string reg segfaults t/op/time...ok t/op/trans..ok All tests successful, 4 subtests skipped. Files=8, Tests=100, 32 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) Weird, huh? If I use nmake /a (forces it to do test, even though it thinks test is up to date) instead of pmake, I get the same output as pmake. This is pretty spooky...
Re: SV: OpenVMS
At 07:47 PM 10/3/2001 +0200, Henrik Tougaard wrote: > > Fra: Simon Cozens [mailto:[EMAIL PROTECTED]] > > > > Botheration, I forgot all about this. How's it coming on? > >I haven't had any tuits yet. >Has anybody involved the vms-perl list? I have, but everyone's tied up. As am I, unfortunately. > >Does VMS have to be on the core list?? > Yes. Partially for the same reason that Windows native is--it's *not* by any stretch of the imagination Unix. If we don't build on VMS it's not a show-stopper for 0.02. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
SV: OpenVMS
> Fra: Simon Cozens [mailto:[EMAIL PROTECTED]] > > Botheration, I forgot all about this. How's it coming on? I haven't had any tuits yet. Has anybody involved the vms-perl list? I forgot to include them in the original mail, but someone migth have tuits enough to start it. Does VMS have to be on the core list?? -- Henrik Tougaard, Copenhagen, Denmark "The first rule of Perl Club is, we don't talk about Perl Club" - Dave Cross at YAPC::Europe 2.0.01
RE: Parrot 0.0.2
Simon Cozens: # On Wed, Oct 03, 2001 at 05:51:14PM +0100, Simon Cozens wrote: # > > # got: 'Seem to have negative Nx # > > not ok # > > # expected: 'Seem to have negative Nx # > > Seem to have positive Nx after pop # # So pop_n is broken on Win32. Did you see any compiler warnings # in the stacks code? Nope. No warnings at all (which is better than I can say for bleadperl :^) ). --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
OpenVMS
Botheration, I forgot all about this. How's it coming on? -- IBM: It may be slow, but it's hard to use.
Re: Parrot 0.0.2
Simon -- > Don't worry, Windows being broken has bought you some time... I don't really need time (since its done). But, I'll take this as "go ahead and commit it when you're ready" (which is now). 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] Asm macros fixed. BONUS: label arithmetic --> poor-man'ssubroutines
All -- I have fixed the macro facility in the assembler (there was a goof in argument processing in expand_macro). I discovered this while implementing label arithmetic for the assembler so all the tests in t/basic.t could be enabled. It now works, and as an added bonus, the net result is "poor man's subroutines". See the attached file call.pasm for an example. 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 \_/ ? ChangeLog ? asm.patch ? call.pasm Index: disassemble.pl === RCS file: /home/perlcvs/parrot/disassemble.pl,v retrieving revision 1.13 diff -a -u -r1.13 disassemble.pl --- disassemble.pl 2001/09/30 20:25:22 1.13 +++ disassemble.pl 2001/10/03 16:59:42 @@ -221,10 +221,10 @@ printf "#\n"; printf "# Segments:\n"; printf "#\n"; -printf "# * Magic Number: %8d bytes\n", sizeof('iv'); +printf "# * Magic Number: %8d bytes\n", sizeof('intval'); printf "# * Fixup Table: %8d bytes\n", $pf->fixup_table->packed_size; printf "# * Const Table: %8d bytes\n", $pf->const_table->packed_size; -printf "# * Byte Code:%8d bytes (%d IVs)\n", length($pf->byte_code), length($pf->byte_code) / sizeof('iv'); +printf "# * Byte Code:%8d bytes (%d IVs)\n", length($pf->byte_code), +length($pf->byte_code) / sizeof('intval'); dump_const_table($pf); disassemble_byte_code($pf); Index: Parrot/Assembler.pm === RCS file: /home/perlcvs/parrot/Parrot/Assembler.pm,v retrieving revision 1.1 diff -a -u -r1.1 Assembler.pm --- Parrot/Assembler.pm 2001/09/30 20:25:23 1.1 +++ Parrot/Assembler.pm 2001/10/03 16:59:43 @@ -9,6 +9,7 @@ # use strict; +use Carp qw(&confess); ### @@ -423,9 +424,34 @@ add_line_to_listing( sprintf( "\t%08x %s\n", $label{$_}, $_ ) ); } + # + # Resolve label arithmetic: + # + + foreach my $label (keys %fixup) { +next unless $label =~ m/^\[(.*)\]$/; + +my $exp = $1; + +$exp =~ s/([A-Za-z_][A-Za-z0-9_]*)/$label{$1}/g; + +my $result = (eval $exp) / sizeof('intval'); + +while (scalar(@{$fixup{$label}})) { + my $offset = shift @{$fixup{$label}}; + substr($bytecode, $offset, sizeof('intval')) = pack_arg('intval', $result); +} + +delete $fixup{$label}; + } + + # + # Complain about undefined symbols: + # + return unless keys %fixup; - print STDERR "SQUAK! These symbols were referenced but not defined:\n"; + print STDERR "These symbols were referenced but not defined:\n"; add_line_to_listing( "\nUNDEFINED SYMBOLS:\n" ); @@ -437,8 +463,10 @@ print STDERR "\n"; add_line_to_listing( "\t$_\n" ); } + + # TODO: some day, unresolved symbols won't be an error! - exit; # some day, unresolved symbols won't be an error! + error("Cannot assemble with unresolved symbols!\n", $file, $line); } @@ -548,6 +576,9 @@ } $code = replace_constants($code); + +while ($code =~ s/\[([^\] \t]*)\s+/[$1/) { }; # Erase all space within label +arithmetic + $code =~ s/,/ /g; $code =~ s/#.*$//; # strip end of line comments @@ -556,6 +587,7 @@ if( exists( $macros{$opcode} ) ) { # found a macro, expand it and append its lines to the front of # the program lines array. + my @expanded_lines = expand_macro( $opcode, @args ); unshift( @program, @expanded_lines ); $lineinfo->[2] = ''; @@ -667,7 +699,7 @@ $macros{$name} = [ [split( /,\s*/, $args)], [] ]; while( 1 ) { if( !scalar( @program ) ) { -error( "The end of the macro was never seen" ); +error( "The end of the macro was never seen", $file, $line); } my $l = shift( @program ); ($file, $line, $pline, $sline) = @$l; @@ -675,7 +707,7 @@ last; } elsif( $pline =~ /^\S+\s+macro/ ) { -error( "Cannot define a macro inside of another macro" ); +error( "Cannot define a macro inside of another macro", $file, $line ); } else { push( @{$macros{$cur_macro}[1]}, $l ); @@ -699,48 +731,66 @@ sub handle_label { my ($label, $code) = $pline =~ /^(\S+):\s*(.+)?/; - # if the label starts with a dollar sign, then it is a local label. - if( $label =~ /^\$/ ) { -# a local label + + # + # Local labels (begin with '$'): + # + + if ($label =~ /^\$/) { if( exists( $local_label{ $label } ) ) {
Re: Parrot 0.0.2
On Wed, Oct 03, 2001 at 05:51:14PM +0100, Simon Cozens wrote: > > # got: 'Seem to have negative Nx > > not ok > > # expected: 'Seem to have negative Nx > > Seem to have positive Nx after pop So pop_n is broken on Win32. Did you see any compiler warnings in the stacks code? -- perl -le 'print (@) - $; +$ (- % _); * *+* *'
Re: Parrot 0.0.2
On Wed, Oct 03, 2001 at 12:53:40PM -0400, Gregor N. Purdy wrote: > I'd like to have a working macro facility in the assembler for 0.0.2, > please. Don't worry, Windows being broken has bought you some time... -- "In space 'cat scream.au | tee /dev/null > /dev/audio'..." - Ben, in the monastery.
Re: Parrot 0.0.2
OK, let's try and clear this up. On Wed, Oct 03, 2001 at 09:39:32AM -0700, Brent Dax wrote: > # got: 'Seem to have negative Nx > not ok > ' > # expected: 'Seem to have negative Nx > Seem to have positive Nx after pop > ' Don't know what's going on here. > t/op/string.NOK 4# Failed test (Parrot/Test.pm at line 74) > # got: 'Error: Control left bounds of byte-code block (now at > location > 31)! There isn't an "end" on that test. Fixed. > # got: 'failure > ' Since there was no other output, this failed: timeI0 ge I0, 0, OK1 Now that's anyone's guess. I've added some debugging prints, can you try a resync? -- We use Linux for all our mission-critical applications. Having the source code means that we are not held hostage by anyone's support department. (Russell Nelson, President of Crynwr Software)
Re: Parrot 0.0.2
Simon -- > Any objections to a release today? How's Cygwin and Win32 looking? I'm about to post a patch that fixes macros in the assembler, and along the way adds label arithmetic, which allows t/basic.t to have all tests enabled (and passing). I'd like to have a working macro facility in the assembler for 0.0.2, please. Have a look at my forthcoming message. 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 0.0.2
Simon Cozens: # On Wed, Oct 03, 2001 at 09:39:32AM -0700, Brent Dax wrote: # > Win2K non-Cygwin is looking a little sick to its stomach: # # Dammit. There had to be a show-stopper, didn't there? And of course it had to be Microsoft. :^) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
Re: Parrot 0.0.2
On Wed, 3 Oct 2001, Bryan C. Warnock wrote: > FWIW, Linux/x86 long long/long double/long long has a few glitches. That's a good test platform because sizeof(long double) is 12 there, while sizeof(long long) is 8, but Parrot/Opcode.pm still seems to assume $nvivsize = $PConfig{numvalsize}/$PConfig{intvalsize} is an integer. I put that in, so I know it's wrong :-). Sparc probably won't show the same effect, since sizeof(long double) there is either 8 (Sparc/Linux) or 16 (Sparc/Solaris), so nvivsize is still an integer there. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Parrot 0.0.2
On Wed, Oct 03, 2001 at 09:39:32AM -0700, Brent Dax wrote: > Win2K non-Cygwin is looking a little sick to its stomach: Dammit. There had to be a show-stopper, didn't there? -- The Blit is a nice terminal, but it runs emacs.
RE: Parrot 0.0.2
Simon Cozens: # Any objections to a release today? How's Cygwin and Win32 looking? Win2K non-Cygwin is looking a little sick to its stomach: Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot>pmake test Reading C:/Perl/site/lib/Make.pm Reading C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot\makefile C:\Perl\bin\perl.exe t/harness t/op/basic..ok, 1/5 skipped: label constants unimplemented in assembler t/op/bitwiseok t/op/integerok t/op/number.ok t/op/stacks.NOK 5# Failed test (Parrot/Test.pm at line 74) # got: 'Seem to have negative Nx not ok ' # expected: 'Seem to have negative Nx Seem to have positive Nx after pop ' t/op/stacks.ok 9/9# Looks like you failed 1 tests of 9. t/op/stacks.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 5 Failed 1/9 tests, 88.89% okay (-3 skipped tests: 5 okay, 55.56%) t/op/string.NOK 4# Failed test (Parrot/Test.pm at line 74) # got: 'Error: Control left bounds of byte-code block (now at location 31)! ng ** ' # expected: 'A string of length 21 A string of lengt A string of lengt ** nothing ** ' t/op/string.ok 11/11# Looks like you failed 1 tests of 11. t/op/string.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 4 Failed 1/11 tests, 90.91% okay (-1 skipped test: 9 okay, 81.82%) t/op/time...NOK 2# Failed test (Parrot/Test.pm at line 74) # got: 'failure ' # expected: 'ok, (!= 1970) Grateful Dead not ok, (now>before) timelords need not apply ' # Looks like you failed 1 tests of 2. t/op/time...dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 2 Failed 1/2 tests, 50.00% okay t/op/trans..ok Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/stacks.t1 256 91 11.11% 5 t/op/string.t1 256111 9.09% 4 t/op/time.t 1 256 21 50.00% 2 5 subtests skipped. Failed 3/8 test scripts, 62.50% okay. 3/100 subtests failed, 97.00% okay. --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
Re: Parrot 0.0.2
On Wednesday 03 October 2001 12:14 pm, Andy Dougherty wrote: > On Wed, 3 Oct 2001, Simon Cozens wrote: > > This is looking releasable. > > (If you include my printf (long) casts) I agree. > > Nice work. FWIW, Linux/x86 long long/long double/long long has a few glitches. Whammo 20> test_prog test [12:35] Iterations: 1 Start time: 1002126954 End time: 1002126966 Count: 1 Elapsed time:12 Estimated ops:3 Estimated ops (numerically):-0.00 Elapsed time:12 Elapsed time:-2.00 Ops/sec:-0.02 -- Bryan C. Warnock [EMAIL PROTECTED]
Re: [PATCH] printf bandaids (Was Re: Parrot 0.0.2)
On Wed, Oct 03, 2001 at 12:13:51PM -0400, Andy Dougherty wrote: > All tests successful, 5 subtests skipped. In which case, I'm happy to pretend this is a format string fix. :) (Applied, thanks) > printing out an INTVAL. I see you're already conforming to the New Order. :) > Fortunately, perl5.7.x's Configure already does some of this > for us. Paging Robin Barker, paging Robin Barker. Simon -- $\=" ";@a=qw/hacker, Perl another Just/;sub TIESCALAR{bless[]};tie $a,$a; *STORE=*FETCH=sub{print pop @a};$_++for$a,$a;
Re: Parrot 0.0.2
On Wed, 3 Oct 2001, Simon Cozens wrote: > This is looking releasable. (If you include my printf (long) casts) I agree. Nice work. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
[PATCH] printf bandaids (Was Re: Parrot 0.0.2)
On Wed, 3 Oct 2001, Simon Cozens wrote: > On Wed, Oct 03, 2001 at 11:44:25AM -0400, Andy Dougherty wrote: > > It's not a core platform, but Linux/Sparc (intvalsize=8) is still not > > very happy: > > OK; I'll have to check that out. The Sparc I have here has intvalsize=4 > by default. Perhaps I'm too daring running bleadperl by default :-). Anyway, the following bandaid results in the following happy output: t/op/basic..ok, 1/5 skipped: label constants unimplemented in assembler t/op/bitwiseok t/op/integerok t/op/number.ok t/op/stacks.ok, 3/9 skipped: various reasons t/op/string.ok, 1/10 skipped: TODO: printing empty string reg segfaults t/op/time...ok t/op/trans..ok All tests successful, 5 subtests skipped. Files=8, Tests=99, 160 wallclock secs (149.65 cusr + 9.88 csys = 159.53 CPU) Here's the patch. It's a bandaid (but a pretty good one). What we really need to do is figure out the correct printf format string for printing out an INTVAL. Fortunately, perl5.7.x's Configure already does some of this for us. Not all the casts may be necessary. I used a rather brute force approach :-). diff -r -u parrot/basic_opcodes.ops parrot-andy/basic_opcodes.ops --- parrot/basic_opcodes.opsTue Oct 2 10:01:30 2001 +++ parrot-andy/basic_opcodes.ops Wed Oct 3 11:40:25 2001 @@ -145,12 +145,12 @@ /* PRINT Ix */ AUTO_OP print_i { - printf("%li", INT_REG(P1)); + printf("%li", (long) INT_REG(P1)); } /* PRINT ic */ AUTO_OP print_ic { - printf("%li", P1); + printf("%li", (long) P1); } diff -r -u parrot/interpreter.c parrot-andy/interpreter.c --- parrot/interpreter.cWed Oct 3 10:51:07 2001 +++ parrot-andy/interpreter.c Wed Oct 3 11:36:44 2001 @@ -84,7 +84,7 @@ fprintf(stderr, "; ARGS=("); for(i = 0; i < op_args[*pc]; i++) { if (i) { fprintf(stderr, ", "); } -fprintf(stderr, "%ld", *(pc + i + 1)); +fprintf(stderr, "%ld", (long) *(pc + i + 1)); } fprintf(stderr, ")"); } @@ -147,7 +147,7 @@ pc = core(interpreter); if (pc < code_start || pc >= code_end) { -fprintf(stderr, "Error: Control left bounds of byte-code block (now at location %d)!\n", pc - code_start); +fprintf(stderr, "Error: Control left bounds of byte-code block (now at +location %d)!\n", (int) (pc - code_start)); exit(1); } } diff -r -u parrot/packfile.c parrot-andy/packfile.c --- parrot/packfile.c Tue Oct 2 10:01:30 2001 +++ parrot-andy/packfile.c Wed Oct 3 11:38:05 2001 @@ -1679,7 +1679,7 @@ break; case PFC_INTEGER: -printf("[ 'PFC_INTEGER', %ld ],\n", self->integer); +printf("[ 'PFC_INTEGER', %ld ],\n", (long) self->integer); break; case PFC_NUMBER: @@ -1689,9 +1689,9 @@ case PFC_STRING: printf("[ 'PFC_STRING', {\n"); printf("FLAGS=> 0x%04x,\n", self->string->flags); -printf("ENCODING => %ld,\n", self->string->encoding->which); -printf("TYPE => %ld,\n", self->string->type); -printf("SIZE => %ld,\n", self->string->bufused); +printf("ENCODING => %ld,\n", (long) +self->string->encoding->which); +printf("TYPE => %ld,\n", (long) self->string->type); +printf("SIZE => %ld,\n", (long) self->string->bufused); printf("DATA => '%s'\n", self->string->bufstart); /* TODO: Not a good idea in general */ printf("} ],\n"); break; -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
RE: Parrot 0.0.2
On Wed, 3 Oct 2001, Gibbs Tanton - tgibbs wrote: > >Here is the patch to get make test to work on cygwin. There may be a better >way to do it. It is actually courtesy of someone else, but I'll have to go >look to see who (unless you speak up :) > >It basically takes >test: > ...do tests >and replaces it with >test: dummy > >dummy: > ...do tests Better: test: dummy ...do tests dummy: Regards Mattia
Re: Parrot 0.0.2
On Wed, Oct 03, 2001 at 05:52:19PM +0200, H. Merijn Brand wrote: > HP-UX 11.00 w/ HP ANSI C > -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE >-D_FILE_OFFSET_BITS=64 -I./include Thanks. Also: $ uname -a SunOS neptune 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-5_10 How big would you like integers to be? [long] And your floats? [double] What is your native opcode type? [long] -DUSE_LONG_LONG -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 $ /usr/ccs/bin/make test perl t/harness t/op/basic..ok, 1/5 skipped: label constants unimplemented in assembler t/op/bitwiseok t/op/integerok t/op/number.ok t/op/stacks.ok, 3/9 skipped: various reasons t/op/string.ok, 1/11 skipped: TODO: printing empty string reg segfaults t/op/time...ok t/op/trans..ok All tests successful, 5 subtests skipped. Files=8, Tests=100, 34 wallclock secs (25.38 cusr + 6.98 csys = 32.36 CPU) $ This is looking releasable. -- even though I know what a 'one time pad' is, it still sounds like a feminine hygiene product.
Re: Parrot 0.0.2
On Wed 03 Oct 2001 16:55, Simon Cozens <[EMAIL PROTECTED]> wrote: > Any objections to a release today? How's Cygwin and Win32 looking? HP-UX 11.00 w/ HP ANSI C -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include l1:/pro/3gl/CPAN/parrot 112 > make test perl t/harness t/op/basic..ok, 1/5 skipped: label constants unimplemented in assembler t/op/bitwiseok t/op/integerok t/op/number.ok t/op/stacks.ok, 3/9 skipped: various reasons t/op/string.ok, 1/10 skipped: TODO: printing empty string reg segfaults t/op/time...ok t/op/trans..ok All tests successful, 5 subtests skipped. Files=8, Tests=99, 32 wallclock secs (22.42 cusr + 4.59 csys = 27.01 CPU) l1:/pro/3gl/CPAN/parrot 113 > -- 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: Strings db (comments requested)
Hi Grant, Just as a suggestion, i would use the PO format (already used by other tools than gettext, like KDE) so we get for free all the catalog manager tools (like Kbabel, which is very nice, by the way). And maybe error codes output could be just another target language. So: fprintf(stderr, i18n ("Error #43: Can't stat file\n") ) Prints just "ERR43\n" when language var is set to, say, "CODES". -- Angel Faus Director Técnico vLex.com - [EMAIL PROTECTED]
Re: resend: [PATCH] chopn broken
On Wed, Oct 03, 2001 at 04:54:41PM +0100, Alex Gough wrote: > Chopn is broken for n < 0, here a fix and tests. Thanks, applied. (with a tiny style correction) -- You're never alone with a news spool.
Re: Constant operator overloading
At 11:02 AM 10/3/2001 -0400, Bryan C. Warnock wrote: >On Wednesday 03 October 2001 10:57 am, Dan Sugalski wrote: > > Having said that, if you're looking to add optimizations into the > > assembler, you're probably OK, but I'm not sure it's worth the effort at > > the moment. > >Investigating what effect a non-duplicated, non-overridable set of opcodes >(namely, the base set of I*, N*, and S* calls) inlined would have on >performance. Ah. Yeah, those will all be non-overridable. The opcodes that do the same thing with PMCs will also be non-overridable, but since they work through the vtables associated with the constants the behaviour can be changed by messing with those if need be. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
resend: [PATCH] chopn broken
Chopn is broken for n < 0, here a fix and tests. Alex Gough -- To have the reputation of possessing the most perfect social tact, talk to every woman as if you loved her, and to every man as if he bored you. ## Index: string.c === RCS file: /home/perlcvs/parrot/string.c,v retrieving revision 1.10 diff -u -r1.10 string.c --- string.c2001/10/02 14:01:30 1.10 +++ string.c2001/10/02 14:14:48 @@ -143,6 +143,7 @@ if (n > s->strlen) { n = s->strlen; } +if (n < 0) n = 0; return (ENC_VTABLE(s)->chopn)(s, n); } Index: t/op/string.t === RCS file: /home/perlcvs/parrot/t/op/string.t,v retrieving revision 1.5 diff -u -r1.5 string.t --- t/op/string.t 2001/09/25 09:12:57 1.5 +++ t/op/string.t 2001/10/02 14:14:49 @@ -1,6 +1,6 @@ #! perl -w -use Parrot::Test tests => 10; +use Parrot::Test tests => 11; output_is( <<'CODE', <
Re: Parrot 0.0.2
On Wed, Oct 03, 2001 at 11:44:25AM -0400, Andy Dougherty wrote: > It's not a core platform, but Linux/Sparc (intvalsize=8) is still not > very happy: OK; I'll have to check that out. The Sparc I have here has intvalsize=4 by default. -- "Contrariwise," continued Tweedledee, "if it was so, it might be, and if it were so, it would be; but as it isn't, it ain't. That's logic!" -- Lewis Carroll, "Through the Looking Glass"
Re: Parrot 0.0.2
On Wednesday 03 October 2001 11:44 am, Andy Dougherty wrote: > Finally, trying a 32-bit opcode_t and a 64-bit INTVAL, I get Mixed sizes are completely hosed. But we need to decide how they should behave before we start randomly applying bandaids. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Parrot 0.0.2
On Wed, 3 Oct 2001, Simon Cozens wrote: > On Wed, Oct 03, 2001 at 03:55:55PM +0100, Simon Cozens wrote: > > Any objections to a release today? How's Cygwin and Win32 looking? > > FWIW, I've just successfully built Parrot on Linux x86, Linux Sparc, > Linux IA64, Tru64, Linux Alpha, FreeBSD Alpha, and FreeBSD x86. > I'm happy. It's not a core platform, but Linux/Sparc (intvalsize=8) is still not very happy: Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/basic.t 2 512 52 40.00% 2 4 t/op/bitwise.t4 1024 44 100.00% 1-4 t/op/integer.t 11 281626 11 42.31% 1-7 21-24 t/op/number.t 1 256251 4.00% 24 t/op/stacks.t 1 256 91 11.11% 1 t/op/string.t 1 256101 10.00% 2 5 subtests skipped. Failed 6/8 test scripts, 25.00% okay. 20/99 subtests failed, 79.80% okay. make: *** [test] Error 29 I also get the same results on a similarly-configured Solaris 8/Sparc system (Solaris SunPro CC). Finally, trying a 32-bit opcode_t and a 64-bit INTVAL, I get Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/basic.t 3 768 53 60.00% 2-4 t/op/bitwise.t4 1024 44 100.00% 1-4 t/op/integer.t 26 665626 26 100.00% 1-26 t/op/number.t25 640025 25 100.00% 1-25 t/op/stacks.t 6 1536 96 66.67% 1 3 5 7-9 t/op/string.t 9 2304109 90.00% 1-9 t/op/time.t 2 512 22 100.00% 1-2 t/op/trans.t 18 460818 18 100.00% 1-18 5 subtests skipped. Failed 8/8 test scripts, 0.00% okay. 93/99 subtests failed, 6.06% okay. The failures are very basic. Here's the output from t/op/basic.t: 1..5 ok 1 - noop, end not ok 2 - print 1 # Failed test (Parrot/Test.pm at line 74) # got: '' # expected: '1' not ok 3 - print string # Failed test (Parrot/Test.pm at line 74) # got: 'PackFile_unpack: Illegal constant table segment size 0 (must be multiple of 92)! Warning: Bytecode does not include opcode table fingerprint! Error: Control left bounds of byte-code block (now at location 0)! ' # expected: 'Parrot flies' not ok 4 - branch_ic # Failed test (Parrot/Test.pm at line 74) # got: '' # expected: '42' ok 5 # skip label constants unimplemented in assembler # Looks like you failed 3 tests of 5. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Okay, hardware gurus....
On Wednesday 03 October 2001 10:56 am, Michael Maraist wrote: > > > x = z->opcode_funcs; > > > > > > while (pc >= code_start && pc < code_end && *pc) { > > > do { > > > y = x[*w]; \ > > >w = (y)(w,z); \ > > > } while (0); > > > } > > > > > > slow it down by 6%? > > > > Perhaps x is no long considered a register. Are you compiling with -O2? > > compile to source (-S on gcc) and loop for that inner loop. See what is > > physically different. (I'm away from my test-environment at the moment) > > Oh, better yet, given all the cache-work I've done in the past two days, > it's entirely possible that a cache line is violated due to the new > assembly ordering. You'd have to check the assembly source to know. > > One check you can perform is to put a temporary variable w/in the loop and > assign it to the outer variable. This avoids the indirection but keeps > the cache / register set populated. > > If you did you -O2 it shouldn't matter though, because the code would be > reordered either way. Leaving the initial (outer) assignment of opcode_funcs to temp (x), the only differences in the assembly between the two are the three less operations within the inner loop that handle the original (inner) assignment. Your other suggestions were tried and had no discernable effect. I'll try it on a Sparc under Forte, and see what it does. (But I'm willing for now to just accept it and chalk it up as a lesson learned. Test everything.) -- Bryan C. Warnock [EMAIL PROTECTED]
RE: Parrot 0.0.2
Here is the patch to get make test to work on cygwin. There may be a better way to do it. It is actually courtesy of someone else, but I'll have to go look to see who (unless you speak up :) It basically takes test: ...do tests and replaces it with test: dummy dummy: ...do tests so that cygwin really thinks there is something to do. -Original Message- From: Gibbs Tanton - tgibbs To: 'Simon Cozens '; '[EMAIL PROTECTED] ' Sent: 10/3/2001 10:12 AM Subject: RE: Parrot 0.0.2 Cygwin is fine. Although I still have to change the makefile to get make test to work right. -Original Message- From: Simon Cozens To: [EMAIL PROTECTED] Sent: 10/3/2001 9:55 AM Subject: Parrot 0.0.2 Any objections to a release today? How's Cygwin and Win32 looking? -- > I'm a person, not a piece of property. Happily, I'm both! - Lionel and Stephen Harris. patch.dat
RE: Strings db (comments requested)
Here's the situation (as I understand it): Parrot needs to stop emitting strings exclusively in English. Parrot needs a standard file format for a string replacement db. Parrot should only put strings to stderr (except when told to). Parrot should be able to emit "error IDs" instead of strings. Parrot presently has about 200 strings that are targets. Here's what I propose: A standard library that allows loading of a strings db at run-time based upon a defined order of variable testing. This might mean that the library would getenv a variable, then check for a command-line option, then check for the default Parrot value. A string database that has number/value pairs, where the number corresponds to the error number defined by Parrot, and the value is the string to emit for that number. A configure directive that tells the library to emit only error numbers only (no strings). This would then allow any language built on top of Parrot to intercept these codes for it's own purpose without having to parse a string. A tool for managing the strings db. This would need to include adherence to some sort of yet-undefined standard of assigning error codes. Perhaps using SOAP? a socket connection to CPAN? Any ideas are welcome. Bibliography: http://dev.perl.org/rfc/85.pod - RFC 85 http://dev.perl.org/rfc/296.pod - RFC 296 http://dev.perl.org/rfc/313.pod - RFC 313 Please comment. Grant M. [EMAIL PROTECTED]
RE: Parrot 0.0.2
> Any objections to a release today? How's Cygwin and Win32 looking? Just built on Cygwin on Win2k: (make test still doesn't work) $ perl t/harness t/op/basic..ok, 1/5 skipped: label constants unimplemented in assembler t/op/bitwiseok t/op/integerok t/op/number.ok t/op/stacks.ok, 3/9 skipped: various reasons t/op/string.ok, 1/10 skipped: TODO: printing empty string reg segfaults t/op/time...ok t/op/trans..ok All tests successful, 5 subtests skipped. Files=8, Tests=99, 44 wallclock secs (29.05 cusr + 19.57 csys = 48.62 CPU) Grant M. [EMAIL PROTECTED]
Re: Parrot 0.0.2
On Wed, Oct 03, 2001 at 03:55:55PM +0100, Simon Cozens wrote: > Any objections to a release today? How's Cygwin and Win32 looking? FWIW, I've just successfully built Parrot on Linux x86, Linux Sparc, Linux IA64, Tru64, Linux Alpha, FreeBSD Alpha, and FreeBSD x86. I'm happy. -- The PROPER way to handle HTML postings is to cancel the article, then hire a hitman to kill the poster, his wife and kids, and fuck his dog and smash his computer into little bits. Anything more is just extremism. - Paul Tomblin, in the monastery.
RE: Parrot 0.0.2
Cygwin is fine. Although I still have to change the makefile to get make test to work right. -Original Message- From: Simon Cozens To: [EMAIL PROTECTED] Sent: 10/3/2001 9:55 AM Subject: Parrot 0.0.2 Any objections to a release today? How's Cygwin and Win32 looking? -- > I'm a person, not a piece of property. Happily, I'm both! - Lionel and Stephen Harris.
Re: Constant operator overloading
On Wednesday 03 October 2001 10:57 am, Dan Sugalski wrote: > Having said that, if you're looking to add optimizations into the > assembler, you're probably OK, but I'm not sure it's worth the effort at > the moment. Investigating what effect a non-duplicated, non-overridable set of opcodes (namely, the base set of I*, N*, and S* calls) inlined would have on performance. (By non-duplicated, meaning that, say, opcodes 0-256, for instance, are non-overridable, and the opcode numbers 0-256 are also unusable by extensions.) -- Bryan C. Warnock [EMAIL PROTECTED]
Parrot 0.0.2
Any objections to a release today? How's Cygwin and Win32 looking? -- > I'm a person, not a piece of property. Happily, I'm both! - Lionel and Stephen Harris.
Re: Okay, hardware gurus....
At 10:56 AM 10/3/2001 -0400, Michael Maraist wrote: >If you did you -O2 it shouldn't matter though, because the code would be >reordered either way. Counting on gcc, or any compiler, to reorder in ways you expect is always a dicey thing. :) Just because things get reordered doesn't mean they get reordered *right*... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Constant operator overloading
At 10:51 AM 10/3/2001 -0400, Bryan C. Warnock wrote: >Is there anything that might alter an operation involving only constants >and/or the constant registers at a time other than compile time (ie, when >the opcode is generated.)? For integer, string, and float constants (i.e. I, N, and S regs) no. For PMC constants, yes. It's possible that someone might change the behaviour of the String class, or the Integer class. (Yanking Ruby into the mix here) Whether constant folding can be done is an issue for the compiler and optimizer, though. Once things get to the interpreter they're pretty much fixed. Having said that, if you're looking to add optimizations into the assembler, you're probably OK, but I'm not sure it's worth the effort at the moment. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Okay, hardware gurus....
> > Linux/Athlon/gcc. > > > > Why does changing this: (DO_OP loop partially inlined) > > > > while (pc >= code_start && pc < code_end && *pc) { > > do { > > x = z->opcode_funcs; \ > > y = x[*w]; \ > >w = (y)(w,z); \ > > } while (0); > > } > > > > to > > > > x = z->opcode_funcs; > > > > while (pc >= code_start && pc < code_end && *pc) { > > do { > > y = x[*w]; \ > >w = (y)(w,z); \ > > } while (0); > > } > > > > slow it down by 6%? > > Perhaps x is no long considered a register. Are you compiling with -O2? > compile to source (-S on gcc) and loop for that inner loop. See what is > physically different. (I'm away from my test-environment at the moment) > Oh, better yet, given all the cache-work I've done in the past two days, it's entirely possible that a cache line is violated due to the new assembly ordering. You'd have to check the assembly source to know. One check you can perform is to put a temporary variable w/in the loop and assign it to the outer variable. This avoids the indirection but keeps the cache / register set populated. If you did you -O2 it shouldn't matter though, because the code would be reordered either way. -Michael
Re: Okay, hardware gurus....
> Linux/Athlon/gcc. > > Why does changing this: (DO_OP loop partially inlined) > > while (pc >= code_start && pc < code_end && *pc) { > do { > x = z->opcode_funcs; \ > y = x[*w]; \ >w = (y)(w,z); \ > } while (0); > } > > to > > x = z->opcode_funcs; > > while (pc >= code_start && pc < code_end && *pc) { > do { > y = x[*w]; \ >w = (y)(w,z); \ > } while (0); > } > > slow it down by 6%? Perhaps x is no long considered a register. Are you compiling with -O2? compile to source (-S on gcc) and loop for that inner loop. See what is physically different. (I'm away from my test-environment at the moment) -Michael
Constant operator overloading
Is there anything that might alter an operation involving only constants and/or the constant registers at a time other than compile time (ie, when the opcode is generated.)? -- Bryan C. Warnock [EMAIL PROTECTED]
RE: [PATCH] opcode_t *
Thanks! Applied. -Original Message- From: Bryan C. Warnock To: [EMAIL PROTECTED] Sent: 10/3/2001 9:22 AM Subject: [PATCH] opcode_t * Missed one of these. Index: interpreter.c === RCS file: /home/perlcvs/parrot/interpreter.c,v retrieving revision 1.21 diff -u -r1.21 interpreter.c --- interpreter.c 2001/10/02 14:01:30 1.21 +++ interpreter.c 2001/10/03 14:21:52 @@ -136,7 +136,7 @@ opcode_t * code_start; INTVAL code_size; opcode_t * code_end; -INTVAL * pc; +opcode_t * pc; check_fingerprint(interpreter); -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Okay, hardware gurus....
On Wednesday 03 October 2001 10:43 am, Simon Cozens wrote: > On Wed, Oct 03, 2001 at 10:45:08AM -0400, Bryan C. Warnock wrote: > > while (pc >= code_start && pc < code_end && *pc) { > > do { > > x = z->opcode_funcs; \ > > y = x[*w]; \ > >w = (y)(w,z); \ > > } while (0); > > } > > > > to > > > > x = z->opcode_funcs; > > The optimizer should hoist the code out of the loop anyway. What does > the assembly code say? If it does, it's a problem, because the opcode_func function table may change during opcode processing. But I didn't think about looking at the assembly. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Okay, hardware gurus....
On Wed, Oct 03, 2001 at 10:45:08AM -0400, Bryan C. Warnock wrote: > while (pc >= code_start && pc < code_end && *pc) { > do { > x = z->opcode_funcs; \ > y = x[*w]; \ >w = (y)(w,z); \ > } while (0); > } > > to > > x = z->opcode_funcs; The optimizer should hoist the code out of the loop anyway. What does the assembly code say? -- So now I don't trust my backups, which is a lot like not trusting my girlfriend -- sooner or later either they'll win back my trust or I'll have to trade them in on a new model.- D J Trindle, in the monastery
Okay, hardware gurus....
Linux/Athlon/gcc. Why does changing this: (DO_OP loop partially inlined) while (pc >= code_start && pc < code_end && *pc) { do { x = z->opcode_funcs; \ y = x[*w]; \ w = (y)(w,z); \ } while (0); } to x = z->opcode_funcs; while (pc >= code_start && pc < code_end && *pc) { do { y = x[*w]; \ w = (y)(w,z); \ } while (0); } slow it down by 6%? -- Bryan C. Warnock [EMAIL PROTECTED]
[PATCH] opcode_t *
Missed one of these. Index: interpreter.c === RCS file: /home/perlcvs/parrot/interpreter.c,v retrieving revision 1.21 diff -u -r1.21 interpreter.c --- interpreter.c 2001/10/02 14:01:30 1.21 +++ interpreter.c 2001/10/03 14:21:52 @@ -136,7 +136,7 @@ opcode_t * code_start; INTVAL code_size; opcode_t * code_end; -INTVAL * pc; +opcode_t * pc; check_fingerprint(interpreter); -- Bryan C. Warnock [EMAIL PROTECTED]
Re: [PATCH] Updated DO_OP patch
Simon -- > What's an IV? That was a slip of the keyboard. The C-based disassembler is (as is now obvious) not ready for prime time. I've moved it to its own sandbox (since it doesn't have anything to do with the doop patch anyway). Here's an updated 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 \_/ ? doop.patch ? t/inc.pasm ? t/jumpoob.pasm ? t/jumpsub.pasm ? t/substr.pasm ? t/jump2.pasm ? t/jump3.pasm ? t/jump4.pasm ? t/runoob.pasm Index: .cvsignore === RCS file: /home/perlcvs/parrot/.cvsignore,v retrieving revision 1.4 diff -a -u -r1.4 .cvsignore --- .cvsignore 2001/09/19 16:48:28 1.4 +++ .cvsignore 2001/10/03 14:14:35 @@ -1,5 +1,8 @@ basic_opcodes.c -test_prog -pdump +interp_guts.c Makefile +op_info.c Parrot/ +pdisasm +pdump +test_prog Index: Makefile.in === RCS file: /home/perlcvs/parrot/Makefile.in,v retrieving revision 1.15 diff -a -u -r1.15 Makefile.in --- Makefile.in 2001/10/01 22:00:23 1.15 +++ Makefile.in 2001/10/03 14:14:36 @@ -29,21 +29,21 @@ libparrot.so: $(O_FILES) $(CC) -shared $(C_LIBS) -o $@ $(O_FILES) -$(TEST_PROG): test_main$(O) $(O_FILES) - $(CC) $(CFLAGS) -o $(TEST_PROG) $(O_FILES) test_main$(O) $(C_LIBS) +$(TEST_PROG): test_main$(O) $(O_FILES) interp_guts$(O) op_info$(O) + $(CC) $(CFLAGS) -o $(TEST_PROG) $(O_FILES) interp_guts$(O) op_info$(O) +test_main$(O) $(C_LIBS) + +$(PDUMP): pdump$(O) packfile$(O) memory$(O) global_setup$(O) string$(O) strnative$(O) + $(CC) $(CFLAGS) -o $(PDUMP) pdump$(O) packfile$(O) memory$(O) global_setup$(O) +string$(O) strnative$(O) $(C_LIBS) -$(PDUMP): pdump$(O) $(O_FILES) - $(CC) $(CFLAGS) -o $(PDUMP) $(O_FILES) pdump$(O) $(C_LIBS) +test_main$(O): $(H_FILES) $(INC)/interp_guts.h -test_main$(O): $(H_FILES) - global_setup$(O): $(H_FILES) string$(O): $(H_FILES) strnative$(O): $(H_FILES) -$(INC)/interp_guts.h: opcode_table build_interp_starter.pl +$(INC)/interp_guts.h interp_guts.c $(INC)/op_info.h op_info.c: opcode_table +build_interp_starter.pl $(PERL) build_interp_starter.pl interpreter$(O): interpreter.c $(H_FILES) $(INC)/interp_guts.h @@ -68,7 +68,7 @@ $(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 interp_guts.c $(INC)/interp_guts.h +$(INC)/op.h op_info.c $(INC)op_info.h $(TEST_PROG) $(PDISASM) $(PDUMP) test: $(PERL) t/harness Index: build_interp_starter.pl === RCS file: /home/perlcvs/parrot/build_interp_starter.pl,v retrieving revision 1.12 diff -a -u -r1.12 build_interp_starter.pl --- build_interp_starter.pl 2001/09/24 17:19:47 1.12 +++ build_interp_starter.pl 2001/10/03 14:14:36 @@ -1,10 +1,23 @@ # !/usr/bin/perl -w +# +# build_interp_starter.pl +# +# $Id: $ +# + use strict; use Parrot::Opcode; + +my %opcodes= Parrot::Opcode::read_ops(); +my $opcode_fingerprint = Parrot::Opcode::fingerprint(); + +open INTERP_GUTS_H, "> include/parrot/interp_guts.h" or die "Can't open +include/parrot/interp_guts.h, $!/$^E"; +open INTERP_GUTS_C, "> interp_guts.c" or die "Can't open interp_guts.c, $!/$^E"; -open INTERP, "> include/parrot/interp_guts.h" or die "Can't open include/parrot/interp_guts.h, $!/$^E"; +open OP_INFO_H, "> include/parrot/op_info.h" or die "Can't open +include/parrot/op_info.h, $!/$^E"; +open OP_INFO_C, "> op_info.c" or die "Can't open op_info.c, $!/$^E"; -print INTERP$opcodes{$b}{CODE}} keys %opcodes) { -print INTERP "\tx[$opcodes{$name}{CODE}] = $name; \\\n"; -} -print INTERP "} while (0);\n"; +### +print OP_INFO_H < $opcodes{$b}{CODE}} keys %opcodes) { -print INTERP "\tx[$opcodes{$name}{CODE}] = \"$name\"; \\\n"; -} -print INTERP "} while (0);\n"; +### +print INTERP_GUTS_C < $opcodes{$b}{CODE}} keys %opcodes) { -print INTERP "\tx[$opcodes{$name}{CODE}] = $opcodes{$name}{ARGS}; \
Re: Speed trials!
Holding steady since last report. -- Bryan C. Warnock [EMAIL PROTECTED]
[PATCH] Updated 'mod' patch
All -- I've updated my mod patch to work with the latest CVS... Regards, -- _ / 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 \_/ ? tryme ? mod.c ? mod.patch Index: basic_opcodes.ops === RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v retrieving revision 1.29 diff -a -u -r1.29 basic_opcodes.ops --- basic_opcodes.ops 2001/10/02 14:01:30 1.29 +++ basic_opcodes.ops 2001/10/03 12:30:16 @@ -7,6 +7,13 @@ #include "parrot/parrot.h" #include +/* DEFINES to make true mod work right */ + +#define OPP_SIGNS(x,y) x)<0)&&((y)>0))||(((x)>0)&&((y)<0))) +#define REM_INC(x,y) (((x)%(y))?1:0) +#define INT_FLOOR_DIV(x,y) (OPP_SIGNS(x,y)?(-((-x)/(y)+REM_INC((-x),(y:((x)/(y))) +#define INT_MOD(x,y) (((y)==0)?(x):((x)-(y)*INT_FLOOR_DIV((x),(y + /* SET Ix, CONSTANT */ AUTO_OP set_i_ic { INT_REG(P1) = P2; @@ -43,8 +50,12 @@ /* MOD Ix, Iy, Iz */ AUTO_OP mod_i { - INT_REG(P1) = INT_REG(P2) % - INT_REG(P3); + INT_REG(P1) = INT_MOD(INT_REG(P2), INT_REG(P3)); +} + +/* CMOD Ix, Iy, Iz */ +AUTO_OP cmod_i { + INT_REG(P1) = INT_REG(P2) % INT_REG(P3); } /* EQ Ix, Iy, EQ_BRANCH */ @@ -221,6 +232,18 @@ AUTO_OP div_n { NUM_REG(P1) = NUM_REG(P2) / NUM_REG(P3); +} + +/* MOD Nx, Ny, Nz */ +AUTO_OP mod_n { + NUM_REG(P1) = NUM_REG(P3) +? (NUM_REG(P2) - NUM_REG(P3) * floor(NUM_REG(P2) / NUM_REG(P3))) +: NUM_REG(P2); +} + +/* CMOD Nx, Ny, Nz */ +AUTO_OP cmod_n { + NUM_REG(P1) = fmod(NUM_REG(P2), NUM_REG(P3)); } /* EQ Nx, Ny, EQ_BRANCH */ Index: opcode_table === RCS file: /home/perlcvs/parrot/opcode_table,v retrieving revision 1.22 diff -a -u -r1.22 opcode_table --- opcode_table2001/09/24 16:27:48 1.22 +++ opcode_table2001/10/03 12:30:16 @@ -36,6 +36,7 @@ mul_i 3 I I I div_i 3 I I I mod_i 3 I I I +cmod_i 3 I I I inc_i 1 I inc_i_ic 2 I i dec_i 1 I @@ -49,6 +50,8 @@ sub_n 3 N N N mul_n 3 N N N div_n 3 N N N +mod_n 3 N N N +cmod_n 3 N N N inc_n 1 N inc_n_nc 2 N n dec_n 1 N Index: t/op/integer.t === RCS file: /home/perlcvs/parrot/t/op/integer.t,v retrieving revision 1.7 diff -a -u -r1.7 integer.t --- t/op/integer.t 2001/09/26 18:13:50 1.7 +++ t/op/integer.t 2001/10/03 12:30:17 @@ -1,6 +1,6 @@ #! perl -w -use Parrot::Test tests => 26; +use Parrot::Test tests => 27; output_is(< 25; +use Parrot::Test tests => 27; output_is(<
Re: [PATCH] Updated DO_OP patch
On Wed, Oct 03, 2001 at 08:26:07AM -0400, Gregor N. Purdy wrote: > +IV byte_code_size; > +char * byte_code; > +char * byte_code_end; > +char * cursor; > +IV * iv_ptr; > +NV * nv_ptr; What's an IV? -- "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." -- Howard Aiken
Re: [PATCH] Updated bytecode --> C compiler
All -- Here's the actual patch... > I've updated the patch for the bytecode --> C compiler to work with > the latest code out of CVS. I've modified Makefile so that when you > build, it automatically assembles t/test1.pasm to t/test1.pbc, and > automatically runs the bytecode compiler "pbcc" to produce t/test1.c, > compiles and links the C file so that you can run t/test1. I get a > HUGE speedup (as would be expected) on my machine. > > BTW, I renamed t/test.pasm to t/test1.pasm because I wanted to name > the final output program the same as the base name of the source file, > and naming a program 'test' is a no-no. 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 \_/ ? pbcc.patch Index: MANIFEST === RCS file: /home/perlcvs/parrot/MANIFEST,v retrieving revision 1.23 diff -a -u -r1.23 MANIFEST --- MANIFEST2001/09/30 20:25:22 1.23 +++ MANIFEST2001/10/03 12:17:19 @@ -4,6 +4,7 @@ Makefile.in Parrot/Assembler.pm Parrot/Opcode.pm +Parrot/OpFunc.pm Parrot/PackFile.pm Parrot/PackFile/ConstTable.pm Parrot/PackFile/Constant.pm @@ -53,6 +54,7 @@ opcode_table packfile.c parrot.c +pbcc pdump.c process_opfunc.pl register.c @@ -71,7 +73,7 @@ t/op/string.t t/op/time.t t/op/trans.t -t/test.pasm +t/test1.pasm t/test2.pasm t/test3.pasm test_c.in Index: Makefile.in === RCS file: /home/perlcvs/parrot/Makefile.in,v retrieving revision 1.15 diff -a -u -r1.15 Makefile.in --- Makefile.in 2001/10/01 22:00:23 1.15 +++ Makefile.in 2001/10/03 12:17:19 @@ -22,7 +22,7 @@ .c$(O): $(CC) $(CFLAGS) -o $@ -c $< -all : $(TEST_PROG) $(PDUMP) +all : $(TEST_PROG) $(PDUMP) t/test1${exe} #XXX This target is not portable to Win32 shared: libparrot.so @@ -35,6 +35,18 @@ $(PDUMP): pdump$(O) $(O_FILES) $(CC) $(CFLAGS) -o $(PDUMP) $(O_FILES) pdump$(O) $(C_LIBS) +t/test1.pbc: t/test1.pasm + cd t; make test1.pbc + +t/test1.c: t/test1.pbc + pbcc t/test1.pbc > t/test1.c + +t/test1$(O): t/test1.c + $(CC) -o t/test1$(O) -c -I ./include t/test1.c + +t/test1${exe}: t/test1$(O) $(O_FILES) + $(CC) $(CFLAGS) -o t/test1${exe} $(O_FILES) t/test1$(O) $(C_LIBS) + test_main$(O): $(H_FILES) global_setup$(O): $(H_FILES) @@ -75,3 +87,4 @@ update: cvs -q update -dP + Index: pbcc === RCS file: pbcc diff -N pbcc --- /dev/null Wed Oct 3 03:04:34 2001 +++ pbccWed Oct 3 05:17:19 2001 @@ -0,0 +1,327 @@ +#! /usr/bin/perl -w +# +# compile.pl +# +# Turn a parrot bytecode file into text. +# +# Copyright (C) 2001 The Parrot Team. All rights reserved. +# This program is free software. It is subject to the same license +# as the Parrot interpreter. +# +# $Id: $ +# + +use strict; + +use Parrot::Opcode; +use Parrot::PackFile; +use Parrot::PackFile::ConstTable; +use Parrot::OpFunc; + +use Data::Dumper; +$Data::Dumper::Useqq = 1; +$Data::Dumper::Terse = 1; +$Data::Dumper::Indent = 0; + +Parrot::OpFunc->init('basic_opcodes.ops'); + +# +# GLOBAL VARIABLES: +# + +my %unpack_type = (i => 'l', + I => 'l', + n => 'd', + N => 'l', + D => 'l', + S => 'l', + s => 'l', + ); +my %unpack_size = (i => 4, + n => 8, + I => 4, + N => 4, + D => 4, + S => 4, + s => 4, + ); + +my %opcodes= Parrot::Opcode::read_ops(); +my $opcode_fingerprint = Parrot::Opcode::fingerprint(); +my @opcodes; +for my $name (keys %opcodes) { +$opcodes[$opcodes{$name}{CODE}] = { NAME => $name, + %{$opcodes{$name}} }; +} + + +# +# dump_const_table() +# + +sub dump_const_table { +my ($pf) = @_; + +my $count = $pf->const_table->const_count; + +if ($count < 1) { + warn "Disassembling without opcode table fingerprint!"; + return; +} + +die "Cannot compile (differing opcode table)!" +if $pf->const_table->constant(0)->data ne $opcode_fingerprint; + +print "# Constants: $count entries\n"; +print "# ID FlagsEncoding Type Size Data\n"; + +my $constant_num = 0; + +foreach ($pf->const_table->constants) { +printf("%04x: %08x %08x %08x %08x %s\n", + $constant_num, $_->flags, $_->encoding, $_->type, +$_->size,
[PATCH] Updated DO_OP patch
All -- I've updated the simplified DO_OP patch to work with the latest out of CVS. 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 \_/ ? doop.patch ? t/inc.pasm ? t/jumpoob.pasm ? t/jumpsub.pasm ? t/substr.pasm ? t/jump2.pasm ? t/jump3.pasm ? t/jump4.pasm ? t/runoob.pasm Index: .cvsignore === RCS file: /home/perlcvs/parrot/.cvsignore,v retrieving revision 1.4 diff -a -u -r1.4 .cvsignore --- .cvsignore 2001/09/19 16:48:28 1.4 +++ .cvsignore 2001/10/03 12:24:52 @@ -1,5 +1,8 @@ basic_opcodes.c -test_prog -pdump +interp_guts.c Makefile +op_info.c Parrot/ +pdisasm +pdump +test_prog Index: MANIFEST === RCS file: /home/perlcvs/parrot/MANIFEST,v retrieving revision 1.23 diff -a -u -r1.23 MANIFEST --- MANIFEST2001/09/30 20:25:22 1.23 +++ MANIFEST2001/10/03 12:24:52 @@ -53,6 +53,7 @@ opcode_table packfile.c parrot.c +pdisasm.c pdump.c process_opfunc.pl register.c Index: Makefile.in === RCS file: /home/perlcvs/parrot/Makefile.in,v retrieving revision 1.15 diff -a -u -r1.15 Makefile.in --- Makefile.in 2001/10/01 22:00:23 1.15 +++ Makefile.in 2001/10/03 12:24:52 @@ -18,24 +18,28 @@ PERL = ${perl} TEST_PROG = test_prog${exe} PDUMP = pdump${exe} +PDISASM = pdisasm${exe} .c$(O): $(CC) $(CFLAGS) -o $@ -c $< -all : $(TEST_PROG) $(PDUMP) +all : $(TEST_PROG) $(PDUMP) $(PDISASM) #XXX This target is not portable to Win32 shared: libparrot.so libparrot.so: $(O_FILES) $(CC) -shared $(C_LIBS) -o $@ $(O_FILES) -$(TEST_PROG): test_main$(O) $(O_FILES) - $(CC) $(CFLAGS) -o $(TEST_PROG) $(O_FILES) test_main$(O) $(C_LIBS) +$(TEST_PROG): test_main$(O) $(O_FILES) interp_guts$(O) op_info$(O) + $(CC) $(CFLAGS) -o $(TEST_PROG) $(O_FILES) interp_guts$(O) op_info$(O) +test_main$(O) $(C_LIBS) -$(PDUMP): pdump$(O) $(O_FILES) - $(CC) $(CFLAGS) -o $(PDUMP) $(O_FILES) pdump$(O) $(C_LIBS) +$(PDISASM): pdisasm$(O) op_info$(O) packfile$(O) memory$(O) global_setup$(O) +string$(O) strnative$(O) + $(CC) $(CFLAGS) -o $(PDISASM) pdisasm$(O) op_info$(O) packfile$(O) memory$(O) +global_setup$(O) string$(O) strnative$(O) $(C_LIBS) + +$(PDUMP): pdump$(O) packfile$(O) memory$(O) global_setup$(O) string$(O) strnative$(O) + $(CC) $(CFLAGS) -o $(PDUMP) pdump$(O) packfile$(O) memory$(O) global_setup$(O) +string$(O) strnative$(O) $(C_LIBS) -test_main$(O): $(H_FILES) +test_main$(O): $(H_FILES) $(INC)/interp_guts.h global_setup$(O): $(H_FILES) @@ -43,7 +47,7 @@ strnative$(O): $(H_FILES) -$(INC)/interp_guts.h: opcode_table build_interp_starter.pl +$(INC)/interp_guts.h interp_guts.c $(INC)/op_info.h op_info.c: opcode_table +build_interp_starter.pl $(PERL) build_interp_starter.pl interpreter$(O): interpreter.c $(H_FILES) $(INC)/interp_guts.h @@ -68,7 +72,7 @@ $(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 interp_guts.c $(INC)/interp_guts.h +$(INC)/op.h op_info.c $(INC)op_info.h $(TEST_PROG) $(PDISASM) $(PDUMP) test: $(PERL) t/harness Index: build_interp_starter.pl === RCS file: /home/perlcvs/parrot/build_interp_starter.pl,v retrieving revision 1.12 diff -a -u -r1.12 build_interp_starter.pl --- build_interp_starter.pl 2001/09/24 17:19:47 1.12 +++ build_interp_starter.pl 2001/10/03 12:24:52 @@ -1,10 +1,23 @@ # !/usr/bin/perl -w +# +# build_interp_starter.pl +# +# $Id: $ +# + use strict; use Parrot::Opcode; + +my %opcodes= Parrot::Opcode::read_ops(); +my $opcode_fingerprint = Parrot::Opcode::fingerprint(); + +open INTERP_GUTS_H, "> include/parrot/interp_guts.h" or die "Can't open +include/parrot/interp_guts.h, $!/$^E"; +open INTERP_GUTS_C, "> interp_guts.c" or die "Can't open interp_guts.c, $!/$^E"; -open INTERP, "> include/parrot/interp_guts.h" or die "Can't open include/parrot/interp_guts.h, $!/$^E"; +open OP_INFO_H, "> include/parrot/op_info.h" or die "Can't open +include/parrot/op_info.h, $!/$^E"; +open OP_INFO_C, "> op_info.c" or die "Can't open op_info.c, $!/$^E"; -print INTERP
[PATCH] Updated bytecode --> C compiler
All -- I've updated the patch for the bytecode --> C compiler to work with the latest code out of CVS. I've modified Makefile so that when you build, it automatically assembles t/test1.pasm to t/test1.pbc, and automatically runs the bytecode compiler "pbcc" to produce t/test1.c, compiles and links the C file so that you can run t/test1. I get a HUGE speedup (as would be expected) on my machine. BTW, I renamed t/test.pasm to t/test1.pasm because I wanted to name the final output program the same as the base name of the source file, and naming a program 'test' is a no-no. 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: memory allocation paper (Courtesy of Alan)
Uri Guttman wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > > > DS> Ask has found us a spot for the paper Alan was speaking of. > > DS> http://dev.perl.org/perl6/talks/ > > very impressive paper. my recent proposal for a multi-queue malloc > system has some of the ideas of this but nowhere nearly as fully > developed. if we can drop in the libumem implementation directly, i > think it will be a major win. it doesn't look too difficult for us to > write our own version (with some parrot centric features maybe). the > thread (vs. cpu) support looks very good too. i like how they get > constant or linear time results. > > uri I was facinated by the concepts and implications so I wrote several test utilities based on a 466MHZ dual processor celeron running Linux RedHat 7.1. The paper shows a benchmark based on a 10cpu Solaris Machine that is a large loop of allocs and frees (of an unspecified size, assumed to be 4bytes). The paper shows single threaded throughput of .5Mega cycles / second growing to an upper bound of 3 Mc / second. I ran several combinations of a simple loop of: thr_main: for i .. size: ptr = alloc(4); *ptr = 1; free(ptr); main: for i .. num_threads: pthread_create( thr_main ) The first thing to note is that using glibc's non-MT malloc I achieved 2.67Mega cycles / second. Using the perl5 memory allocator (non-MT), I achieved 8.4Mega cycles / second. In both cases using pthreads (via uncommenting thread-specific code and linking -lpthread), the throughput fell to 0.978M / second ( for both perl5 and glibc ). Perhaps I'm not successfully mapping alloc to perl - I tried various alternative names for the allocator (such as New, Perl_xxx, etc). I obviously didn't have libumem to play with, but I did want to see what the lower-bound was for the various operations. I found some strange results. First I wrote an unlocked void* MyAlloc(int), void MyFree(void*) pair which simply used a stack for allocation. It wasn't a valid memory allocator, since it assumes that you free in reverse order but it sufficied. It achieved 20 million cycles / second. Next I added mutex's, which slowed the single thread down to 1.3Mega cycles/ second. The next thing I did was to split resources into separate arrays which are accessed via a hashing of the thread-id. This required (int)pthread_self(). The existing implementation is that thread_t is just an int, but it doesn't give me warm fuzzies doing this (how portable could that be). Strangely enough Linux's thread_id's are wildly jumping numbers (starting at over a thousand with at least a thousand numeric values separating each). The hash was a simple masking of the right several most bits (3 in my test case since I wasn't to test more than 10 simultaneous threads). Very quickly I found cache-line-contention to be a problem (just as the paper suggested). Since I was using separate arrays of integers, the cache-lines were hopelessly shared. My interoom solution was to multiply the thread_id by some value ( 8 or 16 work well ), at the expense of unused array elements. The following are some benchmarks (that I can still read from my scratch-sheets): Num-threads|run-time for thread-multiplier = 16 (pad)|run-time for thread-multiplier = 2|mutex's with multiplier=16 1|1.52s|1.52s|8.05s 2|8.25s|8.6s|16.14s 3|5.6s|12.99s|16.18s 4|3.86s|17.23s|21s 5|5.04s||23.19s 6|6.7s 7|6.64s One comment, the left-most data-set has some wild-swings; the more common occurance were something like: 1|1.52s|6.4Mega cycles / s 2|8s|2.5Mc/s 3|5s|6Mc/s 4|5.5s|7.2Mc/s 5|6s|8.3Mc/s 6|6.5s|... etc The above are based on the top of my head from the types of numbers I've seen after hundreds of tweaks and unrecorded runs. Two things seemed true. First, the more threads that were used, the more efficient it became. Secondly the second thread always seemed to provide the slowest / least-efficient operation, without exception. I can't explain this. It seemed impervious to cache-line-width padding. Note in the padding-times table that two threads took roughly the same time for both 2 and 16x thread_id multipliers. When only either a 1 or 2x muliplier, the run-time for 2 threads seems to fall in line with the other thread-values. The 1-thread operation is obviously faster because there is no cache-line contention. I'm curious to learn if this is a general problem with either Linux, x86, the dual-processor celerons or something more subtle. At this point I was using a two level memory manager. The first level was a thread-specific magazine allocator. In this primative memory system, there was no need for "data" / "previous" as described in the SUN paper, and instead a single magazine