Re: Example assembler code (primes.pasm)
On Wed, Sep 19, 2001 at 02:49:58PM +0100, Leon Brocard wrote: Attached is a cute prime number printer. It strikes me that we need a central place to put these things - it'd really help people get stuck into the lowlevel stuff. It wouldn't hurt to throw it in as a test. Probably the most complicated test case we've got at the moment. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One If you see an animal with (-) 100 points and (+) 70 points, would you eat it? Hell no, and you should run for your life! --Alex Chiu, Immortality Guy
Re: niave question about Parrot::Opcode
On Wed, Sep 19, 2001 at 01:40:31PM -0400, Pat Eyler wrote:
I realize that the $count inside the if block shown masks the $count
declared outside the while loop, but (to me) this would be easier to
understand if the inner $count where changed to $numParams -- it is more
obvious on casual reading that $count and $count are two different
things. Am I missing something?
No, you aren't. That IS confusing.
2) It also appears that a second (older?) version of read_ops and an
associated pile of pod is still in the Opcode.pm file can this be
trimmed (removing about 80 lines from the file)?
Where on earth did that come from?
Patch attached to rename the second $count, and to remove the
duplicate code.
- Damien
Index: Parrot/Opcode.pm
===
RCS file: /home/perlcvs/parrot/Parrot/Opcode.pm,v
retrieving revision 1.6
diff -u -r1.6 Opcode.pm
--- Parrot/Opcode.pm2001/09/18 00:32:15 1.6
+++ Parrot/Opcode.pm2001/09/20 07:23:44
@@ -28,9 +28,9 @@
my($name, @params) = split /\s+/;
if (@params $params[0] =~ /^\d+$/) {
- my $count = shift @params;
+ my $nparams = shift @params;
die $file, line $.: opcode $name parameters don't match count\n
- if ($count != @params);
+ if ($nparams != @params);
}
warn $file, line $.: opcode $name redefined\n if $opcode{$name};
@@ -108,91 +108,5 @@
The fingerprint() function returns the MD5 signature (in hex) of the
opcode table.
-
-=cut
-package Parrot::Opcode;
-
-use strict;
-use Symbol;
-
-sub read_ops {
-my $file = @_ ? shift : opcode_table;
-
-my $fh = gensym;
-open $fh, $file or die $file: $!\n;
-
-my %opcode;
-my $count = 1;
-while ($fh) {
- s/#.*//;
- s/^\s+//;
- chomp;
- next unless $_;
-
- my($name, @params) = split /\s+/;
- if (@params $params[0] =~ /^\d+$/) {
- my $count = shift @params;
- die $file, line $.: opcode $name parameters don't match count\n
- if ($count != @params);
- }
-
- warn $file, line $.: opcode $name redefined\n if $opcode{$name};
-
- $opcode{$name}{ARGS} = @params;
- $opcode{$name}{TYPES} = \@params;
- $opcode{$name}{CODE} = ($name eq end) ? 0 : $count++;
- $opcode{$name}{FUNC} = Parrot_op_$name;
-
- my $num_i = () = grep {/i/} @params;
- my $num_n = () = grep {/n/} @params;
- $opcode{$name}{RETURN_OFFSET} = 1 + $num_i + $num_n * 2;
-}
-
-return %opcode;
-}
-
-1;
-
-
-__END__
-
-=head1 NAME
-
-Parrot::Opcode - Read opcode definitions
-
-=head1 SYNOPSIS
-
- use Parrot::Opcode;
-
- %opcodes = Parrot::Opcode::read_ops();
-
-=head1 DESCRIPTION
-
-The read_ops() function parses the Parrot opcode_table file, and
-returns the contents as a hash. The hash key is the opcode name;
-values are hashrefs containing the following fields:
-
-=over
-
-=item CODE
-
-The opcode number.
-
-=item ARGS
-
-The opcode argument count.
-
-=item TYPES
-
-The opcode argument types, as an arrayref.
-
-=item FUNC
-
-The name of the C function implementing this op.
-
-=back
-
-read_ops() takes an optional argument: the file to read the opcode table
-from.
=cut
Re: question about branching/returning
The internal do-op-loop runs until it sees a return value of zero from any op-codes. The RETURN statement within basic_opcodes.ops is really a keyword which gets parsed into an offset of the current PC counter based on the internally calculated size of the instruction (known at Configure time from opcode_table). Of course, this is based off my reverse engineering of existing code. I'm sure any of this is subject to change. As a note, another poster said that end is never executed which isn't currently true. -Michael Dave Storrs wrote: Ok, that was pretty much what I thought. But then what is the 'end' opcode for? It does a 'RETURN 0', which would increment the PC by 0 opcodes...which either counts as an infinite loop or a no-op, and we've already got a no-op op.
Re: Darwin - looking good
On Thu, Sep 20, 2001 at 12:42:13AM +0100, Robin Houston wrote: I only had one real problem with Parrot on Darwin, which really has nothing to do with Darwin at all. The first time I tried to make test I got a slew of errors about Test::More, so I diligently went to CPAN and downloaded the latest version. The latest version of the Test-More tarball should have blown up in your face with a big Don't use this, download Test-Simple instead! to prevent exactly this sort of thing from happening. For some reason that last version doesn't seem to have made it into modules/by-module/Test/, it's just sitting in my author directory. Sorry for the inconvenience, I'll go poke the CPAN folks. Are there any plans to remove the dependency of Parrot::Test on non-core modules? It's bound to be a stumbling block for quite a few people, surely? If not, I'll contribute a patch which makes the failure more graceful and informative. These actually are core, but not until 5.7.2. And we don't want to take a Great Leap Backward to Test.pm. For *exactly* such a contingency (I sound like an Acme saleman now) we have Test-SDK (remember the SDKs?) which includes new-enough versions of Test::More, Test::Simple, Test::Inline and Test::Harness in one handy, easy to install tarball for those of you that don't use the CPAN shell. As a third alternative, you can simply distribute Test::Simple/More (and even the new versions of Test::Harness) as part of parrot, same as you do Parrot::Test. That involves the least work for the test runner. I'd suggest creating a lib/ directory and moving Parrot/ into it now before you get a proliferation of individual Perl module directories. And change the Makefile to this: PERL = perl PERLRUN = $(PERL) -Ilib test: $(PERLRUN) t/harness and the other targets that use $(PERL) change to $(PERLRUN). I could do this myself. What's the best way to submit a bunch of file/directory moves? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One purl Hey, Schwern! THERE IS A HUGE GAZORGANSPLATTEDFARTMONGERING- LIGHTENINGBEASTASAURSOPOD BEHIND YOU! RUN, BEFORE IT GAFLUMMOXES YOUR INNARDLYBITS!
Re: Darwin - looking good
On Thu, Sep 20, 2001 at 04:00:02AM -0400, Michael G Schwern wrote: The latest version of the Test-More tarball should have blown up in your face with a big Don't use this, download Test-Simple instead! This is irrelevant in this case, because that's still a non-core module. These actually are core, but not until 5.7.2. Which means not until 5.6.2, which means we're stuffed *now*. That doesn't help much either. As a third alternative, you can simply distribute Test::Simple/More (and even the new versions of Test::Harness) as part of parrot You're just trying to take over the world now. -- And tomorrow will be like today, only more so. -- Isaiah 56:12, New Standard Version
Re: [PATCH] Changes to interpreter op table and simplified DO_OP
Oops; that'll teach me to submit things before a cvs update. The generate.pl I just sent is out-of-date with regards to CVS. Attached is an updated version. (I haven't seen my prior mail go through yet; I'm guessing this is the list being slow, but it might be a problem with my local mail system. Just in case, I'm sending this from a different machine. If this arrives without my prior message, that means my mail system is screwy. :) - Damien generate.pl
RE: [PATCH] changing IV to opcode_t!!
Brent Dax:
# I'll work on it later today.
Patch below sig. I don't know if (or even really think that) this will
apply cleanly--I haven't updated my CVS in a while--but I don't expect
this to go in until after 0.02. This is basically just to show you what
I'm thinking. Let me know if my thought process is flawed.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- ..\..\parrot-cvs\parrot\Configure.plTue Sep 18 11:32:06 2001
+++ Configure.plThu Sep 20 01:48:06 2001
@@ -62,6 +62,8 @@
my(%c)=(
iv = ($Config{ivtype}||'long'),
nv = ($Config{nvtype}||'double'),
+ ivsize = undef, #filled in later in
program
+ nvsize = undef, #ditto
cc = $Config{cc},
#ADD C COMPILER FLAGS HERE
ccflags = $Config{ccflags}. -I./include,
@@ -118,6 +120,17 @@
print END;
+Alright, I'm now gonna compile and run a little C program
+to figure some stuff out.
+END
+
+buildfile(test_c);
+system($c{cc} test.c $c{ccflags} -o test$c{exe}) and die Compilation
of test.c unsuccessful;
+@c{qw(ivsize nvsize)}=(`test$c{exe}` =~ m{(\d+)/(\d+)});
+unlink('test$c{exe}', 'test.c');
+
+print END;
+
Okay, that's finished. I'm now going to write your very
own Makefile, config.h, and Parrot::Config to disk.
END
--- ..\..\parrot-cvs\parrot\config_h.in Fri Sep 14 09:40:36 2001
+++ config_h.in Thu Sep 20 01:44:36 2001
@@ -6,8 +6,12 @@
#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
+
typedef ${iv} IV;
+#define ivsize ${ivsize}
+
typedef ${nv} NV;
+#define nvsize ${nvsize}
typedef struct _vtable VTABLE;
typedef void DPOINTER;
@@ -24,7 +28,6 @@
#define MASK_CHUNK_LOW_BITS 0xf000
-
${headers}
--- /dev/null Wed Dec 31 16:00:00 1969
+++ test_c.in Thu Sep 20 01:31:36 2001
@@ -0,0 +1,6 @@
+#include stdio.h
+
+int main(int argc, char **argv) {
+ printf(%d/%d, sizeof(${iv}), sizeof(${nv}));
+ return 0;
+}
Re: [PATCH] changing IV to opcode_t!!
On Thu, Sep 20, 2001 at 01:50:04AM -0700, Brent Dax wrote:
+int main(int argc, char **argv) {
+ printf(%d/%d, sizeof(${iv}), sizeof(${nv}));
+ return 0;
+}
$Config{ivsize} not good enough for ya, then? :)
--
You are in a maze of little twisting passages, all alike.
Re: Complete failure on Linux/PowerPC with 64bit ints.
On Thu, Sep 20, 2001 at 04:30:34AM -0400, Michael G Schwern wrote: And all of the tests fail with This isn't Parrot bytecode! That's what I like to see. Thanks. -- I've looked at the listing, and it's right! -- Joel Halpern
RE: [PATCH] changing IV to opcode_t!!
Simon Cozens:
# On Thu, Sep 20, 2001 at 01:50:04AM -0700, Brent Dax wrote:
# +int main(int argc, char **argv) {
# + printf(%d/%d, sizeof(${iv}), sizeof(${nv}));
# + return 0;
# +}
#
# $Config{ivsize} not good enough for ya, then? :)
No, because the user may have chosen a different value for IV. For
example, I may have chosen 'long long' in Perl 5 but 'long' in Parrot to
be safe (IIRC, we're still having 64-bit issues). Thus, we can't depend
on $Config{ivsize}. Thus, a little bit of C is necessary to check for
us. Thus, I am very tired, since I'm talking like this. I should go to
sleep. Goodnight.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
Re: [PATCH] changing IV to opcode_t!!
On Thu, Sep 20, 2001 at 01:57:51AM -0700, Brent Dax wrote: No, because the user may have chosen a different value for IV. For Oh, yep, fair enough. That makes sense. example, I may have chosen 'long long' in Perl 5 but 'long' in Parrot to be safe (IIRC, we're still having 64-bit issues) Yeah. That needs fixed. :( Thus, I am very tired, since I'm talking like this. I should go to sleep. Goodnight. Sleep well. -- He was a modest, good-humored boy. It was Oxford that made him insufferable.
[PATCH] Comment fixes
Attached are trivial comment fixes for two files.
As it so happens, it strikes me that CONCAT Sx, Sx isn't
three-register code. I'd be much happier with CONCAT Sx, Sx, Sx - it'd
make it easier to generate code for and would fit in with the rest of
the instructions. Comments?
Leon
ps should i start filing bug reports in rt if my assembler bugs
aren't being fixed? ;-)
--
Leon Brocard.http://www.astray.com/
Nanoware...http://www.nanoware.org/
... Have you seen Quasimoto? I have a hunch he's back!
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.21
diff -u -u -r1.21 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/19 21:32:29 1.21
+++ basic_opcodes.ops 2001/09/20 09:01:17
@@ -452,6 +452,7 @@
STR_REG(P1) = s;
}
+/* CONCAT Sx, Sx */
AUTO_OP concat_s {
STRING *s = string_concat(STR_REG(P1), STR_REG(P2), 1);
STR_REG(P1) = s;
Index: process_opfunc.pl
===
RCS file: /home/perlcvs/parrot/process_opfunc.pl,v
retrieving revision 1.12
diff -u -u -r1.12 process_opfunc.pl
--- process_opfunc.pl 2001/09/19 21:32:29 1.12
+++ process_opfunc.pl 2001/09/20 09:01:32
@@ -19,11 +19,11 @@
#
#... body of function ...
#
-#RETVAL = x;
+#RETURN(x);
#
# }
#
-# There may be more than one RETVAL
+# There may be more than one RETURN
#
# The functions have the magic variables Pnnn for parameters 1 through
# X. (Parameter 0 is the opcode number) Types for each, and the size
Re: [PATCH] Comment fixes
On Thu, Sep 20, 2001 at 10:05:00AM +0100, Leon Brocard wrote: As it so happens, it strikes me that CONCAT Sx, Sx isn't three-register code. I'd be much happier with CONCAT Sx, Sx, Sx - it'd make it easier to generate code for and would fit in with the rest of the instructions. Comments? It also means you *have* to allocate a new string each concat. That sucks. ps should i start filing bug reports in rt if my assembler bugs aren't being fixed? ;-) Yes, yes, yes. Simon -- The course of true anything never does run smooth. -- Samuel Butler
Re: question about branching/returning
On Wed, Sep 19, 2001 at 10:32:18PM -0700, Dave Storrs wrote: Ok, that was pretty much what I thought. But then what is the 'end' opcode for? It does a 'RETURN 0', which would increment the PC by 0 opcodes...which either counts as an infinite loop or a no-op, and we've already got a no-op op. RETURN(0) is special-cased by process_opcodes(); it returns a literal 0, not a relative address. As other people have noted, this is irrelevent, as end is never called. - Damien
Re: [PATCH] Comment fixes
On Thursday 20 September 2001 05:12 am, Simon Cozens wrote: On Thu, Sep 20, 2001 at 10:05:00AM +0100, Leon Brocard wrote: As it so happens, it strikes me that CONCAT Sx, Sx isn't three-register code. I'd be much happier with CONCAT Sx, Sx, Sx - it'd make it easier to generate code for and would fit in with the rest of the instructions. Comments? It also means you *have* to allocate a new string each concat. That sucks. It's no different than any of the other two-and-three register operands (sans allocation, of course), except that you didn't bother creating a three operand version. (IOW, you have: a += b and a = b + c and a ~= b but not a = b ~ c ) Of course, that last is really: a = b a ~= c anyway. But that's two ops, vice one, and you may underallocate 'a' on the first op. With 'a = b ~ c', you can allocate 'a' the correct length. (Assuming a bad allocation scheme, the cuts the number of allocations of @array in half.) If you're not going to have continuous string buffers, that's all moot. But I would imagine that those would be handled via the PMC registers instead. I wouldn't say that CONCAT Sx,Sx should be CONCAT Sx,Sx,Sx, but that CONCAT Sx,Sx,Sx should be added. I'll patch (if warranted) when I find the time, unless someone beats me to it. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: question about branching/returning
Simon --
But this still sucks:
while (code = code_start code (code_start + code_size) code-i) {
DO_OP(code, temp, func, interpreter);
}
Three tests and an addition each op. At the *very least*, we should store
code_end = code_start + code_size. And at best...
This:
while (code = code_start code (code_start+code_size) *code)
{ DO_OP(code, interpreter); }
should be the same as this:
IV code_end = code_start + code_size;
while (code = code_start code code_end *code)
{ DO_OP(code, interpreter); }
once the optimizer is through (disclaimer: IANAO).
DS The default dispatch loop shouldn't check. The Safe dispatch loop (note the
DS caps there... :) should check.
If we add:
#define PARROT_SAFE_FLAG 0x04 /* Watch bytecode block bounds */
to include/parrot/interpreter.h, then we could change the core runops
loop to look like this:
if (interpreter-flags PARROT_SAFE_FLAG) {
IV code_end = code_start + code_size; /* Nice and explicit */
while (code = code_start code code_end *code)
{ DO_OP(code, interpreter); }
}
else {
while (*code) { DO_OP(code, interpreter); }
}
But I don't know if that is on track with where folks want to head of
safe operation, or if this is a good way but should be called
something other than safe...
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: Complete failure on Linux/PowerPC with 64bit ints.
On Thu, 20 Sep 2001, Michael G Schwern wrote: But if we run Configure.pl with bleadperl that *does* use 64bit ints and has debugging flags on, there's trouble. And all of the tests fail with This isn't Parrot bytecode! That's because assemble.pl hasn't been patched yet to use the right pack_type. You can either apply my patch from yesterday or you can hand-patch the pack_type for 'i' to be 'q'. Once you do that, you'll probably still get lots of failures of the form Error: Control left bounds of byte-code block (now at location -234894350)! -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: [FIX] jakoc syntax error
Michael --
Thanks. Applied.
On Thu, 2001-09-20 at 04:00, Michael L Maraist wrote:
Guess you're the man to see about a zebra... Well, an equal sign if you don't
squint really hard.
Version 1.6 line 613
You have
$string =~ s/([^\\])\$((([A-Za-z][A-Za-z0-9_]*)\b)|({[A-Za-z][A-Za-z0=9_]*}))/$1,
$2, /g;
Note the [A-Za-z0=9] instead of 0-9.
Enjoy.
-Michael
--
_
/ 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: Complete failure on Linux/PowerPC with 64bit ints.
On Thu, Sep 20, 2001 at 09:03:45AM -0400, Andy Dougherty wrote: On Thu, 20 Sep 2001, Michael G Schwern wrote: But if we run Configure.pl with bleadperl that *does* use 64bit ints and has debugging flags on, there's trouble. And all of the tests fail with This isn't Parrot bytecode! That's because assemble.pl hasn't been patched yet to use the right pack_type. You can either apply my patch from yesterday or you can hand-patch the pack_type for 'i' to be 'q'. This one? http:[EMAIL PROTECTED]/msg04540.html -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Death follows me like a wee followey thing. -- Quakeman
RE: Complete failure on Linux/PowerPC with 64bit ints.
Don't forget that this patch requires the configure patch by Brent that was just a couple of messages back. -Original Message- From: Michael G Schwern To: Andy Dougherty Cc: [EMAIL PROTECTED] Sent: 9/20/2001 8:22 AM Subject: Re: Complete failure on Linux/PowerPC with 64bit ints. On Thu, Sep 20, 2001 at 09:03:45AM -0400, Andy Dougherty wrote: On Thu, 20 Sep 2001, Michael G Schwern wrote: But if we run Configure.pl with bleadperl that *does* use 64bit ints and has debugging flags on, there's trouble. And all of the tests fail with This isn't Parrot bytecode! That's because assemble.pl hasn't been patched yet to use the right pack_type. You can either apply my patch from yesterday or you can hand-patch the pack_type for 'i' to be 'q'. This one? http:[EMAIL PROTECTED]/msg04540.html -- Michael G. Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Death follows me like a wee followey thing. -- Quakeman
Re: [PATCH] changing IV to opcode_t!!
On Wed, Sep 19, 2001 at 02:51:19PM -0400, Andy Dougherty wrote:
This might help a bit.
It does; Parrot is now working to at least some degree on Tru64.
Andy, I love you and I want to have your children.
--
void russian_roulette(void) { char *target; strcpy(target, bullet); }
Re: cvs snapshots
On Tue, 18 Sep 2001, H.Merijn Brand wrote: [...] it's only updated every 6th hour. Maybe I'll get time to get it to update more often (but not create a snapshot) tonight. From all my machines I get i2:/l1/pro/3gl/CPAN/parrot 104 rsync -avz rsync://cvs.perl.org::parrot-HEAD/ . failed to connect to cvs.perl.org - Can't assign requested address Hmn, no idea. What does a traceroute say? - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
[PATCH] Minimal changes required for smoking
These are the minimal fixes for smoking to take effect.
After these are in, I'll release Parrot::Smoke
* Makefile.in
* it is $(INC)/config.h, not config.h
* .o = $(O)
* test_main.c
* _read was ok when it was inside
ifdef WIN32
now it must be read ( or it fails in
non-win32 pre-5.6.0 systems )
* t/op/integer.t
* you *can't* test 0x == -1
( and the whole first test looks
very suspicious )
Regards
Mattia
--- parrot.cvs/Makefile.in Thu Sep 20 00:54:46 2001
+++ parrot/Makefile.in Thu Sep 20 15:35:14 2001
@@ -19,5 +19,5 @@
PDUMP = pdump${exe}
-.c.o:
+.c$(O):
$(CC) $(CFLAGS) -o $@ -c $
@@ -66,5 +66,5 @@
$(PERL) make_op_header.pl opcode_table $(INC)/op.h
-config.h: Configure.pl config_h.in
+$(INC)/config.h: Configure.pl config_h.in
$(PERL) Configure.pl
--- parrot.cvs/test_main.c Thu Sep 20 15:27:42 2001
+++ parrot/test_main.c Thu Sep 20 15:27:18 2001
@@ -95,5 +95,5 @@
#ifndef HAS_HEADER_SYSMMAN
program_code = (opcode_t*)mem_sys_allocate(program_size);
-_read(fd, (void*)program_code, program_size);
+read(fd, (void*)program_code, program_size);
#else
program_code = (opcode_t*)mmap(0, program_size, PROT_READ, MAP_SHARED, fd, 0);
--- parrot.cvs/t/op/integer.t Thu Sep 20 15:25:46 2001
+++ parrot/t/op/integer.t Thu Sep 20 15:25:04 2001
@@ -19,7 +19,4 @@
print I2
print \\n
- set I3, 4294967295
- print I3
- print \\n
end
CODE
@@ -28,5 +25,4 @@
2147483647
-2147483648
--1
OUTPUT
Re: Complete failure on Linux/PowerPC with 64bit ints.
On Thu, Sep 20, 2001 at 09:22:50AM -0400, Michael G Schwern wrote: That's because assemble.pl hasn't been patched yet to use the right pack_type. You can either apply my patch from yesterday or you can hand-patch the pack_type for 'i' to be 'q'. This one? http:[EMAIL PROTECTED]/msg04540.html It's applied; just resync. -- I want you to know that I create nice things like this because it pleases the Author of my story. If this bothers you, then your notion of Authorship needs some revision. But you can use perl anyway. :-) - Larry Wall
Re: Feature Freeze
On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote: So, if you're running on one of the core platforms, please check out a *clean* CVS copy, try and build and post the output of make test. FWIW, here's the current state of Tru64: Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/integer.t4 1024264 15.38% 1 3 21 23 t/op/number.t21 537623 21 91.30% 1-19 21 23 t/op/trans.t 18 460818 18 100.00% 1-18 4 subtests skipped. Failed 3/5 test scripts, 40.00% okay. 43/74 subtests failed, 41.89% okay. -- Actually Perl *can* be a Bondage Discipline language but it's unique among such languages in that it lets you use safe words. -- Piers Cawley
RE: Tru64
Ok, I applied Damien's integer.t fix and we now get: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/number.t7 1792237 30.43% 1 7 9 11 13 15 17 4 subtests skipped. Failed 1/5 test scripts, 80.00% okay. 7/74 subtests failed, 90.54% okay. make: *** [test] Error 2 Damien, is there any way we could get a similar fix for number.t? That would make us at 100% on Tru64. Thanks! Tanton
Re: [PATCH] changing IV to opcode_t!!
On Thu, 20 Sep 2001, Simon Cozens wrote: On Wed, Sep 19, 2001 at 02:51:19PM -0400, Andy Dougherty wrote: This might help a bit. It does; Parrot is now working to at least some degree on Tru64. Your job has just begun :-). Seriously, some serious thought is needed about integral and pointer types. Perl currently uses just one type, the IV, for everything. That's both good and bad. Parrot may or may not want to do the same. It may be sensible to have an opcode_t type that is usually 'int' (perhaps 32-bit, perhaps 64, whatever is more natural on the platform), and a separate IV type (quite possibly 64-bit if the platform supports it reasonably well) that holds integer 'data'. I really don't know which is best. Similarly, whatever integral types are used, it would be best to spell out carefully what assumptions we want to make about conversions between pointers and integers. Have the appropriate amount of fun, Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Complete failure on Linux/PowerPC with 64bit ints.
[EMAIL PROTECTED] (Andy Dougherty) writes: [...] That's because assemble.pl hasn't been patched yet to use the right pack_type. You can either apply my patch from yesterday [...] If you sign up for an account at http://dev.perl.org/auth/account I am sure that Dan and Simon will let me flip the cvs access bit for you. =) -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
[PATCH] More NV/IV size issues.
This patch does two only somewhat related things.
Parrot/Opcode.pm: Change the hard-wired assumption that sizeof(nv) =
2*sizeof(iv) to a PConfig-type computed value.
Parrot/Test.pm: Change it to run with the perl that was used to generate
this version of Parrot. This is useful if, for example, you want to use
bleadperl to build and test parrot (e.g. to try out various 64-bit
options) but you still have a 5.6.x (or 5.005_xx) installed as the default
'perl' on your system. Since perl-5.7.x is installed 'version-only', a
plain 'perl' is quite likely to pick up the older perl in such cases.
Such an older perl might well not understand pack('q') used in the
assembler.
diff -r -u parrot/Parrot/Opcode.pm parrot-andy/Parrot/Opcode.pm
--- parrot/Parrot/Opcode.pm Mon Sep 17 20:32:15 2001
+++ parrot-andy/Parrot/Opcode.pmThu Sep 20 10:18:43 2001
@@ -2,11 +2,15 @@
use strict;
use Symbol;
+use Parrot::Config;
my %opcode;
my $fingerprint;
my $revision;
+my $nvivsize;
+$nvivsize = $PConfig{nvsize}/$PConfig{ivsize};
+
sub _load {
my $file = @_ ? shift : opcode_table;
@@ -42,7 +46,7 @@
my $num_i = () = grep {/i/} @params;
my $num_n = () = grep {/n/} @params;
- $opcode{$name}{RETURN_OFFSET} = 1 + $num_i + $num_n * 2;
+ $opcode{$name}{RETURN_OFFSET} = 1 + $num_i + $num_n * $nvivsize;
}
}
@@ -145,7 +149,7 @@
my $num_i = () = grep {/i/} @params;
my $num_n = () = grep {/n/} @params;
- $opcode{$name}{RETURN_OFFSET} = 1 + $num_i + $num_n * 2;
+ $opcode{$name}{RETURN_OFFSET} = 1 + $num_i + $num_n * $nvivsize;
}
return %opcode;
diff -r -u parrot/Parrot/Test.pm parrot-andy/Parrot/Test.pm
--- parrot/Parrot/Test.pm Sun Sep 16 12:21:16 2001
+++ parrot-andy/Parrot/Test.pm Thu Sep 20 10:14:05 2001
@@ -4,6 +4,7 @@
use strict;
use vars qw(@EXPORT @ISA);
+use Parrot::Config;
require Exporter;
require Test::More;
@@ -57,7 +58,7 @@
print ASSEMBLY $assembly;
close ASSEMBLY;
-_run_command( perl assemble.pl $as_f --output $by_f );
+_run_command( $PConfig{perl} assemble.pl $as_f --output $by_f );
_run_command( ./test_prog $by_f, 'STDOUT' = $out_f );
my $prog_output;
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Feature Freeze
[EMAIL PROTECTED] (Simon Cozens) writes: [...] So, if you're running on one of the core platforms, please check out a *clean* CVS copy, try and build and post the output of make test. On FreeBSD 4.x all passes (or skips) except the first t/op/integer test. (as other people have mentioned). -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: [PATCH] More NV/IV size issues.
On Thu, Sep 20, 2001 at 10:38:10AM -0400, Andy Dougherty wrote:
This patch does two only somewhat related things.
Parrot/Opcode.pm: Change the hard-wired assumption that sizeof(nv) =
2*sizeof(iv) to a PConfig-type computed value.
Parrot/Test.pm: Change it to run with the perl that was used to generate
this version of Parrot. This is useful if, for example, you want to use
bleadperl to build and test parrot (e.g. to try out various 64-bit
options) but you still have a 5.6.x (or 5.005_xx) installed as the default
'perl' on your system. Since perl-5.7.x is installed 'version-only', a
plain 'perl' is quite likely to pick up the older perl in such cases.
Such an older perl might well not understand pack('q') used in the
assembler.
Thanks, applied.
--
Wouldn't it be wonderful if real life supported control-Z?
Vague Heads-up
I'm seriously investigating the possibility of changing IV and NV to something more readable. (But for those of you who are following language-dev, don't tell 'em because then they'll think they've won. ;) -- I don't understand how people can think SCSI is anything more quirky than a genius with peculiar dietary requirements in a world where the creators of Notes, and their new owners, are allowed to walk the streets without fearing for their very lives. - Graham Reed, asr
Re: Failures with Perl 5.005
On Thu, 20 Sep 2001, Philip Kendall wrote: What version of Perl are we requiring to bootstrap Parrot? At the moment, things fail with 5.005 because: 2) The use of `!' to pack() in the assembler. Oops. My fault. I forgot that was a new addition. It's not really a big problem. You can just delete it for the moment. Later today I'll try to fix it better, but I need to read the 5.005, 5.6.x, and 5.7.x pack(3pm) man pages again carefully first. If someone else beats me to it, I'd be happy. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Vague Heads-up
At 03:34 PM 9/20/2001 +0100, Simon Cozens wrote: (But for those of you who are following language-dev, don't tell 'em because then they'll think they've won. ;) Ah, go ahead and tell them. I don't much care about who wins or loses if the code's easier to maintain and runs fast. (Neither do I much care about people who really care about winning or losing, 'cause they'll get in the way of the two main goals... :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot multithreading?
At 03:59 PM 9/20/2001 +0200, Arthur Bergman wrote: While it has been decided that perl should be using ithread like threading, I guess that is irelevant at the parrot level. Are you going to have one virtual cpu per thread with it's own set of registers or are you going to context switch the virtual cpu? What we're going to do is fire up a new interpreter for each thread. (We may have a pool of prebuilt interpreters hanging around for this eventuality) Threading *is* essential at the parrot level, and there are even a few (as yet undocumented) opcodes to deal with them, and some stuff that's an integral part of the variable vtable code to deal with it. Whether it's considered ithread-like or not's up in the air--it'll probably look a lot like a mix. I'm also seriously considering throwing *all* PerlIO code into separate threads (one per file) as an aid to asynchrony. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Draft switch for DO_OP() :-)
At 12:07 AM 9/20/2001 -0700, Damien Neil wrote: I'm not at all certain what to do with things outside the opcodes themselves. The .ops = .c conversion was clearly originally concieved as translating one file into another. In order to dispatch ops via a switch, you need to pull out only the function contents; this makes the .ops file into a definition of function code only...the remainder of the file gets tossed by the wayside. Actually the ops=C conversion was conceived to do exactly what's being done now--to abstract out the body of the opcodes so that they could be turned into a switch, or turned into generated machine code, or TIL'd. If you're finding that this isn't working well it's a sign we need to change things some so they will. (Better now than in six months...) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: question about branching/returning
At 10:22 PM 9/19/2001 -0700, Dave Storrs wrote: I'm working on documenting the opcodes, and I want to make sure that I understand the 'RETURN' code properly. I've poked around a little bit to see if I coudl figure it out, but I don't want to divert too much. Would someone please explain to me what each of the following does? RETURN 4 RETURN 0 RETURN -2 # Is this even legal? You've been filled in pretty well (yeah, the docs suck. Sorry... :) on what those should do. Please note that the jump opcode is currently broken. It returns an offset, when it should return an absolute address. (I'm trying to remember if I intended all the RETURNs to return absolute addresses or not) We need a separate RETURN_ABS or something to not do the offset, FWIW. Oh, and end is always op 0, and the oploop checks that, as you've seen. It has a function body anyway, just to be really sure. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Vague Heads-up
Simon Cozens [EMAIL PROTECTED] wrote: I'm seriously investigating the possibility of changing IV and NV to something more readable. (But for those of you who are following language-dev, don't tell 'em because then they'll think they've won. ;) Some time ago I sugested that NV was a bad name, because in early Perl 5 is was there to contrast with PV - ie an SV contains numeric or string value (or both). When SVs started to hold IVs too, the name became misleading - it would have made more sense of rename it FV or something. Also, I think that IV needs splitting into two or more different types. There is the type that specifically fits in the Parrot integer registers and is recognised by parrot ops; Then there are all the other places within perl and parrot which need to contain integers or pointers, which may or may not be the same type or size as the register ints.
Re: Failures with Perl 5.005
On Thu, 20 Sep 2001, Andy Dougherty wrote:
On Thu, 20 Sep 2001, Philip Kendall wrote:
What version of Perl are we requiring to bootstrap Parrot? At the
moment, things fail with 5.005 because:
2) The use of `!' to pack() in the assembler.
Oops. My fault. I forgot that was a new addition.
Here's the fix for that.
--- assemble.pl Thu Sep 20 09:35:26 2001
+++ assembple.pl.port Thu Sep 20 11:23:20 2001
@@ -49,14 +49,15 @@
# define data types
my %pack_type;
# Alas perl5.7.2 doesn't have an IV flag for pack().
-if ($PConfig{ivsize} == $PConfig{longsize}) {
+# The ! modifier only works for perl 5.6.x or greater.
+if (($] = 5.006) ($PConfig{ivsize} == $PConfig{longsize}) ) {
%pack_type = ('i'='l!','n'='d');
}
-elsif ($PConfig{ivsize} == 8) {
-%pack_type = ('i'='q','n'='d');
-}
elsif ($PConfig{ivsize} == 4) {
%pack_type = ('i'='l','n'='d');
+}
+elsif ($PConfig{ivsize} == 8) {
+%pack_type = ('i'='q','n'='d');
}
else {
die(I don't know how to pack an IV!\n);
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Vague Heads-up
At 04:16 PM 9/20/2001 +0100, Dave Mitchell wrote: Also, I think that IV needs splitting into two or more different types. There is the type that specifically fits in the Parrot integer registers and is recognised by parrot ops; Then there are all the other places within perl and parrot which need to contain integers or pointers, which may or may not be the same type or size as the register ints. I don't want to do int-pointer casts anywhere in the source if we can possibly avoid it. Yech. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Vague Heads-up
On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote: I don't want to do int-pointer casts anywhere in the source if we can possibly avoid it. Yech. In which case, do we *need* a type that can hold both. -- Darkly hinting of head hitting desk -- Megahal (trained on asr), 1998-11-05
Re: Feature Freeze
On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote: So, if you're running on one of the core platforms, please check out a *clean* CVS copy, try and build and post the output of make test. FWIW, here's the current state of Linux/Sparc (ivsize=8, nvsize=8, ptrsize=4) 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 -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Vague Heads-up
At 04:38 PM 9/20/2001 +0100, Simon Cozens wrote: On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote: I don't want to do int-pointer casts anywhere in the source if we can possibly avoid it. Yech. In which case, do we *need* a type that can hold both. I can't think of a reason, no. I don't promise that a reason doesn't exist, however. :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Me
I will be on vacation in Disney World from now until Sunday night. Therefore, if you need me I won't be here :) Tanton
[PATCH] make realclean
This patch adds some more tidying-up to Makefile.in and t/Makefile. The split between clean and realclean is absolutely arbitrary; season to taste. diff -r -u parrot/Makefile.in parrot-andy/Makefile.in --- parrot/Makefile.in Wed Sep 19 12:48:28 2001 +++ parrot-andy/Makefile.in Thu Sep 20 12:49:38 2001 @@ -69,8 +69,14 @@ $(PERL) Configure.pl clean: - rm -f *$(O) *.s basic_opcodes.c $(INC)/interp_guts.h $(INC)/op.h $(TEST_PROG) + rm -f *$(O) *.s basic_opcodes.c $(INC)/interp_guts.h $(INC)/op.h + rm -f $(TEST_PROG) pdump + +realclean: clean + rm -f *.pbc core + rm -f Parrot/Config.pm $(INC)/config.h + cd t; make realclean + rm -f Makefile test: $(PERL) t/harness - diff -r -u parrot/t/Makefile parrot-andy/t/Makefile --- parrot/t/Makefile Mon Sep 17 20:32:55 2001 +++ parrot-andy/t/Makefile Thu Sep 20 12:47:35 2001 @@ -3,8 +3,13 @@ .SUFFIXES: .pbc .pasm +RM_F = rm -f + clean: - rm *.pbc + $(RM_F) op/*.out op/*.pasm op/*.pbc + +realclean: clean + $(RM_F) *.pbc core .pasm.pbc: perl -I.. ../assemble.pl $ $@ -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Feature Freeze
On Thu 20 Sep 2001 15:49, Simon Cozens [EMAIL PROTECTED] wrote: On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote: So, if you're running on one of the core platforms, please check out a *clean* CVS copy, try and build and post the output of make test. FWIW, here's the current state of Tru64: Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/integer.t4 1024264 15.38% 1 3 21 23 t/op/number.t21 537623 21 91.30% 1-19 21 23 t/op/trans.t 18 460818 18 100.00% 1-18 4 subtests skipped. Failed 3/5 test scripts, 40.00% okay. 43/74 subtests failed, 41.89% okay. I did let it run for some time to get a more complete picture :) Here's the results from the Dutch HP-UX 11.00 jury running bleadperl for Parrot snap 20 Sep 2001 09:00 Configuration: -Dusedevel -Uuseperlio === ../perl t/harness t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerok t/op/number.Confused test output: test 2 answered after test 6 Test output counter mismatch [test 7] Confused test output: test 2 answered after test 7 Test output counter mismatch [test 8] Confused test output: test 2 answered after test 8 Test output counter mismatch [test 9] Confused test output: test 2 answered after test 9 Test output counter mismatch [test 10] Confused test output: test 2 answered after test 10 Test output counter mismatch [test 11] Confused test output: test 2 answered after test 11 Test output counter mismatch [test 12] Confused test output: test 2 answered after test 12 Test output counter mismatch [test 13] Confused test output: test 2 answered after test 13 Test output counter mismatch [test 14] Confused test output: test 2 answered after test 14 Test output counter mismatch [test 15] Confused test output: test 2 answered after test 15 Test output counter mismatch [test 16] Confused test output: test 2 answered after test 16 Test output counter mismatch [test 17] Confused test output: test 2 answered after test 17 Test output counter mismatch [test 18] Confused test output: test 2 answered after test 18 Test output counter mismatch [test 19] dubious Test returned status 21 (wstat 5376, 0x1500) DIED. FAILED tests 1-19, 21, 23 Failed 21/23 tests, 8.70% okay (-2 skipped tests: 0 okay, 0.00%) t/op/string.ok, 1/5 skipped: I'm unable to write it! 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/number.t 21 537623 142 617.39% 1-19 21 23 t/op/trans.t 2 512182 11.11% 13 18 4 subtests skipped. For all next configurations I manually removed the line noise ... Configuration: -Dusedevel -Uuseperlio === t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerok t/op/number. DIED. FAILED tests 1-19, 21, 23 t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans.. DIED. FAILED tests 13, 18 Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/number.t 21 537623 142 617.39% 1-19 21 23 t/op/trans.t 2 512182 11.11% 13 18 4 subtests skipped. Configuration: -DDEBUGGING -Dusedevel -Uuseperlio === t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerok t/op/number. DIED. FAILED tests 1-19, 21, 23 t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans.. DIED. FAILED tests 13, 18 Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/number.t 21 537623 142 617.39% 1-19 21 23 t/op/trans.t 2 512182 11.11% 13 18 4 subtests skipped. Configuration: -DDEBUGGING -Dusedevel -Uuseperlio === t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerok t/op/number. DIED. FAILED tests 1-19, 21, 23 t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans.. DIED. FAILED tests 13, 18 Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/number.t 21 537623 142 617.39% 1-19 21 23 t/op/trans.t 2 512182 11.11% 13 18 4 subtests skipped. Configuration: -Dusedevel -Duseperlio
RE: question about branching/returning
On Thu, 20 Sep 2001, Brent Dax wrote: Damien Neil: # RETURN(0); (written exactly like that, no variation permitted) # is a special case, and terminates the runops loop. The only op # which uses this is end, and it doesn't actually ever execute. # Personally, I feel that this special case should be removed. We should probably just check if the thing returned 0 and exit runops if that's the case. This will also protect us against utter stupidity like: FOO:jump FOO which wouldn't be a bad thing to protect against. To my understanding jump FOO would physically map to the c-code return code + code[1], which means the number zero is not returned, even thoughthe offset of FOO is zero bytes. (I'm away from the source code so I can't verify this, but it's what I remember) -Michael
Re: Parrot multithreading?
AB == Arthur Bergman [EMAIL PROTECTED] writes: AB In an effort to rest my braine from a coredumping perl5 I started AB to think a bit on threading under parrot? While it has been AB decided that perl should be using ithread like threading, I guess AB that is irelevant at the parrot level. Are you going to have one AB virtual cpu per thread with it's own set of registers or are you AB going to context switch the virtual cpu? it is not irrelevent IMO. since each thread will have a private parrot interpreter, then parrot must minimize any globals so it can be almost all stack based. this means the parrot control structure must be malloc'd and only one pointer to it must be in some sort of global space (for thread management). this structure will manage the PC, the stacks, thread global vars, memory management (with or without gc?), etc. AB If it was one virtual cpu per thread then one would just create a AB new virtual cpu and feed it the bytecode stream? that is the idea as i have understood it. AB Is there anything I could help with regarding this? i think we need to design the (async) i/o and event subsystems either before or in parallel to the thread subsystem. they will all be coupled in various ways and it is better to do all the design first so you don't have awkward interfaces later. 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: Vague Heads-up
On Thu, 20 Sep 2001, Dan Sugalski wrote: At 04:38 PM 9/20/2001 +0100, Simon Cozens wrote: On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote: I don't want to do int-pointer casts anywhere in the source if we can possibly avoid it. Yech. In which case, do we *need* a type that can hold both. I can't think of a reason, no. I don't promise that a reason doesn't exist, however. :) Well, the following (macro-expanded) line in register.c tries to go both ways: chunk_base = (void *)(0xf000 (IV) interpreter-int_reg ) ; -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Parrot multithreading?
DS == Dan Sugalski [EMAIL PROTECTED] writes: DS I'm also seriously considering throwing *all* PerlIO code into separate DS threads (one per file) as an aid to asynchrony. but that will be hard to support on systems without threads. i still have that internals async i/o idea floating in my numb skull. it is an api that would look async on all platforms and will use the kernel async file i/o if possible. it could be made thread specific easily as my idea was that the event system was also thread specific. as i just got my home boxes reorganized and my wife is actually getting independent (drives herself now) from her broken leg, i will have some more time to burn here. 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
Parrot Smoke Sep 20 00:00:02 2001 MSWin32 4.0
Automated smoke report for patch Sep 20 00:00:02 2001 v0.01 on MSWin32 using cl version 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 --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 --define nv=float F F --defaults --define iv=long --define nv=double F F --defaults --define iv=long --define nv=\long double\ | | | +- --debugging +--- normal Failures: MSWin32 --defaults --define iv=int --define nv=float MSWin32 --debugging --defaults --define iv=int --define nv=float t/op/integerdubious DIED. FAILED test 25 t/op/number.dubious DIED. FAILED tests 1-5, 9-18, 23 t/op/trans..dubious DIED. FAILED tests 1-18 MSWin32 --defaults --define iv=int --define nv=double MSWin32 --debugging --defaults --define iv=int --define nv=double MSWin32 --defaults --define iv=int --define nv=\long double\ MSWin32 --debugging --defaults --define iv=int --define nv=\long double\ t/op/number.dubious DIED. FAILED test 1 MSWin32 --defaults --define iv=long --define nv=float MSWin32 --debugging --defaults --define iv=long --define nv=float t/op/integerdubious DIED. FAILED test 25 t/op/number.dubious DIED. FAILED tests 1-5, 9-18, 23 t/op/trans..dubious DIED. FAILED tests 1-18 MSWin32 --defaults --define iv=long --define nv=double MSWin32 --debugging --defaults --define iv=long --define nv=double MSWin32 --defaults --define iv=long --define nv=\long double\ MSWin32 --debugging --defaults --define iv=long --define nv=\long double\ t/op/number.dubious DIED. FAILED test 1
Backslashes in $PConfig{perl}
Configuration VC7 Normal is BROKEN. Step: make test STDOUT output: C:\Perl\bin\perl.exe t/harness t/op/basic..dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/2 tests, 50.00% okay (-1 skipped test: 0 okay, 0.00%) t/op/integerdubious Test returned status 26 (wstat 6656, 0x1a00) DIED. FAILED tests 1-26 Failed 26/26 tests, 0.00% okay t/op/number.dubious Test returned status 21 (wstat 5376, 0x1500) DIED. FAILED tests 1-19, 21, 23 Failed 21/23 tests, 8.70% okay (-2 skipped tests: 0 okay, 0.00%) t/op/string.dubious Test returned status 4 (wstat 1024, 0x400) DIED. FAILED tests 1-3, 5 Failed 4/5 tests, 20.00% okay (-1 skipped test: 0 okay, 0.00%) t/op/trans..dubious Test returned status 18 (wstat 4608, 0x1200) DIED. FAILED tests 1-18 Failed 18/18 tests, 0.00% okay Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/basic.t 1 256 21 50.00% 1 t/op/integer.t 26 665626 26 100.00% 1-26 t/op/number.t21 537623 21 91.30% 1-19 21 23 t/op/string.t 4 1024 54 80.00% 1-3 5 t/op/trans.t 18 460818 18 100.00% 1-18 4 subtests skipped. STDERR output: 'C:Perlinperl.exe' is not recognized as an internal or external command, operable program or batch file. # Failed test (Parrot/Test.pm at line 74) # got: 'can't stat t/op/basic1.pbc, code 2 ' # expected: '42' # Looks like you failed 1 tests of 2. ... It looks like the backslashes in the path are being interpreted incorrectly. I don't think the problem is in Configure; can somebody look at it? --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: Parrot multithreading?
DS I'm also seriously considering throwing *all* PerlIO code into separate DS threads (one per file) as an aid to asynchrony. but that will be hard to support on systems without threads. i still have that internals async i/o idea floating in my numb skull. it is an api that would look async on all platforms and will use the kernel async file i/o if possible. it could be made thread specific easily as my idea was that the event system was also thread specific. I think we should have some thread abstraction layer instead of throwing PerlIO into threads. The thread abstraction layer can use either native thread package (blocking io), or implement user level thread package with either non-blocking io or async io. The internal io should be sync instead of async. async is normally slower than sync (most of unix don't have real async io), and thread is cheap. Hong
Re: Parrot multithreading?
On Thu, Sep 20, 2001 at 12:33:54PM -0700, Hong Zhang wrote:
DS I'm also seriously considering throwing *all* PerlIO code into
separate
DS threads (one per file) as an aid to asynchrony.
but that will be hard to support on systems without threads. i still
have that internals async i/o idea floating in my numb skull. it is an
api that would look async on all platforms and will use the kernel async
file i/o if possible. it could be made thread specific easily as my idea
was that the event system was also thread specific.
I think we should have some thread abstraction layer instead of throwing
PerlIO into threads. The thread
abstraction layer can use either native thread package (blocking io), or
implement user level thread package
with either non-blocking io or async io. The internal io should be sync
instead of async. async is normally
slower than sync (most of unix don't have real async io), and thread is
cheap.
I agree. Threads, at least in spirit, provide a cleaner interface to
threading and asynchronous I/O than user level callbacks. There's
nothing stopping a compiler from generating event driven code out of
procedural, perhaps even threaded code. Consider this:
sub read_console {
print while ();
}
sub read_log {
print while (LOG);
}
Thread-new( \read_console );
Thread-new( \read_log );
sleep 1 while threads_active();
exit 0;
A compiler can either generate threaded code that's pretty close to
the original source, or it can generate asynchronous callbacks at the
bytecode level. The same source code could compile and run on systems
that support asynchronous I/O, threads, or both.
Here's some parrot assembly that may or may not be legal at the
moment. It shows what a compiler might do with the threaded source
code on a system that only supported asynchronous I/O.
read_console_entry:
find_global P1, STDIN, main
set I1, read_console_got_line
jsr set_input_callback
return
read_console_got_line:
# Assumes the AIO engine sets S1 with a read line.
printS1
return
read_log_entry:
find_global P1, LOG, main
set I1, read_log_got_line
jsr set_input_callback
return
read_log_got_line:
# Assumes the AIO engine sets S1 with a read line.
printS1
return
main:
set I1, read_console_entry
jsr thread_new
set I1, read_log_entry
jsr thread_new
main_timer_loop:
set I1, main_timer_done
set I2, 1
jsr set_timer
return
main_timer_done:
jsr threads_active
ne I1, 0, main_timer_loop
end
__END__
-- Rocco Caputo / [EMAIL PROTECTED] / poe.eekeek.org / poe.sourceforge.net
Re: Parrot multithreading?
Arthur Bergman wrote: In an effort to rest my braine from a coredumping perl5 I started to think a bit on threading under parrot? While it has been decided that perl should be using ithread like threading, I guess that is irelevant at the parrot level. Are you going to have one virtual cpu per thread with it's own set of registers or are you going to context switch the virtual cpu? If it was one virtual cpu per thread then one would just create a new virtual cpu and feed it the bytecode stream? Is there anything I could help with regarding this? Arthur The context is almost identical to that of Perl5's MULTIPLICITY which passes the perl-interpreter to each op-code. Thus there is inherent support for multiple ithread-streams. In the main-loop (between each invoked op-code) there is an event-checker (or was in older versions at any rate). It doesn't do anything yet, but it would make sence to assume that this is where context-switches would occur, which would simply involve swapping out the current pointer to the perl-context; A trivial matter. The easiest threading model I can think of would be to have a global var called next_interpreter which is always loaded in the do-loop. An asynchronous timer (or event) could cause the value of next_interpreter to be swapped. This way no schedule function need be checked on each operation. The cost is that of an extra indirection once per op-code. True MT code simply has each thread use it's own local interpreter instance. MT-code is problematic with non MT-safe extensions (since you can't enforce that). In iThread, you don't have a problem with atomic operations, but you can't take advantage of multiple CPUs nor can you garuntee prevention of IO-blocking (though you can get sneaky with UNIX-select). -Michael
SV: Parrot multithreading?
Arthur Bergman wrote: In an effort to rest my braine from a coredumping perl5 I started to think a bit on threading under parrot? While it has been decided that perl should be using ithread like threading, I guess that is irelevant at the parrot level. Are you going to have one virtual cpu per thread with it's own set of registers or are you going to context switch the virtual cpu? If it was one virtual cpu per thread then one would just create a new virtual cpu and feed it the bytecode stream? Is there anything I could help with regarding this? Arthur The context is almost identical to that of Perl5's MULTIPLICITY which passes the perl-interpreter to each op-code. Thus there is inherent support for multiple ithread-streams. In the main-loop (between each invoked op-code) there is an event-checker (or was in older versions at any rate). It doesn't do anything yet, but it would make sence to assume that this is where context-switches would occur, which would simply involve swapping out the current pointer to the perl-context; A trivial matter. Uhm, are you talking perl 5 here? The event checker checks for signals, we got safe signals now. MULTIPLICITY is just allowing multiple interpreters, ithreads is letting them run at the same time and properly clone them. If you want to use it switch interpreters at runtime for fake threads, patches are welcome, send it and I will apply it. The easiest threading model I can think of would be to have a global var called next_interpreter which is always loaded in the do-loop. An asynchronous timer (or event) could cause the value of next_interpreter to be swapped. This way no schedule function need be checked on each operation. The cost is that of an extra indirection once per op-code. True MT code simply has each thread use it's own local interpreter instance. MT-code is problematic with non MT-safe extensions (since you can't enforce that). I am sorry to say, but perl 5 is true MT. In iThread, you don't have a problem with atomic operations, but you can't take advantage of multiple CPUs nor can you garuntee prevention of IO-blocking (though you can get sneaky with UNIX-select). Where did you get this breaking info? ithread works with multiple CPUs and IO blocking is not a problem. Arthur
void*
Dan, Could you explain again why you don't want char* anywhere, and prefer void*? You answered this on language-dev, but went off on what seemed to be a tangent about encodings. Some ramblings of my own that may be confusing me, are: char* doesn't necessarily mean a string. would typedef char byte (or) typedef char bytes make you happy? But still - why void*? I think that will make things harder to understand... having a generic type (which might initially be typedef void generic) might make things more understandable and allow for some typechecking. -R
Re: Tru64
On Thu, Sep 20, 2001 at 09:06:12AM -0500, Gibbs Tanton - tgibbs wrote: Damien, is there any way we could get a similar fix for number.t? That would make us at 100% on Tru64. (Apologies if this shows up twice; something appears to be screwy with my mail system.) I'm currently getting segfaults on all tests on Tru64; I'll look into it if I get a chance, but I may not have time for a few days. (I'm flying to Connecticut for a friend's wedding tomorrow morning.) I didn't think there were any tests in number.t which would be particularly architecture-dependent...which ones are failing for you, and what output are they producing? - Damien
Re: Draft switch for DO_OP() :-)
On Thu, Sep 20, 2001 at 11:11:42AM -0400, Dan Sugalski wrote:
Actually the ops=C conversion was conceived to do exactly what's being
done now--to abstract out the body of the opcodes so that they could be
turned into a switch, or turned into generated machine code, or TIL'd. If
you're finding that this isn't working well it's a sign we need to change
things some so they will. (Better now than in six months...)
The problem is that the conversion currently done by process_opcodes.pl
translates the op definitions into functions, and leaves the remainder
of the file untouched. This is useful, because it allows the opcode
file to include headers, declare file-scope variables, and the like.
Unfortunately, when translating the ops into a switch statement in a
header file, there is no place to put this non-opcode code.
There are a few approaches we can take. The simplest, I think, is to
ignore the problem when generating inline ops; given that these ops
are going to be compiled at Perl build time (they can never be
dynamically loaded for obvious reasons), we can manually put any
required #includes in interpreter.c. Files containing dynamically-
loaded ops can be generated in the same way that process_opcodes.pl
does now, preserving the file-scope code.
Another approach would be to include a means of defining information
that must be included by the file implementing the ops. For example:
HEADER {
#include math.h
}
This would then be placed into interp_guts.h. (Possibly surrounded
by a conditional guard (#ifdef PARROT_OP_IMPLEMENTATION), so no file
other than interpreter.h will pick up that code.)
- Damien
Re: Parrot multithreading?
What we're going to do is fire up a new interpreter for each thread. (We may have a pool of prebuilt interpreters hanging around for this eventuality) Threading *is* essential at the parrot level, and there are even a few (as yet undocumented) opcodes to deal with them, and some stuff that's an integral part of the variable vtable code to deal with it. Whether it's considered ithread-like or not's up in the air--it'll probably look a lot like a mix. I'm also seriously considering throwing *all* PerlIO code into separate threads (one per file) as an aid to asynchrony. Just remember the cost in context-switching, plus the lack of scalability as the number of file-handles increases. Linux thread-context-switches are relatively brutal compared to say Solaris. Additionally you're consuming a new stack area for each file-handle. That's lots of overhead. There are bound to be semi-portable methods of non-blocking IO. UNIX-select has to have an equiv on NT. Granted it's a lot more complicated. Basically you could have IO ops trigger an event-based iThread swap, which causes select to be invoked. I've always thought this was the most efficient model for single-CPU machines. The biggest problem was always segmenting one's code into call-backs. Well, with op-codes, we have a natural division. We have a tight inner loop that occasionally hits a dispatcher on a complexity level similar to a GUI. You're much better prone to handle event-based operations (which means higher level languages can be built atop such a parrot-design). Food for thought. -Michael
Re: Vague Heads-up
At 02:21 PM 9/20/2001 -0400, Andy Dougherty wrote: On Thu, 20 Sep 2001, Dan Sugalski wrote: At 04:38 PM 9/20/2001 +0100, Simon Cozens wrote: On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote: I don't want to do int-pointer casts anywhere in the source if we can possibly avoid it. Yech. In which case, do we *need* a type that can hold both. I can't think of a reason, no. I don't promise that a reason doesn't exist, however. :) Well, the following (macro-expanded) line in register.c tries to go both ways: chunk_base = (void *)(0xf000 (IV) interpreter-int_reg ) ; True. That's one of the really evil bits, though. (As is a good chunk of memory.c...) I only yanked in IV as a typecast as a convenience, and it really ought to be something else. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: void*
At 01:06 PM 9/20/2001 -0700, Robert Spier wrote: Dan, Could you explain again why you don't want char* anywhere, and prefer void*? Because for character data we're not sure char * is right. (Might be wchar_t, __int16, __int32, or something else) It's also to shake off the Oh, it's character data! I can use the string.h functions! reaction. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Draft switch for DO_OP() :-)
At 01:08 PM 9/20/2001 -0700, Damien Neil wrote:
Another approach would be to include a means of defining information
that must be included by the file implementing the ops. For example:
HEADER {
#include math.h
}
This would then be placed into interp_guts.h. (Possibly surrounded
by a conditional guard (#ifdef PARROT_OP_IMPLEMENTATION), so no file
other than interpreter.h will pick up that code.)
I like that approach. I'd say go for it--got time to put this in?
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: void*
Quoting Dan Sugalski [EMAIL PROTECTED]: Could you explain again why you don't want char* anywhere, and prefer void*? Because for character data we're not sure char * is right. (Might be wchar_t, __int16, __int32, or something else) It's also to shake off the Oh, it's character data! I can use the string.h functions! reaction. That makes sense. But, why not a type named parrotchar (or similar) (which may end up resolving to void)? It just seems like the use of the explicit 'void' type may trip us up later, and we might as well use as much of the typing capabilities of C as we can. -R
Re: Parrot multithreading?
On Thu, Sep 20, 2001 at 04:13:48PM -0400, Michael L Maraist wrote: What we're going to do is fire up a new interpreter for each thread. (We may have a pool of prebuilt interpreters hanging around for this eventuality) Threading *is* essential at the parrot level, and there are even a few (as yet undocumented) opcodes to deal with them, and some stuff that's an integral part of the variable vtable code to deal with it. Whether it's considered ithread-like or not's up in the air--it'll probably look a lot like a mix. I'm also seriously considering throwing *all* PerlIO code into separate threads (one per file) as an aid to asynchrony. Just remember the cost in context-switching, plus the lack of scalability as the number of file-handles increases. Linux thread-context-switches are relatively brutal compared to say Solaris. Additionally you're consuming a new stack area for each file-handle. That's lots of overhead. One idea I haven't seen mentioned is have a fixed number of system threads to service a potentially larger pool of parrot interpreters. Essentially, physical threads become execution pipelines for the virtual machine. The limit on system threads can be tuned to optimally spread execution across available CPUs. It could be as small as 1 on single-processor systems that don't switch thread contexts well. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
RE: Parrot multithreading?
At 12:33 PM 9/20/2001 -0700, Hong Zhang wrote: DS I'm also seriously considering throwing *all* PerlIO code into separate DS threads (one per file) as an aid to asynchrony. but that will be hard to support on systems without threads. i still have that internals async i/o idea floating in my numb skull. it is an api that would look async on all platforms and will use the kernel async file i/o if possible. it could be made thread specific easily as my idea was that the event system was also thread specific. I think we should have some thread abstraction layer instead of throwing PerlIO into threads. The thread abstraction layer can use either native thread package (blocking io), or implement user level thread package with either non-blocking io or async io. I did say I was seriously considering it, not that I was going to do it. We may well just throw the PerlIO stuff (at least anything with a filter) into separate interpreters rather than separate threads. We'll see. The internal io should be sync instead of async. Nope. Internal I/O, at least as the interpreter will see it is async. You can build sync from async, it's a big pain to build async from sync. Doesn't mean we actually get asynchrony, just that we can. async is normally slower than sync (most of unix don't have real async io), and thread is cheap. Just because some systems have a really pathetic I/O system doesn't mean we should penalize those that don't... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot multithreading?
At 04:36 PM 9/20/2001 -0400, Rocco Caputo wrote: On Thu, Sep 20, 2001 at 04:13:48PM -0400, Michael L Maraist wrote: What we're going to do is fire up a new interpreter for each thread. (We may have a pool of prebuilt interpreters hanging around for this eventuality) Threading *is* essential at the parrot level, and there are even a few (as yet undocumented) opcodes to deal with them, and some stuff that's an integral part of the variable vtable code to deal with it. Whether it's considered ithread-like or not's up in the air--it'll probably look a lot like a mix. I'm also seriously considering throwing *all* PerlIO code into separate threads (one per file) as an aid to asynchrony. Just remember the cost in context-switching, plus the lack of scalability as the number of file-handles increases. Linux thread-context-switches are relatively brutal compared to say Solaris. Additionally you're consuming a new stack area for each file-handle. That's lots of overhead. One idea I haven't seen mentioned is have a fixed number of system threads to service a potentially larger pool of parrot interpreters. Essentially, physical threads become execution pipelines for the virtual machine. The limit on system threads can be tuned to optimally spread execution across available CPUs. It could be as small as 1 on single-processor systems that don't switch thread contexts well. That adds a level of complexity to things that I'd as soon avoid. On the other hand there's no reason we can't add it in later. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot multithreading?
At 01:53 PM 9/20/2001 -0700, Damien Neil wrote: On Thu, Sep 20, 2001 at 04:38:57PM -0400, Dan Sugalski wrote: Nope. Internal I/O, at least as the interpreter will see it is async. You can build sync from async, it's a big pain to build async from sync. Doesn't mean we actually get asynchrony, just that we can. For clarification: do you mean async I/O, or non-blocking I/O? Async. When the interpreter issues a read, for example, it won't assume the read completes immediately. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Parrot multithreading?
Nope. Internal I/O, at least as the interpreter will see it is async. You can build sync from async, it's a big pain to build async from sync. Doesn't mean we actually get asynchrony, just that we can. It is trivial to build async from sync, just using thread. Most Unix async are built this way, using either user level thread or kernel level thread. Win32 has really async io implementation, but it does not interact well with sync io. Just because some systems have a really pathetic I/O system doesn't mean we should penalize those that don't... Implement sync on top of async is also slower. I bet most people will use sync io, not async one. There is no need to build async io from sync, the async can be provided using separate module. It is not about some systems, it is about most systems. Very few systems have high performance async io implementation. And the semantics is not very portable. I am not sure if interpreter has to choose one over the other. The interpreter could support both interface, and use as needed. Hong
Name lengths in C code
Just a reminder--function names shouldn't exceed 31 characters. The C standard doesn't guarantee anything past that... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot multithreading?
DN == Damien Neil [EMAIL PROTECTED] writes: DN On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote: For clarification: do you mean async I/O, or non-blocking I/O? Async. When the interpreter issues a read, for example, it won't assume the read completes immediately. DN That sounds like what I would call non-blocking I/O. Async I/O DN would involve syscalls like aio_read(). you can't do non-blocking i/o on files without aio_read type calls. but what dan is saying is that the api the interpreter uses internally will be an async one. it will either use native/POSIX aio calls or simulate that with sync calls and callbacks or possibly with threads. DN I'm being a bit pedantic here because I've been involved in heated DN debates in the past, which were resolved when the two sides realized DN that they were using different definitions of async I/O. : pipe, socket and char device async i/o is different from file async i/o. with pipes you are told when your request will work and then you make it. with files you make the request and then get told when it was done. both use callbacks and can be integrated under one async api. this api is what parrot will see and a sync api will be layered on top of this. the async i/o will be tied to the event system for timeouts and safe signals and such. 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: Name lengths in C code
On Thu, Sep 20, 2001 at 05:09:52PM -0400, Dan Sugalski wrote: Just a reminder--function names shouldn't exceed 31 characters. The C standard doesn't guarantee anything past that... You think that's bad? You aren't guaranteed more than six characters, case-insensitive for external identifiers. I've been told that Oracle actually requires conformance to this in their coding standards. I'm very happy that I don't have to write code for Orcale... - Damien
_read = read
test_main.c still seems to contain a call to _read(), rather than read(). This breaks compilation under Tru64 for me; the attached patch removes the _. - Damien Index: test_main.c === RCS file: /home/perlcvs/parrot/test_main.c,v retrieving revision 1.11 diff -u -r1.11 test_main.c --- test_main.c 2001/09/18 21:03:27 1.11 +++ test_main.c 2001/09/20 21:17:44 @@ -94,7 +94,7 @@ #ifndef HAS_HEADER_SYSMMAN program_code = (opcode_t*)mem_sys_allocate(program_size); -_read(fd, (void*)program_code, program_size); +read(fd, (void*)program_code, program_size); #else program_code = (opcode_t*)mmap(0, program_size, PROT_READ, MAP_SHARED, fd, 0); #endif
Re: SV: Parrot multithreading?
Arthur Bergman wrote: Arthur Bergman wrote: In an effort to rest my braine from a coredumping perl5 I started to think a bit on threading under parrot? While it has been decided that perl should be using ithread like threading, I guess that is irelevant at the parrot level. Are you going to have one virtual cpu per thread with it's own set of registers or are you going to context switch the virtual cpu? If it was one virtual cpu per thread then one would just create a new virtual cpu and feed it the bytecode stream? Is there anything I could help with regarding this? Arthur The context is almost identical to that of Perl5's MULTIPLICITY which passes the perl-interpreter to each op-code. Thus there is inherent support for multiple ithread-streams. In the main-loop (between each invoked op-code) there is an event-checker (or was in older versions at any rate). It doesn't do anything yet, but it would make sence to assume that this is where context-switches would occur, which would simply involve swapping out the current pointer to the perl-context; A trivial matter. Uhm, are you talking perl 5 here? The event checker checks for signals, we got safe signals now. There wasn't any code for CHECK_EVENTS w/in Parrot when I first read the source-code. I merely assumed that it's role was not-yet determined, but considered the possible uses. CHECK_EVENTS seems to be gone at the moment, so it's a moot point. MULTIPLICITY is just allowing multiple interpreters, ithreads is letting them run at the same time and properly clone them. If you want to use it switch interpreters at runtime for fake threads, patches are welcome, send it and I will apply it. The easiest threading model I can think of would be to have a global var called next_interpreter which is always loaded in the do-loop. An asynchronous timer (or event) could cause the value of next_interpreter to be swapped. This way no schedule function need be checked on each operation. The cost is that of an extra indirection once per op-code. True MT code simply has each thread use it's own local interpreter instance. MT-code is problematic with non MT-safe extensions (since you can't enforce that). I am sorry to say, but perl 5 is true MT. Yes, but that feature never got past being experimental. I know of a couple DBDs that would not let you compile XS code with MT enabled since they weren't MT-safe. The interpreter can be built MT-safe (java is a good example), but extensions are always going to be problematic. (Especially when many extensions are simply wrappers around existing non-MT-aware APIs). I think a good solution to them would be to tread it like X does (which says you can only run X-code w/in the main-thread). An extension could say whether it was MT-safe or not, and be forced to be serialized w/in the main-physical-thread, which becomes the monitoring thread. An alternative would be to simply have XS code compile in a flag which says to throw an exception if the code is run outside of the main-thread; Documentation would emphatically state that it's up to the user to design the system such that only the main-thread calls it. On the side, I never understood the full role of iThreads w/in perl 5.6. As far as I understood, it was merely used as a way of faking fork on NT by running multiple true-threads that don't share any globals. I'd be curious to learn if there were other known uses for it. In iThread, you don't have a problem with atomic operations, but you can't take advantage of multiple CPUs nor can you garuntee prevention of IO-blocking (though you can get sneaky with UNIX-select). Where did you get this breaking info? ithread works with multiple CPUs and IO blocking is not a problem. Arthur I'm under the impression that the terminology for iThreads assumes an independance of the physical threading model. As other posters have noted, there are portability issues if we require hardware threading. Given the prospect of falling back to fake-threads, then multi-CPU and IO blocking is problematic; though the latter can be avoided / minimized if async-IO is somehow enforced. From my scarce exposure to the Linux Java movement, green-threads were considered more stable for a long time, even though the porters were just trying to get things to work on one platform. I would definately like hardware threading to be available. If nothing else, it lets students taking Operating Systems to experiment with threading w/o all the headaches of c. (Granted there's Java, but we like perl) However, I'm not convinced that threading won't ultimately be restrictive if used for generation operation (such as for the IO-subsystem). I'm inclined to believe that threading is only necessary when the user physically wants it (e.g. requests it), and that in many cases fake-threads fulfill the basic desires of everyone involved
Re: SV: Parrot multithreading?
At 05:23 PM 9/20/2001 -0400, Michael L Maraist wrote: There wasn't any code for CHECK_EVENTS w/in Parrot when I first read the source-code. I merely assumed that it's role was not-yet determined, but considered the possible uses. CHECK_EVENTS seems to be gone at the moment, so it's a moot point. There probably won't be any. The current thinking is that since the ops themselves will be a lot smaller, we'll have an explicit event checking op that the compiler will liberally scatter through the generated code. Less overhead that way. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot multithreading?
At 02:04 PM 9/20/2001 -0700, Damien Neil wrote: On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote: For clarification: do you mean async I/O, or non-blocking I/O? Async. When the interpreter issues a read, for example, it won't assume the read completes immediately. That sounds like what I would call non-blocking I/O. Async I/O would involve syscalls like aio_read(). Might sound that way, but it isn't. What I'm talking about is something like: READ S3, P1, I0 X: SLEEP 3 EQ I0, 0, X PRINT S3 Where we issue the read on the filehandle in P1, telling it to store the results in S3, and put the completion status in I0. The sleep will presumably be replaced by code that actually does something, and we wait as long as the completion register says we're not done. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: instructions per second benchmark (in parrot ;)
At 04:54 PM 9/20/2001 -0500, Brian Wheeler wrote: Since all benchmarks are crap anyway, I've written a test which tells the average number of instructions per second. On my athlon 700 I get 3966053 instructions per second and on my PIII 866 I get 5081485 instructions per second. Do those sound like reasonable numbers? Of course, since time_i is one of the opcodes looped, it probably brings the numbers down. That's actually what test.pasm tests. :) I just checked in a new version that prints labels. FWIW, my 600MHz Alpha clocks in at around 23M ops/sec. Nyah! ;-P Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: instructions per second benchmark (in parrot ;)
On Thu, 2001-09-20 at 16:46, Dan Sugalski wrote: At 04:54 PM 9/20/2001 -0500, Brian Wheeler wrote: Since all benchmarks are crap anyway, I've written a test which tells the average number of instructions per second. On my athlon 700 I get 3966053 instructions per second and on my PIII 866 I get 5081485 instructions per second. Do those sound like reasonable numbers? Of course, since time_i is one of the opcodes looped, it probably brings the numbers down. That's actually what test.pasm tests. :) I just checked in a new version that prints labels. Yeah, I realized that _as soon as I posted it_. Doh! Heheh, for the longest time I thought test.pasm just did stuff for a while. Anyway, it started out as an implementation of the bogomips.c program and slowly became this. FWIW, my 600MHz Alpha clocks in at around 23M ops/sec. Nyah! ;-P I get 10M ops/sec on the Athlon 700 using test.pasm. time_i is a killer, especially judging by the difference in cpu usage (test.pasm is nearly 100% user, and mine is 75/25 user/system) The 866 machine gets 15M. Maybe when/if I get my 1.26GHz machine at work I'll be able to match you :) Brian Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: instructions per second benchmark (in parrot ;)
On Thu, Sep 20, 2001 at 04:54:21PM -0500, Brian Wheeler wrote: Since all benchmarks are crap anyway, I've written a test which tells the average number of instructions per second. On my athlon 700 I get 3966053 instructions per second and on my PIII 866 I get 5081485 instructions per second. Do those sound like reasonable numbers? Of course, since time_i is one of the opcodes looped, it probably brings the numbers down. 1.59 MIPS here. 1.77 if I shut off the mp3 player. :) G3/266. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One mendel ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN sChWErn ScHWeRn schweRn sCHWErN schWeRnscHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern scHWerNscHWeRn scHWerNScHwerN SChWeRN scHWeRn SchwERNschwERnSCHwern sCHWErN SCHWErN sChWeRn
Re: instructions per second benchmark (in parrot ;)
On Thu, Sep 20, 2001 at 11:52:50PM +0100, Tom Hughes wrote: I have test.pasm reporting 7.14M ops/sec on a 200MHz K6 running linux with the interpreter compiled -O3. That's about twice the speed that I get without any optimisation. Oh, right. Optimization. I'm getting 2.67 MIPS with -O3. Hmmm, why would a K6/200 come out so much faster than a G3/266? If anything it should be the other way around. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Jesus hates me. http://www.unamerican.com/
Re: SV: Parrot multithreading?
DS == Dan Sugalski [EMAIL PROTECTED] writes: DS There probably won't be any. The current thinking is that since DS the ops themselves will be a lot smaller, we'll have an explicit DS event checking op that the compiler will liberally scatter through DS the generated code. Less overhead that way. we talked about that solution before and i think it has some problems. what if someone writes a short loop. will it generate enough op codes that a check_event one is emitted? do we always emit one in loops? 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. or of course, go with an event loop style dispatcher but then the perl level programs need to be written for that style. 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 multithreading?
DS == Dan Sugalski [EMAIL PROTECTED] writes: DS Might sound that way, but it isn't. What I'm talking about is DS something like: DS READ S3, P1, I0 DS X: SLEEP 3 DS EQ I0, 0, X DS PRINT S3 DS Where we issue the read on the filehandle in P1, telling it to DS store the results in S3, and put the completion status in I0. The DS sleep will presumably be replaced by code that actually does DS something, and we wait as long as the completion register says DS we're not done. and internally tha READ op will do an aio_read if it is supported on this platform. the sleep op is like wait in pdp-11 assembler. there you could wait for interrupts to wake you up. that sleep op needs to do a blocking operation like poll/select so it can release the cpu for other threads/processes. it will be woken up by a signal that the file async i/o is done a variation is to have a WAIT op which waits for a particular io handle to be done. it also will do some blocking select/poll call and let itself be woken up as above. but it will check for its i/o being done and go back to blocking sleep if it is not completed. so you can issue an async i/o request anytime and sync up with it (with WAIT) later when you want the data. this model was in RT-11 30 years ago and it works well. you can have async and sync i/o with a simple set of ops, READ, WRITE and WAIT. we could also have a WAIT with a wild card arg too. it waits for any completion of i/o and then other parrot code must check for what has completed and deal with 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
[PATCH] Fixed typo in Configure.pl
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.11
diff -u -r1.11 Configure.pl
--- Configure.pl2001/09/20 13:35:26 1.11
+++ Configure.pl2001/09/20 19:49:03
@@ -105,7 +105,7 @@
unless( $c{debugging} ) {
$c{ld_debug} = ' ';
- $c{cc_denug} = ' ';
+ $c{cc_debug} = ' ';
}
print END;
Stefan
__
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/
Re: Tru64
On Thu, Sep 20, 2001 at 09:06:12AM -0500, Gibbs Tanton - tgibbs wrote: Failed 1/5 test scripts, 80.00% okay. 7/74 subtests failed, 90.54% okay. make: *** [test] Error 2 Damien, is there any way we could get a similar fix for number.t? That would make us at 100% on Tru64. I'm currently getting segfaults on all tests on Tru64; I'll look into it if I get a chance, but I may not have time for a few days. (I'm flying to Connecticut for a friend's wedding tomorrow morning.) - Damien
[PATCH] Fix ivsize and nvsize issues
Okay, this fixes the issues with changing your IV or NV size. It also
provides an early warning if your C compiler settings aren't okay. I've
also made the style of the code a little more consistent. I'm applying
this, but I figure people might as well check it over anyway.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- ..\..\parrot-cvs\parrot\Configure.plThu Sep 20 21:14:30 2001
+++ Configure.plThu Sep 20 21:24:56 2001
@@ -6,9 +6,10 @@
use strict;
use Config;
use Getopt::Long;
+use ExtUtils::Manifest qw(manicheck);
-my( $opt_debugging, $opt_defaults, $opt_version, $opt_help ) = ( 0, 0,
0, 0 );
-my( %opt_defines );
+my($opt_debugging, $opt_defaults, $opt_version, $opt_help) = (0, 0, 0,
0);
+my(%opt_defines);
my $result = GetOptions(
'debugging!' = \$opt_debugging,
'defaults!' = \$opt_defaults,
@@ -17,12 +18,12 @@
'define=s' = \%opt_defines,
);
-if( $opt_version ) {
+if($opt_version) {
print '$Id: Configure.pl,v 1.12 2001/09/21 01:43:50 brentdax Exp
$' . \n;
exit;
}
-if( $opt_help ) {
+if($opt_help) {
print EOT;
$0 - Parrot Configure
Options:
@@ -54,39 +55,43 @@
complete Parrot kit.
END
-#check_manifest();
+check_manifest();
#Some versions don't seem to have ivtype or nvtype--provide
#defaults for them.
#XXX Figure out better defaults
my(%c)=(
iv = ($Config{ivtype} ||'long'),
-ivsize = ($Config{ivsize} || 4 ),
-longsize = ($Config{longsize} || 4 ),
+ ivsize = undef,
+
nv = ($Config{nvtype} ||'double'),
-nvsize = ($Config{nvsize} || 8 ),
-opcode_t = ($Config{ivtype} ||'long'),
+ nvsize = undef,
+
+ opcode_t = ($Config{ivtype} ||'long'),
+ longsize = undef,
+
cc = $Config{cc},
#ADD C COMPILER FLAGS HERE
ccflags = $Config{ccflags}. -I./include,
libs = $Config{libs},
- perl = $^X,
cc_debug = '-g',
o ='.o', # object files extension
exe = $Config{_exe},
+
ld = $Config{ld},
ld_out = '-o ', # ld output file
ld_debug = '', # include debug info in
executab
le
+
+ perl = $^X,
debugging =$opt_debugging,
);
-foreach my $i ( keys %opt_defines ) {
- $c{$i} = $opt_defines{$i};
-}
+#copy the things from --define foo=bar
+@c{keys %opt_defines}=@opt_defines{keys %opt_defines};
# set up default values
-my $hints = hints/ . lc( $^O ) . .pl;
-if( -f $hints ) {
+my $hints = hints/ . lc($^O) . .pl;
+if(-f $hints) {
local($/);
open HINT, $hints or die Unable to open hints file
'$hints';
my $hint = HINT;
@@ -123,6 +128,17 @@
print END;
+Alright, now I'm gonna check some stuff by compiling and running
+a small C program. This could take a bit...
+END
+
+buildfile(test_c);
+system($c{cc} $c{ccflags} -o test$c{exe} test.c) and die C compiler
died!;
+(@c{qw(ivsize opsize nvsize)})=split('/', `test$c{exe}`);
+unlink('test.c', test$c{exe});
+
+print END;
+
Okay, that's finished. I'm now going to write your very
own Makefile, config.h, and Parrot::Config to disk.
END
@@ -208,36 +224,29 @@
$text =~ s/#DUMPER OUTPUT HERE/$dd-Dump()/eg;
- mkdir(Parrot, 0777) or ( $! =~ /File exists/i or die Can't
make direc
tory ./Parrot: $!);
open(OUT, Parrot/Config.pm) or die Can't open file
Parrot/Config.pm:
$!;
print OUT $text;
close(OUT) or die Can't close file Parrot/Config.pm: $!;
}
sub check_manifest {
- my $not_ok;
- open(MANIFEST, MANIFEST);
+ print \n;
- while(MANIFEST) {
- chomp;
- unless(-e $_) {
- print File $_ is missing!\n;
- $not_ok=1;
- }
- }
+ my(@missing)=manicheck();
- if($not_ok) {
+ if(@missing) {
print END;
Ack, some files were missing! I can't continue running
without everything here. Please try to find the above
files and then try running Configure again.
+
END
+
exit;
}
else {
print END;
-
Okay, we found everything. Next you'll need to answer
a few questions about your system. Rules are the same
as Perl 5's Configure--defaults are in square brackets,
--- /dev/null Wed Dec 31 16:00:00 1969
+++ test_c.in Thu Sep 20 21:12:32 2001
@@ -0,0 +1,13 @@
+/*
+ * test.c - figure out some Configure settings
+ *
+ * This file is automatically generated by Configure
+ * from test_c.in.
+ */
+
+#include stdio.h
+
+int main(int argc, char **argv) {
+ printf(%d/%d/%d, sizeof(${iv}), sizeof(long), sizeof(${nv}));
+
RE: _read = read
Damien Neil: # test_main.c still seems to contain a call to _read(), rather than # read(). This breaks compilation under Tru64 for me; the attached # patch removes the _. Since this (I think) has been submitted multiple times and never applied (and no reason was given for not applying), I've applied it myself. Thanks, Damien. --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
Re: Parrot Smoke Sep 20 00:00:02 2001 MSWin32 4.0
[EMAIL PROTECTED] (Mattia Barbon) writes: Automated smoke report for patch Sep 20 00:00:02 2001 I've changed the .timestamp file to be UTC and include that information. -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: [PATCH] Fix ivsize and nvsize issues
[EMAIL PROTECTED] (Brent Dax) writes:
+(@c{qw(ivsize opsize nvsize)})=split('/', `test$c{exe}`);
I changed this so it works without having . in $PATH.
- ask
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
