Re: Quick Test hack for someone
On Mon, 24 Sep 2001, Simon Cozens wrote: >When tests fail for Really Bad reasons, they tend to do something like this: > >Got: ' >' >Expected: ' >ok 1 >... >' > >It'd be really nice if we could intercept that and give more detail on why >the test failed. Did the assembler compile to a PBC ok? Did the interpreter >segfault? (This is what usually happens.) Or did something else happen? Planning that for post 0.02. do you want that in before? I can do it sooner. >Would make debugging a lot quicker. Regards Mattia
Re: Window CE port? [WAS: Platforms Status]
On Tue 25 Sep 2001 06:00, "Kenneth YK Young" <[EMAIL PROTECTED]> wrote: > I listened in for a while but no one mentioned > Windows CE as a target. I believe that's becoz no > perl5 on Windows CE? But there *is* perl5 for WinCE. I've just passed the majority of the base bleadperl test suite on WinCE 2.11 :) The port is by Rainer Keuchel, and WinCE has been added to the official perl5 supported systems list. http://www.rainer-keuchel.de/software.html > Can someone advise what needs to be done to port > perl6 to CE (with or without porting perl5 first)? Contact Rainer Keuchel <[EMAIL PROTECTED]> > If I have the prerequisites, I'm willing to help - for fun. > (Though I don't expect CE to be core platform - at this > time.) Greatz! -- H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.6.1, 5.7.1 & 623 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
RE: Platforms Status
Buggs: # Collect all the P(ok)emons on the Core Platforms # and try to find the secret ways to the None Core Platforms. # Then proceed to level 0.0.2. # # -- # CORE PLATFORMS # -- # === # Linux (x86): # make ok / test ok # === # CygWin # Configure.pl fails # === # Win32 make ok / test ok (with caveats: nmake doesn't do 'test' correctly, and 'clean' doesn't work because of the 'rm' command) # === # Tru64 # make ok / test fails # === # OpenVMS (Alpha) # ?? # === # Solaris (Sparc) # ?? # === # FreeBSD (x86) # make ok / test ok # === # # - # NONE CORE PLATFORMS # - # # === # FreeBSD (Alpha) # make ok / test fails # === # Linux (Alpha) # make ok / test stacks fails # === # IRIX # make ok / test fails # === # Linux (Sparc) # make ok / test fails # === # iPaq (arm) # make ok / test fails (float errs) # === Linux (Itanium) make ok / test fails (badly--see smoke report below my sig) As you can see from the smoke report below, I've gotten remote smoke tests from Test-Drive machines (more or less) working. (I'll share how I did that in a later message.) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done. Automated smoke report for patch Sep 24 19:00:02 2001 UTC v0.01 on Linux using cc version 2.96-ia64-000717 snap 001117 O = OK F = Failure's), extended report at the bottom ? = still running or test results not (yet) available Build failures during: - = unknown c = Configure, m = make, t = make test-prep Configuration --- --- - F F --defaults F F --defaults --define nv=float F F --defaults --define nv=double F F --defaults --define nv=\"long double\" F F --defaults --define iv=int F F --defaults --define iv=int --define nv=float F F --defaults --define iv=int --define nv=double F F --defaults --define iv=int --define nv=\"long double\" F F --defaults --define iv=long F F --defaults --define iv=long --define nv=float F F --defaults --define iv=long --define nv=double F F --defaults --define iv=long --define nv=\"long double\" F F --defaults --define iv=\"long long\" F F --defaults --define iv=\"long long\" --define nv=float F F --defaults --define iv=\"long long\" --define nv=double F F --defaults --define iv=\"long long\" --define nv=\"long double\" | | | +- --debugging +--- normal Failures: linux--defaults linux--debugging --defaults t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define nv=float linux--debugging --defaults --define nv=float t/op/integerdubious DIED. FAILED test 25 linux--defaults --define nv=double linux--debugging --defaults --define nv=double t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define nv=\"long double\" linux--debugging --defaults --define nv=\"long double\" t/op/integerdubious DIED. FAILED test 25 linux--defaults --define iv=int linux--debugging --defaults --define iv=int linux--defaults --define iv=int --define nv=float linux--debugging --defaults --define iv=int --define nv=float linux--defaults --define iv=int --define nv=double linux--debugging --defaults --define iv=int --define nv=double linux--defaults --define iv=int --define nv=\"long double\" linux--debugging --defaults --define iv=int --define nv=\"long double\" t/op/basic..dubious DIED. FAILED test 1 linux--defaults --define iv=long linux--debugging --defaults --define iv=long t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define iv=long --define nv=float linux--debugging --defaults --define iv=long --define nv=float t/op/integerdubious DIED. FAILED test 25 linux--defaults --define iv=long --define nv=double linux--debugging --defaults --define iv=long --define nv=double t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define iv=long --define nv=\"long double\" linux--debugging --defaults --define iv=long --define nv=\"long double\" t/op/integerdubious DIED. FAILED test 25 linux--defaults --define iv=\"long long\" linux--debugging --defaults --define iv=\"long long\" t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define iv=\"long long\" --define nv=float linux--debugging --defaults --define iv=\"long long\" --define nv=float t/op/int
Re: [PATCH] Fix IRIX64 warnings
> > -opcode_t *(*(*opcode_funcs)[2048])(); /* Opcode */ > > - /* function table */ > > -STRING_FUNCS *(*(*string_funcs)[64])(); /* String function table */ > > +opcode_t *(**opcode_funcs)(); /* Opcode function table */ > > +STRING_FUNCS *(**string_funcs)(); /* String function table */ > > I'm a little unsure about this - where have those array declarations gone > and why? If you strip off the return type and argument list, the declaration of opcode_funcs is *(*opcode_funcs)[2048] which is a pointer to an array of function pointers (3 levels of indirection). But if you look in interpreter.c, you find foo = mem_sys_allocate(2048 * sizeof(void *)); ... interpreter->opcode_funcs = (void*)foo; which allocates the array and assigns it directly to opcode_funcs (2 levels of indirection), and the DO_OP macro has x = z->opcode_funcs; \\ y = x[*w]; \\ w = (y)(w,z); \\ which expands to code = (interpreter->opcode_funcs[*code])(code, interpreter); (again, 2 levels of indirection). So the declaration of opcode_funcs was at a different level of indirection than its allocation and use. The compilers weren't complaining about this because of all the (void *) casts. The IRIX64 compiler did complain, not about indirection levels, but about assigning data pointers to function pointers. For dynamic allocation of the opcode_funcs array (as in current code) the appropriate declaration of opcode_funcs is opcode_t *(**opcode_funcs)(); For static allocation, write opcode_t *(*opcode_funcs[2048])(); and drop the mem_sys_allocate. string_funcs isn't currently used, but I changed its declaration to match opcode_funcs. - SWM
Re: Platforms Status
On Monday 24 September 2001 22:59, Buggs wrote: > On Monday 24 September 2001 22:48, Simon Cozens wrote: > > On Mon, Sep 24, 2001 at 10:44:33PM +0200, Buggs wrote: > > > Tru64 > > > make ok / test fails > > > > Can I have some more data on this? Works perfectly here. > > The machine from Compaq Testdrive. > > Compaq Tru64 Unix 5.1(JAVA) ES40 4@667MHz (ev6) telnet to > 192.233.54.230 Actually that one sucks. But this one: Compaq Tru64 Unix 5.1a(JAVA) DS10-L 1@466MHz (ev6) telnet to 192.233.54.152 with perl5.6 does a lot nicer. stacks.t produces nice core dumps so. Buggs
Re: Window CE port? [WAS: Platforms Status]
On Tue, 25 Sep 2001, Kenneth YK Young wrote: > > I listened in for a while but no one mentioned > Windows CE as a target. I believe that's becoz no > perl5 on Windows CE? Nope. More because we've no development tools or platform for WinCE. (Unless the iPaq counts, but I presume it doesn't) I'd really like to get perl running on WinCE, though. It (and the Palm) are two definite target platforms for the final version of perl. If you can give things a whirl, that's be great--we'd be thrilled to roll any needed patches in. Dan
Window CE port? [WAS: Platforms Status]
I listened in for a while but no one mentioned Windows CE as a target. I believe that's becoz no perl5 on Windows CE? Can someone advise what needs to be done to port perl6 to CE (with or without porting perl5 first)? If I have the prerequisites, I'm willing to help - for fun. (Though I don't expect CE to be core platform - at this time.) Regards, kyoung - Original Message - From: "Buggs" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 25, 2001 4:44 AM Subject: Platforms Status > > Collect all the P(ok)emons on the Core Platforms > and try to find the secret ways to the None Core Platforms. > Then proceed to level 0.0.2. > > -- > CORE PLATFORMS > -- > === > Linux (x86): > make ok / test ok > === > CygWin > Configure.pl fails > === > Win32 > ?? > === > Tru64 > make ok / test fails > === > OpenVMS (Alpha) > ?? > === > Solaris (Sparc) > ?? > === > FreeBSD (x86) > make ok / test ok > === > > - > NONE CORE PLATFORMS > - > > === > FreeBSD (Alpha) > make ok / test fails > === > Linux (Alpha) > make ok / test stacks fails > === > IRIX > make ok / test fails > === > Linux (Sparc) > make ok / test fails > === > iPaq (arm) > make ok / test fails (float errs) > === > > > > Buggs >
Re: SV: Parrot multithreading?
On Monday 24 September 2001 11:54 am, Dan Sugalski wrote:
> Odds are you'll get per-op event checking if you enable debugging, since
> the debugging oploop will really be a generic "check event every op" loop
> that happens to have the "pending debugging event" bit permanently set.
> Dunno whether we want to force this at compile time or consider some way
> to set it at runtime. I'd really like to be able to switch oploops
> dynamically, but I can't think of a good way to do that efficiently.
Embed (them) within an outer loop (function). Program end would propogate
the finish. Otherwise, simply redirect to a new runops routine.
Potentially increases the call-stack by one, but performance hit only occurs
during the switch. Or you could collapse it all, if you have a fixed
number, into a switch.
runops ( ... )
{
run_ops_t run_ops_type= BLUE_MOON;
while (opcode != END) {
switch (run_ops_type) {
/* I want those events checked... */
case (YESTERDAY) {
while (opcode == VALID) { DO_OP1() } break;
}
/* Check the events every... */
case (NOW_AND_THEN) {
while (opcode == VALID) { DO_OP2() } break;
}
/* Look for an event once in a... */
case (BLUE_MOON) {
while (opcode == VALID) { DO_OP3() } break;
}
/* I'll check for an event when... */
case (HELL_FREEZES_OVER) {
while (opcode == VALID) { DO_OP4() } break;
}
}
run_ops_type = new_runops_loop(I,opcode);
}
/* yada yada yada */
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Quick Test hack for someone
On Tuesday 25 September 2001 00:00, Simon Cozens wrote: > When tests fail for Really Bad reasons, they tend to do something like > this: > > Got: ' > ' > Expected: ' > ok 1 > ... > ' > > It'd be really nice if we could intercept that and give more detail on why > the test failed. Did the assembler compile to a PBC ok? Did the interpreter > segfault? (This is what usually happens.) Or did something else happen? > > Would make debugging a lot quicker. The hack is to upgrade Test::Harness :) Looks much less wiered. BTW after updating cygwin(1.3.2 -> 1.3.3) it compiles. Buggs
[patch] time.t, bitwise.t, noop tests
Yet more fun with testing... patch at bottom, rambling first noop didn't have a test, ironic yes, but imagine the shame if it didn't work. Also time and bitwise ops tests. For the bitwise ops I've tried to be platform nice, these tests merely exercise the ops, rather than anything else. BUG: clear_s NULLs the string regs, so print_s on them segfaults. added test but skipped it... Looking at the print* ops, do we have a way to tell if a print failed? Will we want one at some point? We have shr_i_ic and friends, but not shr_i_i, is there good reason? With addition of this patch (below) only following ops remain without tests: print_nc push_p pop_p clear_p These ops have tests, but are skipped due to problems or being broken: clear_s jump_i Alex Gough -- If you are not too long, I will wait here for you all my life. ### against a snapshot from a few hours ago (ish..) --- clean/parrot/MANIFEST Mon Sep 24 20:00:01 2001 +++ parrot/MANIFEST Tue Sep 25 00:13:32 2001 @@ -65,9 +65,11 @@ t/local_label.pasm t/op/basic.t t/op/integer.t +t/op/bitwise.t t/op/number.t t/op/stacks.t t/op/string.t +t/op/time.t t/op/trans.t t/test.pasm t/test2.pasm diff -urN clean/parrot/t/op/basic.t parrot/t/op/basic.t --- clean/parrot/t/op/basic.t Sun Sep 16 17:21:16 2001 +++ parrot/t/op/basic.t Mon Sep 24 23:00:08 2001 @@ -1,6 +1,22 @@ #! perl -w -use Parrot::Test tests => 2; +use Parrot::Test tests => 5; + +# It would be very embarrassing if these didn't work... +output_is(<<'CODE', '', "noop, end"); + noop + end +CODE + +output_is(<<'CODE', '1', "print 1"); + print 1 + end +CODE + +output_is(<<'CODE', 'Parrot flies', "print string"); + print "Parrot flies" + end +CODE output_is( <<'CODE', '42', "branch_ic" ); set I4, 42 diff -urN clean/parrot/t/op/bitwise.t parrot/t/op/bitwise.t --- clean/parrot/t/op/bitwise.t Thu Jan 1 01:00:00 1970 +++ parrot/t/op/bitwise.t Tue Sep 25 00:09:12 2001 @@ -0,0 +1,78 @@ +#! perl -w + +use Parrot::Test tests => 4; + +output_is(<<'CODE', <<'OUTPUT', "shr_i_ic (>>)"); + set I0, 0b001100 + set I1, 0b010100 + shr I2, I0, 1 + shr I1, I1, 2 + print I2 + print "\n" + print I1 + print "\n" + print I0 + print "\n" + end +CODE +6 +5 +12 +OUTPUT + +output_is(<<'CODE', <<'OUTPUT', "xor_i"); + set I0, 0b001100 + set I1, 0b100110 + xor I2, I0, I1 + print I2 + print "\n" + xor I1, I0, I1 + print I1 + print "\n" + print I0 + print "\n" + end +CODE +42 +42 +12 +OUTPUT + +output_is(<<'CODE', <<'OUTPUT', "and_i"); + set I0, 0b001100 + set I1, 0b010110 + and I2, I0,I1 + print I2 + print "\n" + and I1,I0,I1 + print I1 + print "\n" + print I0 + print "\n" +CODE +4 +4 +12 +OUTPUT + +# use C to only check low order bits, this should be platform nice +output_is(<<'CODE', <<'OUTPUT', "not_i"); + set I0, 0b001100 + set I1, 0b001100 + set I31, 0b11 + not I2, I0 + and I2, I2, I31 + print I2 + print "\n" + not I1, I1 + and I1, I1, I31 + print I1 + print "\n" + print I0 + print "\n" +CODE +51 +51 +12 +OUTPUT +1; diff -urN clean/parrot/t/op/integer.t parrot/t/op/integer.t --- clean/parrot/t/op/integer.t Thu Sep 20 20:00:01 2001 +++ parrot/t/op/integer.t Tue Sep 25 00:20:20 2001 @@ -814,3 +814,5 @@ CODE OUTPUT + +1; diff -urN clean/parrot/t/op/string.t parrot/t/op/string.t --- clean/parrot/t/op/string.t Mon Sep 24 20:00:01 2001 +++ parrot/t/op/string.tTue Sep 25 00:08:50 2001 @@ -1,6 +1,6 @@ #! perl -w -use Parrot::Test tests => 9; +use Parrot::Test tests => 10; output_is( <<'CODE', < 2; + +output_is(<<'CODE', <<'OUTPUT', "time_i"); + timeI0 + timeI1 + ge I0, 0, OK1 + branch FAIL +OK1: print "ok, (!= 1970) Grateful Dead not\n" + ge I1, I0, OK2 + branch FAIL +OK2: print "ok, (now>before) timelords need not apply\n" + branch OK_ALL +FAIL: print "failure\n" +OK_ALL: + end +CODE +ok, (!= 1970) Grateful Dead not +ok, (now>before) timelords need not apply +OUTPUT + +output_is(<<'CODE', <<'OUTPUT', "time_n"); + timeN0 + timeN1 + ge N0, 0, OK1 + branch FAIL +OK1: print "ok, (!= 1970) Grateful Dead not\n" + ge N1, N0, OK2 + branch FAIL +OK2: print "ok, (now>before) timelords need not apply\n" + branch OK_ALL +FAIL: print "failure\n" +OK_ALL: + end +CODE +ok, (!= 1970) Grateful Dead not +ok, (now>before) timelords need not apply +OUTPUT +1;
Quick Test hack for someone
When tests fail for Really Bad reasons, they tend to do something like this: Got: ' ' Expected: ' ok 1 ... ' It'd be really nice if we could intercept that and give more detail on why the test failed. Did the assembler compile to a PBC ok? Did the interpreter segfault? (This is what usually happens.) Or did something else happen? Would make debugging a lot quicker. -- fga is frequently given answers... the best are "Date::Calc", "use a hash", and "yes, it's in CPAN" or Data::Dumper or mySQL or "check your permissions" or NO Fmh THAT'S WRONG or "You can't. crypt is one-way" or "yes, i'm single" or "I think that's a faq." or substr! or "use split" or "man perlre" - #perl
[PATCH] print_s_v op (was: RE: variable number of arguments)
All --
I've created a varargs-ish example by making a new op, print_s_v.
This is pretty rough, and I haven't updated the assembler, but it
seems to work.
I'm attaching a patch, and a test program (pt.pasm).
Enjoy!
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc.http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_/
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.45
diff -u -r1.45 assemble.pl
--- assemble.pl 2001/09/24 16:01:58 1.45
+++ assemble.pl 2001/09/24 21:25:57
@@ -303,19 +303,55 @@
error("No opcode $opcode ( tried " . join(', ', @tests) . ") in
<$pline>",$file,$line);
}
}
-if (@args != $opcodes{$opcode}{ARGS}) {
- error("Wrong arg count--got ".scalar(@args)." needed
".$opcodes{$opcode}{ARGS}." in <$_>" ,$file,$line);
+
+my $varop = $opcode =~m/_v$/;
+
+if ($varop) {
+ if (@args < $opcodes{$opcode}{ARGS}) {
+error("Wrong arg count--got ".scalar(@args)." needed at
+least".$opcodes{$opcode}{ARGS}." in <$_>" ,$file,$line);
+ }
+} else {
+ if (@args != $opcodes{$opcode}{ARGS}) {
+error("Wrong arg count--got ".scalar(@args)." needed
+".$opcodes{$opcode}{ARGS}." in <$_>" ,$file,$line);
+ }
}
+
$bytecode .= pack_op($opcodes{$opcode}{CODE});
$op_pc=$pc;
$pc+=sizeof('op');
+if ($varop) {
+ splice(@args, $opcodes{$opcode}{ARGS} - 1, 0, scalar(@args)); # Splice in the
+arg count.
+}
+
foreach (0..$#args) {
my($rtype)=$opcodes{$opcode}{TYPES}[$_];
+
+if ($varop) {
+ if (not defined $rtype) {
+if ($args[$_] =~ m/^([INPS])(\d+)$/) {
+ $rtype = $1;
+} elsif ($args[$_] =~ m/^\d+\.\d+$/) {
+ $rtype = 'n';
+} elsif ($args[$_] =~ m/^\d+$/) {
+ $rtype = 'i';
+} elsif ($args[$_] =~ m/^\[\d+\]$/) {
+ $rtype = 's';
+} else {
+ $rtype = '*';
+ warn "Could not infer arg type!";
+}
+ } elsif ($rtype eq 'v') {
+$rtype = 'i';
+ }
+}
+
if($rtype eq "I" || $rtype eq "N" || $rtype eq "P" || $rtype eq "S") {
# its a register argument
- $args[$_]=~s/^[INPS](\d+)$/$1/i;
- error("Register $1 out of range (should be 0-31) in
'$opcode'",$file,$line) if $1 < 0 or $1 > 31;
+ $args[$_] =~ m/^[INPS](\d+)$/i;
+ error("Register '" . $args[$_] . "' unparseable in '$opcode'",$file,$line)
+unless defined $1;
+ error("Register '$args[$_]' out of range (should be 0-31) in
+'$opcode'",$file,$line) if $1 < 0 or $1 > 31;
+ $args[$_] = $1;
} elsif($rtype eq "D") {
# a destination
if($args[$_]=~/^\$/) {
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.24
diff -u -r1.24 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/24 16:27:48 1.24
+++ basic_opcodes.ops 2001/09/24 21:25:57
@@ -6,7 +6,10 @@
#include "parrot/parrot.h"
#include
+#include
+#define VP(n) cur_opcode[(n) + 2]
+
/* SET Ix, CONSTANT */
AUTO_OP set_i_ic {
INT_REG(P1) = P2;
@@ -141,6 +144,89 @@
/* TIME Ix */
AUTO_OP time_i {
INT_REG(P1) = time(NULL);
+}
+
+/* PRINTF Sx, Vz */
+MANUAL_OP print_s_v {
+ const char * fmt = STR_REG(P1)->bufstart;
+ IV fmt_len = string_length(STR_REG(P1));
+ IV fmt_idx;
+ char fmt_last = '\0';
+ int in_format = 0;
+ STRING * s;
+ IV arg = 0; /* No args so far */
+ const char * str;
+ IV str_len;
+
+ /* TODO: Grab P2 (argc) and make sure we don't overrun it!!! */
+
+ for(fmt_idx = 0; fmt_idx < fmt_len; fmt_idx++) {
+if (fmt[fmt_idx] == '%' && fmt_last != '\\') {
+ in_format = fmt_idx + 1; /* the char after '%' */
+ continue;
+}
+
+/* TODO: DANGER: Assumes IV-sized NVs!!! */
+
+if (in_format) {
+ switch (fmt[fmt_idx]) {
+case 'i':
+ /* TODO: inherit the precision, etc. */
+ arg++;
+ printf("%d", VP(arg));
+ in_format = 0;
+ break;
+
+case 'I':
+ /* TODO: inherit the precision, etc. */
+ arg++;
+ printf("%d", INT_REG(VP(arg)));
+ in_format = 0;
+ break;
+
+case 'n':
+ /* TODO: inherit the precision, etc. */
+ arg++;
+ pri
Re: Platforms Status
On Monday 24 September 2001 22:48, Simon Cozens wrote: > On Mon, Sep 24, 2001 at 10:44:33PM +0200, Buggs wrote: > > Tru64 > > make ok / test fails > > Can I have some more data on this? Works perfectly here. The machine from Compaq Testdrive. Compaq Tru64 Unix 5.1(JAVA) ES40 4@667MHz (ev6) telnet to 192.233.54.230 Could also be the Perl, which is 5.005_03. Same problems as on FreeBSD (Alpha). A lot of these # Failed test (Parrot/Test.pm at line 74) # got: '' # expected: 'ok 1 ok 2 Buggs
Re: Platforms Status
On Mon, Sep 24, 2001 at 10:44:33PM +0200, Buggs wrote: > Tru64 > make ok / test fails Can I have some more data on this? Works perfectly here. -- To downgrade the human mind is bad theology. - C. K. Chesterton
Platforms Status
Collect all the P(ok)emons on the Core Platforms and try to find the secret ways to the None Core Platforms. Then proceed to level 0.0.2. -- CORE PLATFORMS -- === Linux (x86): make ok / test ok === CygWin Configure.pl fails === Win32 ?? === Tru64 make ok / test fails === OpenVMS (Alpha) ?? === Solaris (Sparc) ?? === FreeBSD (x86) make ok / test ok === - NONE CORE PLATFORMS - === FreeBSD (Alpha) make ok / test fails === Linux (Alpha) make ok / test stacks fails === IRIX make ok / test fails === Linux (Sparc) make ok / test fails === iPaq (arm) make ok / test fails (float errs) === Buggs
RE: Strings db
> > GNU does offer the gettext tools library for just such a purpose. I don't > > know how it will translate to the various platforms however, and it likely > > is a major overkill for what we are trying to do. > > http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose > > It might make sense to implement something like this now, rather than create > > our own system and find out it is insufficient down the road. > > Just a thought, > > Grant M. > > But wouldn't that make parrot GPL'd? You could use the gettext tools to generate the catalogs, and reimplement the part that reads the strings from the catalog. wxWindows does just that. Regards Mattia
RE: variable number of arguments
> >
> >I have a minor issue with a proliferation of createArray. In perl5 we
> >used the Stack for just about everything minus physically setting @x =
> >(1,2,3). The creation of a dynamic array is a memory hog.
>
> Less of a hog in many ways than using a stack. Worth the times when it's not.
I don't see how. A stack is "supposed" to be pre-existing and maintain
headroom for growth. The simplest stack (which I think is plenty peppy)
is one that checks bounds and realloc's when it grows too much. If it
grew that big once, then it would surely grow that bug in the future,
which alleviates memory fragmentation.
There's already a stack structure in interpreter_t. I'm not sure how
parameter passing is being implemented yet, but anything other than some
type of stack is going to have problems. (which can only be addressed via
dynamic allocation of arrays.. which are just slower-parameter-stacks).
>
> >ESPECIALLY with
> >mark-and-sweep dynamic memory (which is sounds like perl6 is aiming for).
>
> I don't see the connection here.
The connection had to do with the allocation / deallocation of these
intermediate dynamic arrays. It was just a call-of-attention to the ever
present point of performance degredation.
>
> If the compiler generates code like that and I'm happy about it, someone
> needs to smack me. *hard*. :)
>
> That ought to be either a series of print ops or, more likely, a set of
> push ops and a final prints.
But pushing onto what? A PMC which points to a dynamic array? Pushing is
arguable slower than pre-extending an array and statically assigning to an
index, since you avoid multiple increments. Not to mention if you push a
million entries, you might have to regrow the array 20 or more times.
I stated why I used the array for the print, but you could substitude
print for "@y = map { .. } (1,2,@x)" which would require an intermediate
array of memory. We just didn't have asembly available for that code.
You could set P1 to the new array and concat the three terms, but that
ultimately involves iterating through the array @x and "pushing values".
So you've not escaped the use of a stack. What's more since this is a
temporary stack, you deal with memory management.
Once again, the alternative is a general purpose stack, who's memory
management is minimal.
> >In any case, what we've done here is dynamically create an array each time
> >through the loop.
>
> Yes, but we're doing this with a stack-based system anyway. It's just an
> anonymous pesudo-array (i.e. the stack top), but an array nonetheless.
I'm not convinced that we can't /shouldn't implement persistent
general-purpose stacks, which include parameter passing. Obviously this
would require frame-support (since otherwise @_ would have to be a newly
allocated array), and it seems that the direction is towards
the exclusive use of registers. I just don't know that this doesn't
provide even greater performance / memory penalties than for non-static
parameter functions (such as print / map / grep or non-proto-typed
subroutines).
The way I see such a stack being used:
interp:
..
Stack stack;
Stack frame;
AUTO_OP push_x {
if ( stack->top >= stack->size ) {
grow_stack(stack);
}
setPMC( stack->data[ stack->top++ ], P1 );
}
AUTO_OP get_stack_frame_size {
REG_INT(P1) = stack->top - frame->data[ frame->top ];
}
AUTO_OP push_frame {
// auto-extend frame-stack
frame->data[ frame->top++ ] = stack->top;
}
AUTO_OP get_stack_X_i {
REG_X[P1] = [ stack->data[ frame->data[ frame->top ] + P2 ];
}
// set_stack_X_i
// alloc_stackn
AUTO_OP pop_frame {
stack->top = frame->data[ --frame->top ];
}
Internal c-code could even get pointers to the base-frame so as to avoid
all the indirections. So print, map, grep, etc would be able to read
quickly. You could additionally have efficient op-codes that copy in PMC
arrays to the stack.
That said, if we're exclusively using registers for parameter passing then
there's currently the issue of efficiently passing and returning values.
Currently the only way to pass parameters is to duplicate a given register
set, then move parameters around so they'll be where a subroutine expects
it. The called function would then push any additional
register-segments-stacks that weren't given parameters so it wouldn't
overwrite the caller's values. When complete, it would restore those
reg-stacks that it pushed and would leave return values as presents in P1,
I1, etc. But now the caller has to pop it's register-stacks to get back
to it's old values. But in doing so, it'll lose the return value(s).
There are two ways I can see this working. The first involves doing a
half-push / half-pop. Where you have a 16register input window and a 16
register output window. If a function can accomplish it's tasks with
whatever is left-over, then it doesn't need to do another half-push (it
just can't touch P1..16). On return, the return-values are in P17..P32.
The caller would have to copy the
Re: SV: Parrot multithreading?
On Mon, 24 Sep 2001, Uri Guttman wrote: > >> then what about a win/win? we could make the event checking style a > >> compile time option. > > DS> Odds are you'll get per-op event checking if you enable debugging, > DS> since the debugging oploop will really be a generic "check event > DS> every op" loop that happens to have the "pending debugging event" > DS> bit permanently set. Dunno whether we want to force this at > DS> compile time or consider some way to set it at runtime. I'd really > DS> like to be able to switch oploops dynamically, but I can't think > DS> of a good way to do that efficiently. > > hmmm. what about a special op that implements another form of op loop? > the overhead is almost nil (one op call). the called op loop can run > forever or decide to return and then the parent op loop takes over > again. This type of approach could be implemented in an extension module, could it not? Because of the current flexible design of Parrot, we don't have to implement this type of opcode into the core any more than, say fork. Do we? - D <[EMAIL PROTECTED]>
Re: IRIX64 tests
On Mon, Sep 24, 2001 at 03:16:47PM -0400, Steven W McDougall wrote:
> t/op/number.t 255 6528023 144 626.09% 1-23
> 6/74 subtests failed
Looks like Test::Harness has no brains either.
--
For true believers, LORD would be K\textsc{nuth} in TeX, and
L\textsc{amport} in LaTeX. Atheists prefer \phantom{LORD}. Agnostics
may need to use the ifthen package.
- Chris Boyd, comp.text.tex
IRIX64 tests
> Just out of interest, what are the tests looking like on IRIX? mmm...not so good. - SWM world:~/src/Perl/parrot>uname -a IRIX64 world 6.2 03131016 IP19 world:~/src/Perl/parrot>make test perl t/harness t/op/basic..ok 1/2skip() is UNIMPLEMENTED! at /home/abhaile/swmcd/perl/lib/s ite_perl/5.6.1/Test/More.pm line 505. t/op/basic..dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED test 2 Failed 1/2 tests, 50.00% okay t/op/integerok t/op/number.ok 2/23Confused test output: test 2 answered after test 6 t/op/number.NOK 7Test output counter mismatch [test 7] t/op/number.ok 2/23Confused test output: test 2 answered after test 7 t/op/number.NOK 8Test output counter mismatch [test 8] t/op/number.ok 2/23Confused test output: test 2 answered after test 8 t/op/number.NOK 9Test output counter mismatch [test 9] t/op/number.ok 2/23Confused test output: test 2 answered after test 9 t/op/number.NOK 10Test output counter mismatch [test 10] t/op/number.ok 2/23Confused test output: test 2 answered after test 10 t/op/number.NOK 11Test output counter mismatch [test 11] t/op/number.ok 2/23Confused test output: test 2 answered after test 11 t/op/number.NOK 12Test output counter mismatch [test 12] t/op/number.ok 2/23Confused test output: test 2 answered after test 12 t/op/number.NOK 13Test output counter mismatch [test 13] t/op/number.ok 2/23Confused test output: test 2 answered after test 13 t/op/number.NOK 14Test output counter mismatch [test 14] t/op/number.ok 2/23Confused test output: test 2 answered after test 14 t/op/number.NOK 15Test output counter mismatch [test 15] t/op/number.ok 2/23Confused test output: test 2 answered after test 15 t/op/number.NOK 16Test output counter mismatch [test 16] t/op/number.ok 2/23Confused test output: test 2 answered after test 16 t/op/number.NOK 17Test output counter mismatch [test 17] t/op/number.ok 2/23Confused test output: test 2 answered after test 17 t/op/number.NOK 18Test output counter mismatch [test 18] t/op/number.ok 2/23Confused test output: test 2 answered after test 18 t/op/number.NOK 19skip() is UNIMPLEMENTED! at /home/abhaile/swmcd/perl/lib/s ite_perl/5.6.1/Test/More.pm line 505. Test output counter mismatch [test 19] t/op/number.dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1-23 Failed 23/23 tests, 0.00% okay t/op/string.ok 3/5skip() is UNIMPLEMENTED! at /home/abhaile/swmcd/perl/lib/s ite_perl/5.6.1/Test/More.pm line 505. t/op/string.dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 4-5 Failed 2/5 tests, 60.00% okay t/op/trans..dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 13, 18 Failed 2/18 tests, 88.89% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/basic.t 255 65280 21 50.00% 2 t/op/number.t 255 6528023 144 626.09% 1-23 t/op/string.t 255 65280 52 40.00% 4-5 t/op/trans.t 2 512182 11.11% 13 18 Failed 4/5 test scripts, 20.00% okay. 6/74 subtests failed, 91.89% okay. gmake: *** [test] Error 2 world:~/src/Perl/parrot>
Re: Strings db
At 08:42 PM 9/24/2001 +0200, Paolo Molaro wrote: >On 09/24/01 Michael Maraist wrote: > > > GNU does offer the gettext tools library for just such a purpose. I don't > > > know how it will translate to the various platforms however, and it > likely > > > is a major overkill for what we are trying to do. > > > http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose > > > It might make sense to implement something like this now, rather than > create > > > our own system and find out it is insufficient down the road. > > > Just a thought, > > > Grant M. > > > > But wouldn't that make parrot GPL'd? > >IIRC, the latest release is LGPL and GLib 2.0 will probably contain a >(again LGPL) gettext implementation to be used on systems that don't >provide their own. LGPL's much better, though we still have the issue of portability and self-containedness. We'd probably end up having to ship gettext with perl, which has its own set of problems. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] "Fix" mod op
At 02:25 PM 9/24/2001 -0400, Gregor N. Purdy wrote: >Fortunately, there is a perfectly rational definition of the mod(x,y) >function over the full domains of x and y, and even for x and y that >are not integral. This can be found in the book Concrete Mathematics, >Second Edition by Graham, Knuth and Patashnik (Section 3.4, pages >81-85. Keen, I'd forgotten that was in there. I'd say toss the other mods and go with this as our sole modulus operator, assuming that it behaves the same as C's % for positive integers. Once the feature freeze is over this can go in. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: variable number of arguments
At 01:03 PM 9/24/2001 -0400, Michael Maraist wrote:
> > > is it possible the ops to handle variable number of arguments, what I
> have
> > > in mind :
> > >
> > > print I1,",",N2,"\n"
> >
> > This should be done by create array opcode plus print array opcode.
> >
> > [1, 2, 3, 4, 5]
>
>I have a minor issue with a proliferation of createArray. In perl5 we
>used the Stack for just about everything minus physically setting @x =
>(1,2,3). The creation of a dynamic array is a memory hog.
Less of a hog in many ways than using a stack. Worth the times when it's not.
>ESPECIALLY with
>mark-and-sweep dynamic memory (which is sounds like perl6 is aiming for).
I don't see the connection here.
>Lets say you wanted
>for(...) {
> x++
> y++
> z++
> print "x=$x, y=$y, z=$z"
>}
>Then you'd possibly have
>
>LOOP: cond_eq Ix, DONE
>inc I1, 1
>inc I2, 1
>inc I3, 1
>createArray P1, 6
>setIndexOf P1, 0, "x="
>setIndexOf P1, 1, I1
>setIndexOf P1, 2, ", y="
>setIndexOf P1, 3, I2
>setIndexOf P1, 4, ", z="
>setIndexOf P1, 5, I3
>print P1
>branch LOOP
>DONE:
If the compiler generates code like that and I'm happy about it, someone
needs to smack me. *hard*. :)
That ought to be either a series of print ops or, more likely, a set of
push ops and a final prints.
>In any case, what we've done here is dynamically create an array each time
>through the loop.
Yes, but we're doing this with a stack-based system anyway. It's just an
anonymous pesudo-array (i.e. the stack top), but an array nonetheless.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Strings db
On 09/24/01 Michael Maraist wrote: > > GNU does offer the gettext tools library for just such a purpose. I don't > > know how it will translate to the various platforms however, and it likely > > is a major overkill for what we are trying to do. > > http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose > > It might make sense to implement something like this now, rather than create > > our own system and find out it is insufficient down the road. > > Just a thought, > > Grant M. > > But wouldn't that make parrot GPL'd? IIRC, the latest release is LGPL and GLib 2.0 will probably contain a (again LGPL) gettext implementation to be used on systems that don't provide their own. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
Re: parrot malloc (was Re: Parrot coredumps on Solaris 8)
On Mon, 24 Sep 2001, Uri Guttman wrote: > > "AB" == Alan Burlison <[EMAIL PROTECTED]> writes: > > AB> If you are interested, I'll try to get a copy of the paper to you. > AB> It has some interesting ideas. By having 'arenas' for each object > AB> type, you can remove a large part of the overhead of > AB> splitting&recombing memory cgunks. The perl5 allocator already > AB> does something similar. > > sounds like a wheel worth looking at. are there working free C libs that > implement it? how much work is it to write a new one that is > parrot-centric? would we need all of it features that manage other > things? i assume that the segmented stacks would also use arenas like > this. we will need to define our set of arenas and sizes at some point. > > we haven't touched threads and malloc. does each thread want its own > arena so we don't need locking? > Interesting idea. The main allocator could be locked, so long as x% of all allocations come from thread-specific arenas. The only problem is that this adds overhead to creating / deleting threads (setting up / freeing arena chunks). This would only be efficient if the main allocator only returned chunks on the order of a page-size (which is then divided up into smaller granuled arenas by the parallel procssing threads). Another method would be to act like databases do - You finely tune your memory allocator so that you only perform regional locks. You also point threads to different starting / insertion points along the memory chains. This way you have a unified memory allocation scheme with only occasional contention locks. If all your data-structures are in large chunks (on the order of a page), then this would do well. (Though it might require architecture specific test-and-set operations for efficiency). -Michael
[PATCH] "Fix" mod op
All --
As I understand it, computer languages differ in their implementation
of the mod() function. I've heard some architectures differ, too, so
that the same language (such as C or Perl) might behave differently on
different machines (I'd be interested to know if this is really true).
Fortunately, there is a perfectly rational definition of the mod(x,y)
function over the full domains of x and y, and even for x and y that
are not integral. This can be found in the book Concrete Mathematics,
Second Edition by Graham, Knuth and Patashnik (Section 3.4, pages
81-85.
It seems to me that if we are going to offer folks a 'mod' operator,
we should be (a) guaranteeing that wherever their program is running,
they'll get the same behavior, even with negative arguments and
(b) picking among the possible definitions the one with the most
complete coverage of the domain and most 'useful' mathematical
definition.
With that in mind, I've implemented the GKP mod function for Parrot,
and added tests for it to t/op/integer.t and t/op/number.t. Just in
case someone needs to use the underlying C mod function (the % operator
for integers, and the fmod() function from math.h for numbers), I've
also implemented cmod_i and cmod_n ops.
This way, if someone is doing something with 'mod' in the inner loop,
and knows that the underlying C version behaves as they want for all
possible argument values the inner loop will use, they can use the
faster version.
Anyway, here's the patch if anyone wants to play with it. Of course,
this is at best post-0.0.2 material, and at worst what-the-hell-were-
you-thinking-gregor material. :-)
BTW, one application for which I know these versions of mod to be
useful are in Calendrical Calculations, at least as discussed in
the book of that name.
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc.http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_/
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.24
diff -u -r1.24 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/24 16:27:48 1.24
+++ basic_opcodes.ops 2001/09/24 18:12:02
@@ -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 -u -r1.22 opcode_table
--- opcode_table2001/09/24 16:27:48 1.22
+++ opcode_table2001/09/24 18:12:02
@@ -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.5
diff -u -r1.5 integer.t
--- t/op/integer.t 2001/09/20 14:03:59 1.5
+++ t/op/integer.t 2001/09/24 18:12:02
@@ -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: SV: Parrot multithreading?
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: >> then what about a win/win? we could make the event checking style a >> compile time option. DS> Odds are you'll get per-op event checking if you enable debugging, DS> since the debugging oploop will really be a generic "check event DS> every op" loop that happens to have the "pending debugging event" DS> bit permanently set. Dunno whether we want to force this at DS> compile time or consider some way to set it at runtime. I'd really DS> like to be able to switch oploops dynamically, but I can't think DS> of a good way to do that efficiently. hmmm. what about a special op that implements another form of op loop? the overhead is almost nil (one op call). the called op loop can run forever or decide to return and then the parent op loop takes over again. this would be very cool for event loop management. you could force a scan of event explicitly by making a call to a event flag checking loop when you feel like it in some large crunching code. similarly, you could enable a debug/trace/event flag loop explicitly at run time. we would need some form of language support for this but is it nothing odd. just a special var or call that selects a loop type. the parrot code generated is just the op loop set function. it could be block scoped or global (which means all code/calls below this use it). uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
RE: [PATCH] assemble.pl registers go from 0-31
> >Just curious, do we need a dedicated zero register and sink register? > > I've been pondering that one and waffling back and forth. At the moment I > don't think so, since there's no benefit to going with a zero register over > a zero constant, but that could change tomorrow. For example, once we have subcall, we want to provide all arguments in registers, instead of some args in regs, some in constant pool, some in inline literals. At least, this is a reasonable approach. The sink register can be used for in-place patch (for debugging, profiling, or whatever) without re-arrange the opcodes and offsets. It is of little use. Just a thought. Hong
RE: [PATCH] assemble.pl registers go from 0-31
--- Hong Zhang <[EMAIL PROTECTED]> wrote: > Just curious, do we need a dedicated zero register and > sink register? > The zero register always reads zero, and can not be > written. The sink > register can not be read, and write to it can be ignored. Those, probably not = we have a real nop, and it takes the same number of bits to encode a register as it does a literal integral zero. What we may want (and I've brought up before) is special PMC registers, so our contstant tables aren't clogged up with undefs or the like. -- BKS __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com
RE: [PATCH] assemble.pl registers go from 0-31
At 09:39 AM 9/24/2001 -0700, Hong Zhang wrote: > > Attached patch makes sure you don't try and use register numbers over > > 31. That is, this patch allows registers I0-I31 and anything else gets > > a: Error (foo.pasm:0): Register 32 out of range (should be > > 0-31) in 'set_i_ic' > > > > Oh, there's also a comment at end of line patch that has snuck in 'cos > > it's so darn useful. > >Just curious, do we need a dedicated zero register and sink register? I've been pondering that one and waffling back and forth. At the moment I don't think so, since there's no benefit to going with a zero register over a zero constant, but that could change tomorrow. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Strings db
At 12:38 PM 9/24/2001 -0400, Michael Maraist wrote: > > GNU does offer the gettext tools library for just such a purpose. I don't > > know how it will translate to the various platforms however, and it likely > > is a major overkill for what we are trying to do. > > http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose > > It might make sense to implement something like this now, rather than > create > > our own system and find out it is insufficient down the road. > > Just a thought, > > Grant M. > >But wouldn't that make parrot GPL'd? Not if we re-implemented it. Which wouldn't be unreasonable if the interface is good. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: SV: Parrot multithreading?
At 12:27 PM 9/24/2001 -0400, Michael Maraist wrote: > > >then what about a win/win? we could make the event checking style a > > >compile time option. > > > > Odds are you'll get per-op event checking if you enable debugging, since > > the debugging oploop will really be a generic "check event every op" loop > > that happens to have the "pending debugging event" bit permanently set. > > Dunno whether we want to force this at compile time or consider some way to > > set it at runtime. I'd really like to be able to switch oploops > > dynamically, but I can't think of a good way to do that efficiently. > > > >long-jump!!! I did say *good* way... :) >This would work well for fake-threads too We're not doing fake threads. Luckily we don't need it for real ones. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [patch(es)] strings, tests
On Sat, Sep 22, 2001 at 11:56:26PM +0100, Alex Gough wrote: > I wrote some tests today... Thanks, applied. -- A year spent in artificial intelligence is enough to make one believe in God.
RE: [PATCH] assemble.pl registers go from 0-31
> Just curious, do we need a dedicated zero register and sink register?
> The zero register always reads zero, and can not be written. The sink
> register can not be read, and write to it can be ignored.
I brain-stormed this idea a while ago, and here's what I came up with.
We're not RISC, so we don't need to worry about mapping "mov %r1 -> %r2"
to "or %r1, %r0 -> %r2", which is probably the most common use.
Additionally we'll always be able to use constants of size 32/64bits.
RISC could only use 8-22bit constants so often times it was easiest to
operate on a full 32bit zero. We could always add a second constant
parameter to an instruction if it was demed useful enough.
As for a bit-buck, I can't imagine why you'd use it. Side effects and
no-ops are all I can remember them ever being useful for. But again we're
not RISC, we have a no-op, and can add separate functions for
side-effects.
Lastly, the main reason I say no:
AUTO_OP add_i_i_i {
int p2_val = 0, p3_val = 0;
if ( P2 != 0 ) {
p2_val = REG_INT(P2);
}
if ( P3 != 0 ) {
p3_val = REG_INT(P3);
}
if ( P1 == 0 ) {
p2_val+p3_val;
} else {
REG_INT(P1) = p2_val+p3_val;
}
}
Any questions?
You could have an optimizer convert all %i0 to constants and rearrange the
op-code so it maps to a real one, but you could just have had the compiler
produce proper code in the first place. I don't think we're looking to
use assembly as one of the "supported" language layers. Due to it's
propensity to change.
-Michael
Re: Strings db
We could use the bsd gettext though, couldn't we? --Josh At 12:49 on 09/24/2001 PDT, "Wizard" <[EMAIL PROTECTED]> wrote: > Michael Maraist wrote: > > But wouldn't that make parrot GPL'd? > Yes, Yes it would. > (cup o' coffee and a sux donut, please.) > Never mind. I'll take a look at the docs and look around some more and see > what other clever ideas we can't use. > Grant M. > >
RE: variable number of arguments
> > is it possible the ops to handle variable number of arguments, what I have
> > in mind :
> >
> > print I1,",",N2,"\n"
>
> This should be done by create array opcode plus print array opcode.
>
> [1, 2, 3, 4, 5]
I have a minor issue with a proliferation of createArray. In perl5 we
used the Stack for just about everything minus physically setting @x =
(1,2,3). The creation of a dynamic array is a memory hog. ESPECIALLY with
mark-and-sweep dynamic memory (which is sounds like perl6 is aiming for).
Lets say you wanted
for(...) {
x++
y++
z++
print "x=$x, y=$y, z=$z"
}
Then you'd possibly have
LOOP: cond_eq Ix, DONE
inc I1, 1
inc I2, 1
inc I3, 1
createArray P1, 6
setIndexOf P1, 0, "x="
setIndexOf P1, 1, I1
setIndexOf P1, 2, ", y="
setIndexOf P1, 3, I2
setIndexOf P1, 4, ", z="
setIndexOf P1, 5, I3
print P1
branch LOOP
DONE:
Obviously this could be written differently (say using 6 separate
print-statements.. but we're saying that print is slow, so we'd want to
minimize calls to it; possibly via performing an implicit join when
printing an array). Additionally createArray could have happened on one
line, but that's not an issue either (this avoids type-issues).
In any case, what we've done here is dynamically create an array each time
through the loop. Theoretically we could reuse the same array, but what
if instead of a loop this is part of a log function which happens to get
called a zilion times in debug mode. For many types of gc-ers,
pointing to something new leaves the unreferenced data stranded until
we're either memory starved or a timer goes off. In the case of a
createArray in an inner loop, we could segment the entire memory map into
chunks that fit this dynamic array before we starve for memory. Depending
on the memory allocator, gcing that data will mean coallescing ALL of it
(potentially hundreds of meg worth).
Recently, there was an international programming contest for compressing
XML, and I wrote a program using perl. Worked great, except when I used
input data on the order of a meg, I consumed 300-400meg worth of
user-memory. No biggie, but when the program was finished (physically
output the result) it took just as long to deallocate everything
(20minutes). My guess is that the gnu memory allocator used by perl5 w/in
red-hat 7.1 did some heavy coallescing. When I used perl5's shipped
memory allocator w/ no coallescing, the program exited in a nominal amount
of time (while saving some 100Meg of memory to boot). Lets just say that
I developed a new fondness for the perl5 memory allocator.
The lesson I learned was to not take for granted dynamically allocated
memory). A simple mark-and-sweep GC is going to have a major hickup
periodically with this sort of inner-loop allocation. In this case
ref-counting would at least not leave a stragling allocation, and thus
would not micro-fragment / hickup. I'm sure you can write the
mem-allocator to gc before fragmenting larger chunks, but it's still
excess CPU overhead for this task.
The point here is to avoid the use of dynamic allocation where possible;
especially with the internals.
This is a perfect use for the perl-stack, short and simple.
-Michael
RE: Strings db
Michael Maraist wrote: > But wouldn't that make parrot GPL'd? Yes, Yes it would. (cup o' coffee and a sux donut, please.) Never mind. I'll take a look at the docs and look around some more and see what other clever ideas we can't use. Grant M.
RE: [PATCH] assemble.pl registers go from 0-31
> Attached patch makes sure you don't try and use register numbers over > 31. That is, this patch allows registers I0-I31 and anything else gets > a: Error (foo.pasm:0): Register 32 out of range (should be > 0-31) in 'set_i_ic' > > Oh, there's also a comment at end of line patch that has snuck in 'cos > it's so darn useful. Just curious, do we need a dedicated zero register and sink register? The zero register always reads zero, and can not be written. The sink register can not be read, and write to it can be ignored. Hong
RE: Strings db
> GNU does offer the gettext tools library for just such a purpose. I don't > know how it will translate to the various platforms however, and it likely > is a major overkill for what we are trying to do. > http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose > It might make sense to implement something like this now, rather than create > our own system and find out it is insufficient down the road. > Just a thought, > Grant M. But wouldn't that make parrot GPL'd? -Michael
RE: variable number of arguments
> is it possible the ops to handle variable number of arguments, what I have > in mind : > > print I1,",",N2,"\n" This should be done by create array opcode plus print array opcode. [1, 2, 3, 4, 5] The create array opcode takes "n" top of stack (or "n" of registers) and create an array out of it. Both opcodes are very popular and worth of their existence. I don't see further benefit of a single vararg print opcode. The print is an expensive opcode anyway. Hong
RE: Strings db
GNU does offer the gettext tools library for just such a purpose. I don't know how it will translate to the various platforms however, and it likely is a major overkill for what we are trying to do. http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose It might make sense to implement something like this now, rather than create our own system and find out it is insufficient down the road. Just a thought, Grant M.
Re: SV: Parrot multithreading?
> >then what about a win/win? we could make the event checking style a
> >compile time option.
>
> Odds are you'll get per-op event checking if you enable debugging, since
> the debugging oploop will really be a generic "check event every op" loop
> that happens to have the "pending debugging event" bit permanently set.
> Dunno whether we want to force this at compile time or consider some way to
> set it at runtime. I'd really like to be able to switch oploops
> dynamically, but I can't think of a good way to do that efficiently.
>
long-jump!!!
runops(bla bla){
setjmp(..);
switch(flags) {
fast_runops(bla bla);
debug_runops(bla bla);
trace_runops(bla bla);
conservative_runops(bla bla);
thread_safe_runops(bla bla);
}
}
AUTO_OP sys_opcode_change_runops {
bla bla
set run-flags..
longjmp(..)
}
In C++ I'd say throw the appropriate exception, but this is close enough.
This would work well for fake-threads too, since each thread might have a
different desired main-loop. You'd have to do something like this if you
transitioned bewteen non-threaded and threaded anyway.
-Michael
Re: SV: Parrot multithreading?
> Odds are you'll get per-op event checking if you enable debugging, since
> the debugging oploop will really be a generic "check event every op" loop
> that happens to have the "pending debugging event" bit permanently set.
> Dunno whether we want to force this at compile time or consider some way to
> set it at runtime. I'd really like to be able to switch oploops
> dynamically, but I can't think of a good way to do that efficiently.
If you're looking to dynamically "insert statis checks every op", then
that sounds like picking a different runops function. We've already got a
trace varient. We could farm out a couple of these and have execution
flags specify which one to use. If you wanted every 5'th op to check
flags, you could trivially do:
while(code) {
DO_OP(..)
if(code) DO_OP(..)
if(code) DO_OP(..)
if(code) DO_OP(..)
if(code) DO_OP(..)
CHECK_EVENTS(interp)
}
The inner loop is a little bigger, but aside from cache-issues, has no
performance overhead. This would prevent having to interleave check-ops
everywhere (more importantly, it would reduce the complexity of the
compiler which would have to garuntee the injection of check-events inside
all code-paths (especially for complex flow-control like "last FOO".
You could use asynchronous timers to set various flags in the check-events
section (such as gc every so-often). Of course this requires using a more
sophisticated "alarm/sleep" control system than the simple wrapper around
alarm/sleep and $SIG{X}, etc.
Other methods might be whenever a dynamic variable referencee is
reassigned / derefed, an event flag is set to Q the gc, etc.
-Michael
Re: Parrot coredumps on Solaris 8
At 10:46 AM 9/24/2001 -0400, Michael Maraist wrote: >Why aren't we just using the perl5 memory manager? Because it's not what I ultimately want, or what Parrot ultimately needs. That and it would've been more work than it was worth when Parrot was first set up. (We don't *do* much, so I didn't see the harm in leaking if the leaks are caused by behind-the-scenes stuff) It, or a variant on it, might make a good interim allocator. If someone wants to go for it, I'm fine with that. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: SV: Parrot multithreading?
At 09:56 AM 9/24/2001 -0400, Uri Guttman wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > >> do we always emit one in > >> loops? > > DS> At least one per statement, probably more for things like regexes. > > >> what about complex conditional code? i don't think there is an > >> easy way to guarantee events are checked with inserted op codes. doing > >> it in the op loop is better for this. > > DS> I'd agree in some cases, but I don't think it'll be a big problem > DS> to get things emitted properly. (It's funny we're arguing exactly > DS> opposite positions than we had not too long ago... :) > >true! Funny old world, huh? :) >then what about a win/win? we could make the event checking style a >compile time option. Odds are you'll get per-op event checking if you enable debugging, since the debugging oploop will really be a generic "check event every op" loop that happens to have the "pending debugging event" bit permanently set. Dunno whether we want to force this at compile time or consider some way to set it at runtime. I'd really like to be able to switch oploops dynamically, but I can't think of a good way to do that efficiently. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Suggestion: register liveness information
At 12:36 AM 9/25/2001 +1000, Andrew J Bromage wrote: >G'day all. > >On Mon, Sep 24, 2001 at 10:27:24AM -0400, Michael Maraist wrote: > > > Does it have to be in the instruction stream to be useful? > >No, of course not. I said "instruction" because that's how I saw it >implemented last, but that was in a compiler backend, not in a virtual >machine specification. > >"Annotation" would be more accurate. This stuff's all slated to be in what the parser hands to the compiler, and what the compiler hands to the optimizer. It'll be in the bytecode file on-disk, just not in the instruction stream itself. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Curious about Parrot + Closures
At 09:02 AM 9/24/2001 -0500, David M. Lloyd wrote: >I'm just curious, is there a plan for how closures will work in Parrot? When we create a PMC for a subroutine, it'll grab onto the scratchpad that's in effect, and that scratchpad has a link to its parent, and so on. When the last pointer to a scratchpad goes away then everything in it gets cleaned up the next GC run. We may get a little fancier depending on what's in the closure--we don't need unreferenced variables if there's no eval in the closure, for example. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Using int32_t instead of IV for code
Dan Sugalski writes: > Speaking from on high here, bytecode is strictly identifiable as to its > characteristics. It will be as portable as a platform implementer wants it > to be. The only 'required' types of bytecode that need to be read are > 32-bit integer (both big and little endian) with 8-byte IEEE floats for FP > constants. Everything else is optional, though if the code's small I fully > expect we'll ship with a full complement of translators. Here's what I want. In the real world, I want the reference C implementation of Parrot to read and write a bytecode that will be portable to other people using the reference C implementation. If someone wants to implement a faster, smaller, non-portable bytecode, then that's cool. But I really really really want the default out of the box to be able to let us distribute compiled Perl programs. Is that how the system you're describing will work? (Apologies if it's blindingly obvious, it's not so to thicky old me) Nat
RE: Strings db
At 09:42 AM 9/24/2001 -0700, Wizard wrote: >Some questions about implementation: >which scenarios?: >1.> external text-file strings (name=value?) chosen at run-time >2.> Parrot build-time embedded strings (language chosen at configure) > >Do we want to break the messages into sets, such that <256 is 'fatal', 256 >to 511 is 'warning', 512 to 767 is 'informational', and 768 to 1023 is 'UI'? I'd rather choose low bits for the general status. (And my tendency is to snag the VMS standard, as its as good as anything else) As for the rest, it really beats me--I have close to zero experience in the area, so I'm not comfortable making a declaration. I'd assume the best thing to do is hand off an error code and parameters, and the I18N stuff looks up the appropriate error message from the local catalog (probably set at perl compile time or via an ENV entry or system locale or something) and spits out a formatted error. I'd love it if someone with more I18N experience than me would draft up a proposal, even if it's "We should do what ZZZ does, which is..." Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What should and shouldn't get documented?
At 01:16 PM 9/24/2001 +0100, Dave Mitchell wrote: >Dan Sugalski <[EMAIL PROTECTED]> wrote: > > Subject: What should and shouldn't get documented? > > > > I see there's a lot of embedded documentation going into the core, and > > that's a good thing. That brings up a question, though--what exactly > should > > we document, and where should it be seen? > > > > For an example, the opcode functions should *never* be used outside the > > interpreter core itself, but documenting them's still a good thing. > > > > Maybe we need a way to tag the type of documentation for each > function--the > > module it belongs to and how exposed it should be, or something. > >Well, we already tag the api it belongs to. It stikes me that exposure >can be one or more of: > >1. internal to the subsystem >2. usable by the whole core >3. usable by extensions >4. usable by embedders > >I'm not sure if (3) and (4) need to be distingished. Also, I'm not sure >whether (2) needs to be further subdivided, eg into parrot and perl/python/... 3 and 4 need distinguishing, but there will be *very* few routines in 4. If we have more than 8, I think we have too many. (Though I may change my mind at some point) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC: Bytecode file format
At 12:24 PM 9/24/2001 +0200, Bart Lateur wrote: >On Fri, 14 Sep 2001 16:42:21 -0400, Dan Sugalski wrote: > > >Nope. At the very least, a bytecode file needs to start with: > > > >8-byte word:endianness (magic value 0x123456789abcdef0) > >byte: word size > >byte[7]:empty > >word: major version > >word: minor version > > > >Where all word values are as big as the word size says they are. > >I'm just wondering... Since we need a conversion tool for reading >non-native bytecode formats anyway, and since all bytecodes will be >limited to 32 bit... could it not be that on current day processors, >reading and converting of 32 bit bytecodes to 64 bit, if that is the >native format, could actually be faster than reading in 64 bit bytecodes >with no conversion? I would think that CPU cycles are cheap when >compared to disk I/O. Sure, but don't forget that if we're mmapping in we may well never map in good chunks of the stuff on disk. Also the mapping can be done asynchronously, with the system faulting in several pages simultaneously and letting us go when the first page is in. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Using int32_t instead of IV for code
At 12:17 AM 9/24/2001 -0400, Michael Maraist wrote: >Dan wrote: > > For bytecode, it's not a big problem, certainly not one I'm worried about. > > Machines that want 64-bit ints have, likely speaking, more than enough > > memory to handle the larger bytecode. > > >That's not the problem. The problem is protability of the byte-code. >I've heard various discussions about byte-code-compiling. One of which >was that it is not considered cosher to let a program compile code and >write into a "/usr/local/scripts" directory or any such thing. Many >companies want to be able to distribute "byte-commpiled" code (such as >with python). Portability is why we tag the bytecode files with the size and endianness of things, along with version numbers. That way the interpreter can either handle things as appropriate or pitch a fit. >Though I don't know what the powers on high want, are we saying here and >now that the byte-code is strickly non-portable? Speaking from on high here, bytecode is strictly identifiable as to its characteristics. It will be as portable as a platform implementer wants it to be. The only 'required' types of bytecode that need to be read are 32-bit integer (both big and little endian) with 8-byte IEEE floats for FP constants. Everything else is optional, though if the code's small I fully expect we'll ship with a full complement of translators. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] dec_n_nc fix
Leon -- > Can someone apply this please? I just applied this patch a few minutes ago... 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: Wow.
At 10:36 AM 9/24/2001 -0400, Michael Maraist wrote:
>On Mon, 24 Sep 2001, Buggs wrote:
>
> > On Monday 24 September 2001 03:27, Dan Sugalski wrote:
> > > At 01:47 AM 9/24/2001 +0100, Simon Cozens wrote:
> > > >http://astray.com/mandlebrot.pasm
> > > >
> > > >Leon, you're a sick, sick man.
> > >
> > > Okay, I think that means we need to weld in bitmap handling opcodes into
> > > the interpreter. :)
>
>Woohoo.. How many times have we seen code like this:
>sub log2($)
>{
> my $val = shift;
> my $idx = 0;
> $idx++ while $val >>=1;
> return $idx;
>}
>
>I'd love to see a full compliment of bit-code like the 386 had (oh the
>days). :) That includes get_index_of_left_most_bit (alias log2_i_i),
>get_index_of_first_[one|zero] (which is useful for searching bitmaps).
>count_ones. I'd have to go get my old [345]86 assembly book for the rest.
>This is useful stuff people. :) Heck, on x86 platforms would could use
>#ifdefs and assembly. :) Tell me this wouldn't be cool?
This would be cool, and I'll raise you the VAX bit handling code on top of it.
However...
I was talking about a different instance of "bitmap". More like:
newbm P3, (640, 480, 24, 8) # Make a 640X480, 24 bit image
# with 8 bits of alpha
drawline P3, (100, 100, 200, 200, green) # Draw a green line from
# 100, 100 to 200,200
and so on.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Wow.
All -- > > Also looks like there are some bugs in the num register handling that need > > fixing. :( > > > Just forgotten or is there more to it? I just fixed the dec_n_n opcode, and fixed the assembler's handling of constants like '0.1', which were being routed through oct(). 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: Sparc/Linux results
On Mon, 24 Sep 2001, Simon Cozens wrote: > On Mon, Sep 24, 2001 at 09:16:10AM -0400, Andy Dougherty wrote: > > I'm afraid I'll have very little time this week to track this down myself. > > It's OK; I've found myself a SPARC machine and I'm looking into it. Thank you. Some perspective for others on the list (Simon already knows all this and much more, and has made great strides): Internally, there's still signficiant confusion about integral types. In particular, on a machine where 32-bits is the 'natural' size for an integer, it is perfectly reasonable to still want to use 64-bit IVs to do your work. On such a system, you may or may not decide to use 32-bit opcodes. Thus IV and opcode_t need to be separate types. We shouldn't assume sizeof(IV) and sizeof(opcode_t) are the same. Toruture-testing now with various variations is a good way to uncover various erroneous assumptions before they get too deeply engrained. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Curious about Parrot + Closures
> I'm just curious, is there a plan for how closures will work in Parrot? I > think that closures are one of the coolest Perl 5 features around (despite > their memory leak issues :-), and I'd hate to see them go away. I doubt that there's any limitation. In Java, all they had to do was supply a reference to the enclosing object and compile a new class which used some local and some "friend member vars". We're obviously not fundamentally OO here so this approach won't work. We still haven't seen thow PMVs (or whatever they're called). They contain a structure. That's probably perfect for the reproduction of perl5 CV's which I believe contained (among other things) the "locals" which included references to closure values. In short. Fear not. -Michael
Re: Parrot coredumps on Solaris 8
> DS> At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote: > > >> >Horribly wasteful of memory, definitely, and the final allocation system > >> >will do things better, but this is OK to start. > >> > >> So to stop it waste memory, subtract 1 first and add it again later. > > DS> Nah, it'll still waste memory. It can't not, because of the way it > DS> works. It has to ask for a big gob of memory and ignore bits to > DS> make sure it gets the alignment right. This particular > DS> implementation's not all that efficient I'm sure, but it'll get > DS> ripped out and replaced when we have a real memory management > DS> system. > > what about a binary type allocation system? > > we have multiple allocation structures in an array with each one > allocating the next size up binary size. so the lowest level does say 32 > bytes (or whatever our smallest granularity is). the highest level could > be in the multi-megabytes or larger. when a size is requested it go to > that size queue and if there is a free block on its list, it gets it. if > no block exists, it requests from a larger size and will break it > down. now, if you allocate with malloc and it is not on the proper, > boundary the preceding ram is broekn into smaller parts and put onthose > queues. so no (or little) ram is wasted. all blocks are allocated on > proper boundaries and you can do binary coallescing during (incremental) > GC. > > a first request of a small block may allocate 32 (or some other 2**N) of > them in a large chunk. that large blocks are managed by just slice off > the leading chunk and moving a pointer so that is very fast. when the > block is gone and the queue is empty, a new larger block is allocated. > > once the queues get populated some, it will be very fast. > > lemme try to whip out something like this soon and see what happens. or > does anyone else want to hack it with or without me? > > uri Why aren't we just using the perl5 memory manager? Cut-and-paste right? It used 2k page alignments for the most part. That should account for most of our alignment needs. Actually I think it put the size as the first several bytes. But this could be rectified by "spilling into the predecessor". Namely All allocations start at 2K but spill back 4 or so bytes. This means that free chains have to be <=4 above the grain. If you use pow2 based allocation instead of physical size-of-data, then you can assume that it's 2^idx-4 when allocating. It's more wasteful of memory, but with things like 2k-4B pages and clustered sub 2K allocations, it's very efficient. Until we get to that point, our current hack of a memory allocator is fine for any applications we're capable of writing with this boot-strap API. -Michael
Re: Suggestion: register liveness information
G'day all. On Mon, Sep 24, 2001 at 10:27:24AM -0400, Michael Maraist wrote: > Does it have to be in the instruction stream to be useful? No, of course not. I said "instruction" because that's how I saw it implemented last, but that was in a compiler backend, not in a virtual machine specification. "Annotation" would be more accurate. Cheers, Andrew Bromage
Re: Wow.
On Mon, 24 Sep 2001, Buggs wrote:
> On Monday 24 September 2001 03:27, Dan Sugalski wrote:
> > At 01:47 AM 9/24/2001 +0100, Simon Cozens wrote:
> > >http://astray.com/mandlebrot.pasm
> > >
> > >Leon, you're a sick, sick man.
> >
> > Okay, I think that means we need to weld in bitmap handling opcodes into
> > the interpreter. :)
Woohoo.. How many times have we seen code like this:
sub log2($)
{
my $val = shift;
my $idx = 0;
$idx++ while $val >>=1;
return $idx;
}
I'd love to see a full compliment of bit-code like the 386 had (oh the
days). :) That includes get_index_of_left_most_bit (alias log2_i_i),
get_index_of_first_[one|zero] (which is useful for searching bitmaps).
count_ones. I'd have to go get my old [345]86 assembly book for the rest.
This is useful stuff people. :) Heck, on x86 platforms would could use
#ifdefs and assembly. :) Tell me this wouldn't be cool?
-Michael
Re: Suggestion: register liveness information
> I have a suggestion for allowing parrot implementations to execute > code more efficiently. Add an "instruction" or other annotation which > denotes what registers are "live" at some point in the code. The Does it have to be in the instruction stream to be useful? Why not just be part of the constants /fixup segment. This way non-JIT execution won't require wasted op-execution (which we're devilishly trying to pre-maturely optimize :). You could profile things via perl6-code attributes which give clues to an optimizer or JIT (such as frequency of use, etc). In any case, I can't imagine that a JIT compiler is expected to quickly execute. What you have suggested is summary code, which can be determined at JIT compilation time. I'm not convinced that the waste of CPU for invocation of op-codes that aren't used in non-JIT form (which is the case when you know you're only going to run this once) is justified for such simplistic information. However, a similar idea of "live-registers" exists on newer CPU-architecture. Namely mapping how many registers need to survive the subroutine call. The block, in turn, specifies how many it will use within it's block. The CPU then frees non-maintained registers and allocates just enough. The IA64 does something along these lines. Here, however, we're not starved for register space; We're utilizing multiple stack-streams. The beginning of a block simply allocates new stack space on whichever stacks it requires. The only optimization in this manner is to have the caller specify if it has used less than the full compliment (or 32 or so), which would allow the potential stack-allocation to save a block of 8, 16 or 24 registers (useful when only 8 are used.. This also rewards compiler optimizatios which reuse registers; which has cache rewards as well). Namely: general-op general-op keep_int_regs %16 jsr _foo_func general-op _foo_func: push_int_regs // only shifts reg-stack by 16 (properly handles over-flow) push_num_regs // shifts a full 32 general-ops ... pop_num_regs // shifts back 32 pop_int_regs // remembered to shift back only 16 ret Unfortunately this trades off memory savings for extra CPU overhead. You have to maintain a seperate "shift-stack" which says how much to shift each time you do a push/pop. The current shift-value is set via the new op-code "keep_x_regs" which also introduces over-head. I personally would like to see smaller subroutines and more of them, but I don't know that we're really going to be wasting a whole hell of a lot of stack-space. At least not enough to be worth the CPU-overhead. In general, if the hint-information is useful for non-JIT execution as well, then I'd recommend it, but I'm not seeing this particular point as being worth the cost. -Michael
Re: [PATCH] dec_n_nc fix
Leon Brocard sent the following bits through the ether:
> Attached is a patch to actually make dec_n_nc do what it should.
> (Also included is a minor doc patch which I've previously sent but
> which hasn't yet been applied ;-)
Can someone apply this please?
Leon
--
Leon Brocard.http://www.astray.com/
Nanoware...http://www.nanoware.org/
... If I knew what I was doing... I'd be dangerous...
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.22
diff -u -u -r1.22 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/21 09:25:39 1.22
+++ basic_opcodes.ops 2001/09/24 14:26:15
@@ -341,7 +341,7 @@
/* DEC Nx, nnn */
AUTO_OP dec_n_nc {
- NUM_REG(P1) += P2;
+ NUM_REG(P1) -= P2;
}
/* ITON Nx, Iy */
Re: Where is Parrot/Types.pm
On Mon, Sep 24, 2001 at 09:16:34AM -0500, Gibbs Tanton - tgibbs wrote: > assemble.pl dies saying that it can't find Parrot/Types.pm in @INC. I've > done a cvs update -dP and it doesn't get added...what happend to this file? You need to rerun Configure. -- [Bastille Linux] Of course, if we consider the relative ease with which the historical Bastille was taken by a bunch of peasants, maybe there's not much difference between the two. - Jonathan Byrne.
Re: Floating Points and 0.0.2 release
On Mon, Sep 24, 2001 at 03:14:19PM +0100, Leon Brocard wrote: > While we're at it: Simon, what do we need to have ready before > we release the next version? OK, here's the release roadmap for the near future: 0.0.2 will be released when all tests pass on the core platforms. 0.0.3 will be released when we have scalar PMCs implemented. 0.0.4 will be released when we have hash and list PMCs implemented. 0.1.0 will be released when we have subroutines. -- The Messiah will come. There will be a resurrection of the dead -- all the things that Jews believed in before they got so damn sophisticated. - Rabbi Meir Kahane
Where is Parrot/Types.pm
assemble.pl dies saying that it can't find Parrot/Types.pm in @INC. I've done a cvs update -dP and it doesn't get added...what happend to this file? Tanton
Re: Floating Points and 0.0.2 release
Gibbs Tanton - tgibbs sent the following bits through the ether: > For the 0.0.2 release While we're at it: Simon, what do we need to have ready before we release the next version? Leon -- Leon Brocard.http://www.astray.com/ Nanoware...http://www.nanoware.org/ ... DIODE: What happens to people who don't die young
Re: Floating Points and 0.0.2 release
On Mon, Sep 24, 2001 at 09:03:39AM -0500, Gibbs Tanton - tgibbs wrote: > For the 0.0.2 release, do we want floating point constants in the constant > table, or do we want to change the code to work with inline constants...I > think we can do a simple memcpy to make the inline constants work (instead > of casting and assigning.) They're going to go in the constant table. I'll sit down and rewrite the constant table code sometime soon (hopefully today) because it needs to know about i) what *type* of constant (string, NV, PMC) each constant is, and ii) how to align constants so that the NVs can be read off. Simon -- "Language shapes the way we think, and determines what we can think about." -- B. L. Whorf
Floating Points and 0.0.2 release
For the 0.0.2 release, do we want floating point constants in the constant table, or do we want to change the code to work with inline constants...I think we can do a simple memcpy to make the inline constants work (instead of casting and assigning.) Tanton
Curious about Parrot + Closures
I'm just curious, is there a plan for how closures will work in Parrot? I think that closures are one of the coolest Perl 5 features around (despite their memory leak issues :-), and I'd hate to see them go away. - D <[EMAIL PROTECTED]>
Re: Using int32_t instead of IV for code
> >>We're talking bytecode. That will indeed be a case of "huge arrays of > >>tightly packed integers". > > > >For bytecode, it's not a big problem, certainly not one I'm worried about. > >Machines that want 64-bit ints have, likely speaking, more than enough > >memory to handle the larger bytecode. > > I'm more worried about the cache. For 32 bit bytecodes, the same program > will be only half the size than for 64 bit. Or: you can fit a twice as > large program in the cache, or two of them (for multitasking). That will > mean a speed-up, and likely a vast one for programs with sizes close > enough the cache size. > If this is the case ten why are we using 32bit register identifiers? Obviously it makes code easier to write. But at some point are we going to compress the byte-code? Along with a previous email that suggested that byte-code is only going to be valid on a given machine with a pre-compiled parrot / perl6 core, the bytecode won't need to worry about the number of registers, etc. Most VM architectures use 8 or 16 bits for the op-code (including the register map). Here are the pros and cons as I see them: Cons: o 8bit op-codes dramatically limits number of "macro-ops" or advanced ops o 16bit op-codes have potentially screwy alignment issues. o 4bit register addresses have definatly screwy alignment issues (requires masking to extract values which takes more cpu-time) o sub-32-bit ops might be slower on non x86 architecture (since more and more are 64 or 32bit only; and require special ops to munch sub-32bit data; namely alpha) o If the constant-table index was chosen 16bits, we'd limit the number of entries to 64K per code-segment (But who would ever use more than this in p-code ;) o If the address was limited to 16 bits, we'd have code-size limitation of som 4K ops per code-segment. o allowing p-code-size to be an issue dramatically increases the number of op-codes earlier on in development (write this as a bug-enchancement instead?). Namely we have inc16_i8_ic8, inc16_i8_ic16, inc16_i8_ic32, add16_i8_i8_ic16, add16_i8_i8_ic32. o larger number of op-codes means more c-code, which means a trade-off between D-cache (for byte-code) and C-cache (for extra c-code). Pros: o dramaticaly compressed op-code size (from 128bits on average to 32,48,64). Saves both on disk space and cache-space - tighter inner-loops. o Potentially more highly optimized c-code; 16bit adds are somewhat faster on some architectures - do what's needed when it's needed. 64bit archs will upcast everythign anyway. o If we eventually determined a max-code-length (of like 64bits after alignment), then we could just make all code that big. This would dramatically reduce c-code over-head (no offset = DEFAULT_SIZE; offset += rel_address; return offset; .. code = offset;). This would additionally reduce the risk of jumping into the middle of an op-code. Heck we could do this now; simply profile all op-codes to determine the max code-size, then pad all op-codes to that size. Given that we're not into dynamic-opcodes, and most everything is being pushed into the constants area, I don't see much danger in it. Food for thought.. -Michael
Re: SV: Parrot multithreading?
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: >> do we always emit one in >> loops? DS> At least one per statement, probably more for things like regexes. >> what about complex conditional code? i don't think there is an >> easy way to guarantee events are checked with inserted op codes. doing >> it in the op loop is better for this. DS> I'd agree in some cases, but I don't think it'll be a big problem DS> to get things emitted properly. (It's funny we're arguing exactly DS> opposite positions than we had not too long ago... :) true! then what about a win/win? we could make the event checking style a compile time option. an event pragma will set it to emit op codes, or check in the op loop or do no checking in the loop but have an main event loop. we need 2 or 3 variant op loops for that (very minor variants) and some minor compile time conditions. i just like to be able to offer control to the coder. we can make the emit event checks version the default as that will satisfy the most users with the least trouble. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
Re: Parrot coredumps on Solaris 8
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote: >> >Horribly wasteful of memory, definitely, and the final allocation system >> >will do things better, but this is OK to start. >> >> So to stop it waste memory, subtract 1 first and add it again later. DS> Nah, it'll still waste memory. It can't not, because of the way it DS> works. It has to ask for a big gob of memory and ignore bits to DS> make sure it gets the alignment right. This particular DS> implementation's not all that efficient I'm sure, but it'll get DS> ripped out and replaced when we have a real memory management DS> system. what about a binary type allocation system? we have multiple allocation structures in an array with each one allocating the next size up binary size. so the lowest level does say 32 bytes (or whatever our smallest granularity is). the highest level could be in the multi-megabytes or larger. when a size is requested it go to that size queue and if there is a free block on its list, it gets it. if no block exists, it requests from a larger size and will break it down. now, if you allocate with malloc and it is not on the proper, boundary the preceding ram is broekn into smaller parts and put onthose queues. so no (or little) ram is wasted. all blocks are allocated on proper boundaries and you can do binary coallescing during (incremental) GC. a first request of a small block may allocate 32 (or some other 2**N) of them in a large chunk. that large blocks are managed by just slice off the leading chunk and moving a pointer so that is very fast. when the block is gone and the queue is empty, a new larger block is allocated. once the queues get populated some, it will be very fast. lemme try to whip out something like this soon and see what happens. or does anyone else want to hack it with or without me? uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
RE: Strings db
Some questions about implementation: which scenarios?: 1.> external text-file strings (name=value?) chosen at run-time 2.> Parrot build-time embedded strings (language chosen at configure) Do we want to break the messages into sets, such that <256 is 'fatal', 256 to 511 is 'warning', 512 to 767 is 'informational', and 768 to 1023 is 'UI'? I remember somewhere where each user could specify their list of preferred languages in descending order (i.e., "en; fr; de; ..."), and the application would choose based upon available string files (a .parrc file?), defaulting back to the build-time language. Is this something that makes sense at this level, or should we just ask the user to specify an ENV variable? Is there a better way? Also, do we want to embed sprintf formatting in the strings, or should that be appended data? Perhaps some standardization of all error strings to be something on the order of: void perror(int error_id, char *val_1_name, char *val_1, \ char *val_2_name, char *val_2, ... ) which would print to stderr like so: error_id: (char *)string_lookup(error_id)\n *val_1_name: *val_1\n *val_2_name: *val_2\n ... make sense? Grant M.
Re: Sparc/Linux results
On Mon, Sep 24, 2001 at 09:16:10AM -0400, Andy Dougherty wrote: > I'm afraid I'll have very little time this week to track this down myself. It's OK; I've found myself a SPARC machine and I'm looking into it. -- Calm down, it's *only* ones and zeroes.
Re: Sparc/Linux results
On Fri, 21 Sep 2001, Andy Dougherty wrote:
> Apropos, here's what I get on Debian Sparc/Linux (my default perl there
> has iv='long long', so that's what we get here too). Note that nearly
> everything fails.
Ok, I've done cvs update and things are ever so slightly better. On
Friday, I got
> Failed 4/5 test scripts, 20.00% okay. 20/74 subtests failed, 72.97% okay.
> Failed TestStat Wstat Total Fail Failed List of Failed
> ---
> t/op/basic.t 1 256 21 50.00% 1
> t/op/integer.t 11 281626 11 42.31% 1-7 21-24
> t/op/number.t 7 1792237 30.43% 7 9 11 13 15 17 23
> t/op/string.t 1 256 51 20.00% 2
> 4 subtests skipped.
> make: *** [test] Error 29
Today, I first have to apply the following hack/incorrect patch:
(Otherwise we fail the bytecode.c:check_magic() function).
--- Configure.plSun Sep 23 10:50:48 2001
+++ Configure.pl.quad Mon Sep 24 09:00:42 2001
@@ -158,7 +158,7 @@
}
elsif ($c{ivsize} == 8) {
$c{packtype_i} = 'q';
-$c{packtype_op} = 'l';
+$c{packtype_op} = 'q'; # Still wrong -- assumes iv == opcode_t.
}
$c{packtype_n} = 'd';
Then, I get
Failed 4/5 test scripts, 20.00% okay. 14/74 subtests failed, 81.08% okay.
Failed TestStat Wstat Total Fail Failed List of Failed
---
t/op/basic.t 1 256 21 50.00% 1
t/op/integer.t 11 281626 11 42.31% 1-7 21-24
t/op/number.t 1 256231 4.35% 23
t/op/string.t 1 256 51 20.00% 2
4 subtests skipped.
make: *** [test] Error 29
I'm afraid I'll have very little time this week to track this down myself.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: What should and shouldn't get documented?
I wrote: > Should we go the full hog and make the /*=for api ... */ bit in the > src field subsume any info we currently append to embed.pl etc in Perl 5? s/field/file/
Re: What should and shouldn't get documented?
Dan Sugalski <[EMAIL PROTECTED]> wrote: > Subject: What should and shouldn't get documented? > > I see there's a lot of embedded documentation going into the core, and > that's a good thing. That brings up a question, though--what exactly should > we document, and where should it be seen? > > For an example, the opcode functions should *never* be used outside the > interpreter core itself, but documenting them's still a good thing. > > Maybe we need a way to tag the type of documentation for each function--the > module it belongs to and how exposed it should be, or something. Well, we already tag the api it belongs to. It stikes me that exposure can be one or more of: 1. internal to the subsystem 2. usable by the whole core 3. usable by extensions 4. usable by embedders I'm not sure if (3) and (4) need to be distingished. Also, I'm not sure whether (2) needs to be further subdivided, eg into parrot and perl/python/... We could have some flag letters following the API name, eg /*=for api string IC - exposed internally to itself (I) and to the core (C). Something exposed to extensions need not necessarily be I or C. The same flags could also be used for auto-header generation. Should we go the full hog and make the /*=for api ... */ bit in the src field subsume any info we currently append to embed.pl etc in Perl 5?
Re: Wow.
On Monday 24 September 2001 03:27, Dan Sugalski wrote:
> At 01:47 AM 9/24/2001 +0100, Simon Cozens wrote:
> >http://astray.com/mandlebrot.pasm
> >
> >Leon, you're a sick, sick man.
>
> Okay, I think that means we need to weld in bitmap handling opcodes into
> the interpreter. :)
>
> Also looks like there are some bugs in the num register handling that need
> fixing. :(
Just forgotten or is there more to it?
Buggs
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.22
diff -u -3 -p -r1.22 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/21 09:25:39 1.22
+++ basic_opcodes.ops 2001/09/24 10:22:56
@@ -693,3 +693,7 @@ AUTO_OP shr_i_ic {
AUTO_OP xor_i {
INT_REG(P1) = INT_REG(P2) ^ INT_REG(P3);
}
+/* SET Nx, Nx */
+AUTO_OP set_n {
+ NUM_REG(P1) = NUM_REG(P2);
+}
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.21
diff -u -3 -p -r1.21 opcode_table
--- opcode_table2001/09/19 22:57:15 1.21
+++ opcode_table2001/09/24 10:22:56
@@ -44,6 +44,7 @@ dec_i_ic 2 I i
# NUM ops
set_n_nc 2 N n
+set_n 2 N N
add_n 3 N N N
sub_n 3 N N N
mul_n 3 N N N
Re: RFC: Bytecode file format
On Fri, 14 Sep 2001 16:42:21 -0400, Dan Sugalski wrote: >Nope. At the very least, a bytecode file needs to start with: > >8-byte word:endianness (magic value 0x123456789abcdef0) >byte: word size >byte[7]:empty >word: major version >word: minor version > >Where all word values are as big as the word size says they are. I'm just wondering... Since we need a conversion tool for reading non-native bytecode formats anyway, and since all bytecodes will be limited to 32 bit... could it not be that on current day processors, reading and converting of 32 bit bytecodes to 64 bit, if that is the native format, could actually be faster than reading in 64 bit bytecodes with no conversion? I would think that CPU cycles are cheap when compared to disk I/O. I can't test myself, I don't have that kind of machine. -- Bart.
Re: [PATCH] Fix IRIX64 warnings
On Sun, Sep 23, 2001 at 10:05:20PM -0400, Steven W McDougall wrote: > This patch makes them go away. And it doesn't appear to break anything else in the process. Thanks, applied! Just out of interest, what are the tests looking like on IRIX? > -opcode_t *(*(*opcode_funcs)[2048])(); /* Opcode */ > - /* function table */ > -STRING_FUNCS *(*(*string_funcs)[64])(); /* String function table */ > +opcode_t *(**opcode_funcs)(); /* Opcode function table */ > +STRING_FUNCS *(**string_funcs)(); /* String function table */ I'm a little unsure about this - where have those array declarations gone and why? -- Why do programmers get Halloween and Christmas mixed up? Because OCT(31) == DEC(25)
Re: what is the current status...
On Sun, Sep 23, 2001 at 06:59:48PM -0700, Dave Storrs wrote: > I.e., what is fair game to be worked on * Documentation * Tests * Portability fixes > and what is a "hold off for now?" * Everything else -- I see ADA as a larger threat than communism at this point in time -- Ted Holden
Re: Suggestion: register liveness information
Andrew J Bromage sent the following bits through the ether: > What do you all think? Leon mentioned control flow graphs a few days > ago, but I think that live value information is more generally useful > to optimising interpreters and JIT compilers. I guess it depends what level you want to be able to do this at. My CFG stuff is intended to eventually move on to liveliness so as to optimise badly-generated bycode (from naive compilers, or lazy humans). I'm relearning all this as I haven't used it much since uni, but it's possible to gather all this information from the bytecode. I'd prefer to have code which does real liveliness calculations and can do real optimisations before we start talking about adding more opcodes ;-) Leon -- Leon Brocard.http://www.astray.com/ Nanoware...http://www.nanoware.org/ ... C program run. C program crash. C programmer quit
Suggestion: register liveness information
G'day all.
I have a suggestion for allowing parrot implementations to execute
code more efficiently. Add an "instruction" or other annotation which
denotes what registers are "live" at some point in the code. The
intended usage is that compilers which wish to generate this
information generate such an annotation at the end of every basic block
stating which registers hold data that may be reused in a subsequent
basic block.
Motivation
Many compiler optimisations require "data flow" information. However
I'm not talking about "high level" optimisation such as those which
restructure the control flow graph. I'm talking about the kind of
information that you need to make abstract machine code run on stock
hardware (e.g. instruction scheduling, register allocation etc).
Such information is "global", that is, it requires examination of
the whole compilation unit ("subroutine", "function", whatever) to
determine. However, optimising _implementations_ (as opposed to
optimising _compilers_) generally don't need to perform global
optimisations, only local ones (i.e. optimisations within a basic
block).
Many compilers generate this information during the normal process
of compilation, but subsequently throw it away when the output
listing is generated. This seems wasteful if consumers (e.g. JIT
compilers) could effectively use that information.
Why this information and not something else?
- It's simple to recover simple information. Most information that
a typical JIT compiler needs (e.g. register lifetimes for register
allocation, gen/kill sets for instruction scheduling) is easily
and quickly recoverable from only the live value information.
- It's straightforward to recover complex information. If you need,
say, static single assignment form or global def-use chains, you
can compute them using only the live value information and the
control flow graph. You still don't need expensive global
analysis.
- It's safe. While dataflow information is expensive to compute,
it's very cheap (one pass over the compilation unit) to check that
you have a "correct" solution, where "correct" here means
"conservative". If you need to know if the information is too
conservative, you can do that in only one more pass. So it's easy
to tell if the information can be trusted or not.
- It's simple. You don't need to store more information than a
simple optimising backend needs. You also don't need to work out
how to store complex data structures in the bytecode.
- It's compact. Parrot has 32 registers of each type. If you
represent the live value sets as bit vectors, you need only
one 32-bit word for each type plus opcode per basic block.
And, of course, supplying the information is optional. :-)
Note that the argument for live value information is weakened in JIT
compilers for the JVM because the JVM is a stack machine. Assuming
that all values on the stack are live is actually a pretty good (if
conservative) approximation to live value information given the way
that stack code is typically compiled.
What do you all think? Leon mentioned control flow graphs a few days
ago, but I think that live value information is more generally useful
to optimising interpreters and JIT compilers.
Cheers,
Andrew Bromage
