RE: thread vs signal
On Sun, 30 Sep 2001, Hong Zhang wrote: How does python handle MT? Honestly? Really, really badly, at least from a performance point of view. There's a single global lock and anything that might affect shared state anywhere grabs it. One way to reduce sync overhead is to make more operation atomic instead of of sync. For example, read() write() are atomic. There is no need to sync stream. The array get/put are atomic in Java, so we don't need sync either. The high level library or app itself will be responsible for the sync. Now how do you go about performing an atomic operation in MT? I understand the desire for reentrance via the exclusive use of local variables, but I'm not quite sure how you can enforce this when many operations are on shared data (manipulating elements of the interpreter / global variables). I definately agree that locking should be at a high level (let them core if they don't obey design it well). I liked the perl5 idea that any scalar / array / hash could be a mutex. Prevents you from having to carry around lots of extra mutex-values. We can achieve the exact same synchronization policy of java or one that's finer tuned for performance. -Michael
[PATCH] Parrot Bytecode -- C compiler (works with new PackFile,etc.)
All --
Here's an updated version of my Parrot Bytecode -- C compiler. I've
updated it to work in the context of the latest commits.
NOTE: The only existing file that is modified by this patch is
MANIFEST (to add the two new files), so there's little impact on
your sandbox if you are testing other stuff for 0.0.2 release.
Here's a sample run to give you an idea of the performance boost:
$ assemble.pl t/test.pasm t/test.pbc
$ test_prog t/test.pbc
Iterations: 1
Start time: 1001943537
End time: 1001943590
Count: 1
Elapsed time:53
Estimated ops:3
Estimated ops (numerically):3.00
Elapsed time:53
Elapsed time:53.00
Ops/sec:5660377.358491
$ cc -o t/test.o -c -I ./include t/test.c
$ # I Don't know why I had to link packfile.o here...
$ cc -o t/test -L . -lparrot t/test.o packfile.o
$ export LD_LIBRARY_PATH=.
$ t/test
Iterations: 1
Start time: 1001943640
End time: 1001943644
Count: 1
Elapsed time:4
Estimated ops:3
Estimated ops (numerically):3.00
Elapsed time:4
Elapsed time:4.00
Ops/sec:7500.00
$
So, 5.7 Mop/s -- 75.0 Mop/s. That's pretty good!
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
\_/
? typescript
? compiler.patch
? gmon.out
? test_prog-old.prof
? t/test
? t/test.c
Index: MANIFEST
===
RCS file: /home/perlcvs/parrot/MANIFEST,v
retrieving revision 1.23
diff -a -u -r1.23 MANIFEST
--- MANIFEST2001/09/30 20:25:22 1.23
+++ MANIFEST2001/10/01 13:41:16
@@ -4,6 +4,7 @@
Makefile.in
Parrot/Assembler.pm
Parrot/Opcode.pm
+Parrot/OpFunc.pm
Parrot/PackFile.pm
Parrot/PackFile/ConstTable.pm
Parrot/PackFile/Constant.pm
@@ -53,6 +54,7 @@
opcode_table
packfile.c
parrot.c
+parrotc
pdump.c
process_opfunc.pl
register.c
Index: parrotc
===
RCS file: parrotc
diff -N parrotc
--- /dev/null Mon Oct 1 05:34:59 2001
+++ parrotc Mon Oct 1 06:41:16 2001
@@ -0,0 +1,327 @@
+#! /usr/bin/perl -w
+#
+# compile.pl
+#
+# Turn a parrot bytecode file into text.
+#
+# Copyright (C) 2001 The Parrot Team. All rights reserved.
+# This program is free software. It is subject to the same license
+# as the Parrot interpreter.
+#
+# $Id: $
+#
+
+use strict;
+
+use Parrot::Opcode;
+use Parrot::PackFile;
+use Parrot::PackFile::ConstTable;
+use Parrot::OpFunc;
+
+use Data::Dumper;
+$Data::Dumper::Useqq = 1;
+$Data::Dumper::Terse = 1;
+$Data::Dumper::Indent = 0;
+
+Parrot::OpFunc-init('basic_opcodes.ops');
+
+#
+# GLOBAL VARIABLES:
+#
+
+my %unpack_type = (i = 'l',
+ I = 'l',
+ n = 'd',
+ N = 'l',
+ D = 'l',
+ S = 'l',
+ s = 'l',
+ );
+my %unpack_size = (i = 4,
+ n = 8,
+ I = 4,
+ N = 4,
+ D = 4,
+ S = 4,
+ s = 4,
+ );
+
+my %opcodes= Parrot::Opcode::read_ops();
+my $opcode_fingerprint = Parrot::Opcode::fingerprint();
+my @opcodes;
+for my $name (keys %opcodes) {
+$opcodes[$opcodes{$name}{CODE}] = { NAME = $name,
+ %{$opcodes{$name}} };
+}
+
+
+#
+# dump_const_table()
+#
+
+sub dump_const_table {
+my ($pf) = @_;
+
+my $count = $pf-const_table-const_count;
+
+if ($count 1) {
+ warn Disassembling without opcode table fingerprint!;
+ return;
+}
+
+die Cannot compile (differing opcode table)!
+if $pf-const_table-constant(0)-data ne $opcode_fingerprint;
+
+print # Constants: $count entries\n;
+print # ID FlagsEncoding Type Size Data\n;
+
+my $constant_num = 0;
+
+foreach ($pf-const_table-constants) {
+printf(%04x: %08x %08x %08x %08x %s\n,
+ $constant_num, $_-flags, $_-encoding, $_-type,
+$_-size, $_-data);
+
+ $constant_num++;
+}
+}
+
+
+#
+# compile_byte_code()
+#
+
+sub compile_byte_code {
+my ($pf) = @_;
+my $pc;
+my $new_pc = 1;
+my $op_size;
+
+my $nconst = $pf-const_table-const_count;
+
+print END_C;
+#include parrot/parrot.h
+#include parrot/string.h
+#include math.h
+
+int
+main(int argc, char **argv) {
+inti;
+struct Parrot_Interp * interpreter;
+struct PackFile_Constant * c;
+struct PackFile * pf;
+
+init_world();
+
+interpreter = make_interpreter();
+pf
Re: [PATCH] Bad cast
On Monday 01 October 2001 08:20 am, Gibbs Tanton - tgibbs wrote: Casting to IV doesn't actually hurt anything (unless there is an alignment issue); however, casting to char* is the more idiomatic way of doing it. I'll commit this unless Simon says he is going to handle it in The Great Renaming. Casting from a pointer to a non-pointer and back isn't guaranteed. (The only non-pointer guaranteed to be safely cast to a pointer is '0', although I'll admit I can't find a platform where any of this is an issue. For me, though, it was more of a size issue. An IV isn't necessarily the same size as a pointer.) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: [PATCH] Bad cast
On Monday 01 October 2001 08:36 am, Simon Cozens wrote: On Mon, Oct 01, 2001 at 07:20:56AM -0500, Gibbs Tanton - tgibbs wrote: Casting to IV doesn't actually hurt anything (unless there is an alignment issue); however, casting to char* is the more idiomatic way of doing it. I'll commit this unless Simon says he is going to handle it in The Great Renaming. Let me check it on Tru64 first. I'm basically trying to avoid char* in all its forms, but this is probably OK. /* Functions for handling strings in native byte format Native in this context means the equivalent of LANG=C: No fancy multi-byte stuff, this is plain old byte-at-a-time. But we don't make any assumptions about what those bytes *mean*. */ 'char' is C's byte type. (Well, most likely, unsigned char.) To avoid char * where void * is warranted is good. To avoid char * where char * is warranted is bad. If you're afraid of causing mental programmer problems with byte-wise data that isn't character data, then typedef u_char as byte. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Manifest constants?
On Monday 01 October 2001 10:29 am, Dan Sugalski wrote: Here's a list of manifest constants I think Parrot should know about. Anyone care to add to the list? '' (empty string) 0 1 undef NaN pi e epsilon (maybe) (+- infinity)? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: [Patch] fix docs in Parrot::Opcode
On Sat, Sep 29, 2001 at 12:08:20AM -0700, Josh Wilmes wrote: Here's a fixed version of that patch I sent a while back: Thanks, applied. -- A formal parsing algorithm should not always be used. -- D. Gries
Re: Manifest constants?
Dan -- Here's a list of manifest constants I think Parrot should know about. Anyone care to add to the list? '' (empty string) 0 1 undef NaN pi e epsilon (maybe) That brings up an interesting issue. The Ix registers initialize to zero, as do the Nx registers. These are valid values for those register types. However, the Sx registers initialize to NULL, which is not treated elsewhere (such as print_sc) as a valid string value. I think we need to either treat NULL as if it were an empty string everywhere, or we need to initialize string registers to proper empty string values. So, organized by type, we have: STRING:'' INTEGER: 0, 1 NUMBER:0.0, 1.0, pi, e, epsilon, NaN COOKIE:undef Now, I'm not sure what you mean when you say Parrot should know about these. Are you referring to special treatment in the assembler? Are you suggesting every const_table be initialized with these values? 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: Configure.pl *badly* wrong
On Wed, 26 Sep 2001, Andy Dougherty wrote:
I posted a patch last week to change the 'l' to a 'q', but more generally,
the assumption that sizeof(opcode_t) == sizeof(IV) should probably be
removed and each should be computed independently. Perhaps late today I'll
have a chance to do that if nobody beats me to it.
Nobody beat me to it :-).
The patch below (or something) is still needed. Otherwise, even a simple
perl5.7.2 Configure.pl --defaults
fails miserably for me on both Intel and Sparc. (My 5.7.2 is compiled with
ivsize=8, which means Configure.pl picks 'long long' for both IV and
opcode_t).
diff -r -u parrot/Configure.pl parrot-andy/Configure.pl
--- parrot/Configure.pl Sun Sep 23 10:50:48 2001
+++ parrot-andy/Configure.pl Wed Sep 26 15:55:59 2001
@@ -134,9 +134,10 @@
buildfile(test_c);
system($c{cc} $c{ccflags} -o test_siz$c{exe} test.c) and die C compiler died!;
-(@c{qw(ivsize longsize nvsize)})=split('/', `./test_siz$c{exe}`);
+(@c{qw(ivsize longsize nvsize opcode_t_size)})=split('/', `./test_siz$c{exe}`);
die Something wicked happened!
-unless defined $c{ivsize} and defined $c{longsize} and defined $c{nvsize};
+unless defined $c{ivsize} and defined $c{longsize} and
+defined $c{nvsize} and defined $c{opcode_t_size};
unlink('test.c', test_siz$c{exe}, test$c{o});
print END;
@@ -145,20 +146,23 @@
various Parrot internal types.
END
-my %pack_type;
+
# Alas perl5.7.2 doesn't have an IV flag for pack().
# The ! modifier only works for perl 5.6.x or greater.
-if (($] = 5.006) ($c{ivsize} == $c{longsize}) ) {
-$c{packtype_i} = 'l!';
-$c{packtype_op} = 'l!';
-}
-elsif ($c{ivsize} == 4) {
-$c{packtype_i} = 'l';
-$c{packtype_op} = 'l';
-}
-elsif ($c{ivsize} == 8) {
-$c{packtype_i} = 'q';
-$c{packtype_op} = 'l';
+foreach ('ivsize', 'opcode_t_size') {
+my $which = $_ eq 'ivsize' ? 'packtype_i' : 'packtype_op';
+if (($] = 5.006) ($c{$_} == $c{longsize}) ) {
+ $c{$which} = 'l!';
+}
+elsif ($c{$_} == 4) {
+ $c{$which} = 'l';
+}
+elsif ($c{$_} == 8) {
+ $c{$which} = 'q';
+}
+else {
+ die Configure.pl: Unable to find a suitable packtype for $_.\n;
+}
}
$c{packtype_n} = 'd';
diff -r -u parrot/test_c.in parrot-andy/test_c.in
--- parrot/test_c.in Sat Sep 22 21:03:59 2001
+++ parrot-andy/test_c.in Wed Sep 26 15:53:23 2001
@@ -8,7 +8,8 @@
#include stdio.h
int main(int argc, char **argv) {
- printf(%d/%d/%d, sizeof(${iv}), sizeof(long), sizeof(${nv}));
+ printf(%d/%d/%d/%d,
+ sizeof(${iv}), sizeof(long), sizeof(${nv}), sizeof(${opcode_t}));
return 0;
}
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
RE: thread vs signal
Now how do you go about performing an atomic operation in MT? I understand the desire for reentrance via the exclusive use of local variables, but I'm not quite sure how you can enforce this when many operations are on shared data (manipulating elements of the interpreter / global variables). There are two categories of global vars: ones used by runtime and ones used by app. For former, the runtime will use following schemes: 1) Reducing globals by using more per-thread variable (such as per thread profile info instead of per interpreter info). 2) Use atomic variable. Increment a profile counter does not need lock even it may ocationally corrected by one. 3) Use mutex as needed. I definately agree that locking should be at a high level (let them core if they don't obey design it well). I liked the perl5 idea that any scalar / array / hash could be a mutex. Prevents you from having to carry around lots of extra mutex-values. We can achieve the exact same synchronization policy of java or one that's finer tuned for performance. We can either let sv/av/hv carry mutex, or let them be atomic, although it is non-trivial to make them atomic. For languages like Smalltalk, it is trivial to make system atomic, since all complex data structure are user defined. Hong
RE: thread vs signal
On Sun, Sep 30, 2001 at 10:45:46AM -0700, Hong Zhang wrote: Python uses global lock for multi-threading. It is reasonable for io thread, which blocks most of time. It will completely useless for CPU intensive programs or large SMP machines. It might be useless in theory. In practice it isn't, because most CPU-intensive tasks are pushed down into C code anyway, and C code can release the single interpreter lock while it's crunching away. That does not mean Python is a high performance MT language. It just gives the problem to C. In that sense, every language is about to have the speed, since we can just write everything in C and call it, and we are blazing fast everywhere, .NET? Hong
RE: Manifest constants?
Wizard: # This was discussed to some extent on this list before (see RFC # http://dev.perl.org/rfc/263.pod). If parrot is expected to be # a JVM for # countless other languages, then it MUST (IMHO) understand the # concept of # NULL. Either that, or it must make allowances for the dynamic # inclusion of a # definition of NULL (whatever that might mean). What's the semantic difference between NULL and undef? --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
Re: PATCH process_opfunc.pl -- no more extra 'return's
On Oct 01, Simon Cozens [EMAIL PROTECTED] took up a keyboard and banged out On Mon, Oct 01, 2001 at 04:22:30PM -0400, Jason Gloudon wrote: It breaks manual ops like eq_i_ic since the generated code can return without returning a value. Yeah, I just noticed that myself. :) Retracting. Its also at least 2 weeks old, and obsoleted/made incompatible by lots of other stuff during that time, including opcode switch() stuff I'd sent to other commiters (presumably unused). Sigh. I'll stay on the sidelines. Michael Fischer -- Developer, Beware of bugs in the above code. [EMAIL PROTECTED] I have only proven it correct, not tested it. [EMAIL PROTECTED]-- Donald Knuth
RE: Manifest constants?
At 03:35 PM 10/1/2001 -0700, Brent Dax wrote: Wizard: # This was discussed to some extent on this list before (see RFC # http://dev.perl.org/rfc/263.pod). If parrot is expected to be # a JVM for # countless other languages, then it MUST (IMHO) understand the # concept of # NULL. Either that, or it must make allowances for the dynamic # inclusion of a # definition of NULL (whatever that might mean). What's the semantic difference between NULL and undef? NULL's used for tri-state logic. Current common place to see it's in SQL. Basically NULL's not equal (and not not equal) to everything. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Manifest constants?
At 10:32 AM 10/1/2001 -0400, Bryan C. Warnock wrote: On Monday 01 October 2001 10:29 am, Dan Sugalski wrote: Here's a list of manifest constants I think Parrot should know about. Anyone care to add to the list? '' (empty string) 0 1 undef NaN pi e epsilon (maybe) (+- infinity)? Yep. MAX_INT/MAX_FLOAT/MIN_INT/MIN_FLOAT too, I expect. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Manifest constants?
At 10:52 AM 10/1/2001 -0400, Gregor N. Purdy wrote: Dan -- Here's a list of manifest constants I think Parrot should know about. Anyone care to add to the list? '' (empty string) 0 1 undef NaN pi e epsilon (maybe) That brings up an interesting issue. The Ix registers initialize to zero, as do the Nx registers. These are valid values for those register types. However, the Sx registers initialize to NULL, which is not treated elsewhere (such as print_sc) as a valid string value. The registers shouldn't be assumed to initialize to anything. (I'll start stuffing 0xDEADBEEF in there if I have to... :) Only the PMC registers should go to a value, and that's only because it'll cause the GC fits if they don't. Now, I'm not sure what you mean when you say Parrot should know about these. Are you referring to special treatment in the assembler? Are you suggesting every const_table be initialized with these values? Basically these are constants that are known and provided to you by the interpreter. (So we can avoid people hand-rolling pi and e, amongst other things) I think we might end up with a get_manifest_constant opcode that takes a register and a known named constant, like so: get_manifest_constant N3, pi and looks up the constant from the table we build into parrot. Might want to hide that so that: set N3, pi automagically does the conversion. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Platform readiness reports
FreeBSD/x86 OK/OK Win32/x86 OK/NOK (report after my sig) Linux/IA64 OK/NOK (smoke report after my sig) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done. Win32/x86: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/stacks.t1 256 91 11.11% 5 t/op/time.t 1 256 21 50.00% 2 5 subtests skipped. Failed 2/8 test scripts, 75.00% okay. 2/99 subtests failed, 97.98% okay. Linux/IA64: Automated smoke report for patch Sep 24 19:00:02 2001 UTC v0.01 on linux using cc version 2.96-ia64-000717 snap 001117 O = OK F = Failure(s), extended report at the bottom ? = still running or test results not (yet) available Build failures during: - = unknown c = Configure, m = make, t = make test-prep Configuration --- --- - F F --defaults F F --defaults --define nv=double F F --defaults --define nv=\long double\ F F --defaults --define iv=long F F --defaults --define iv=long --define nv=double F F --defaults --define iv=long --define nv=\long double\ F F --defaults --define iv=\long long\ F F --defaults --define iv=\long long\ --define nv=double F F --defaults --define iv=\long long\ --define nv=\long double\ | | | +- --debugging +--- normal Failures: linux--defaults linux--debugging --defaults linux--defaults --define nv=double linux--debugging --defaults --define nv=double t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define nv=\long double\ linux--debugging --defaults --define nv=\long double\ t/op/integerdubious DIED. FAILED test 25 linux--defaults --define iv=long linux--debugging --defaults --define iv=long linux--defaults --define iv=long --define nv=double linux--debugging --defaults --define iv=long --define nv=double t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define iv=long --define nv=\long double\ linux--debugging --defaults --define iv=long --define nv=\long double\ t/op/integerdubious DIED. FAILED test 25 linux--defaults --define iv=\long long\ linux--debugging --defaults --define iv=\long long\ linux--defaults --define iv=\long long\ --define nv=double linux--debugging --defaults --define iv=\long long\ --define nv=double t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define iv=\long long\ --define nv=\long double\ linux--debugging --defaults --define iv=\long long\ --define nv=\long double\ t/op/integerdubious DIED. FAILED test 25
Re: BabyPerl 0.01
At 09:30 PM 9/30/2001 +0100, Simon Cozens wrote: On Sun, Sep 30, 2001 at 12:57:53PM -0700, Brent Dax wrote: That isn't quite valid Parrot bytecode, because of the concat. Concat is currently documented to take only two arguments. This is because concat is broken. I think I need a ruling from Dan on whether it should add to one string, or add two strings together. The implementation can be smart about checking the pointers coming in to optimize the latter to the former. Concat's three arg: cocnat sx, sy, sz It's OK to check and see if sx is either sy or sz and optimize accordingly. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Sizes, again.
At 11:28 AM 9/30/2001 -0400, Bryan C. Warnock wrote: On Sunday 30 September 2001 11:14 am, Gregor N. Purdy wrote: The stuff I'm about to check in that allows NVs to move to the constant table is set up to also allow IVs to live there, too. I haven't made the assembler and the ops do that yet, but it is possible. I thought we were going to have sizeof(IV) == sizeof(OP), and handle larger integers via PMCs. But if we are going to have the possiblity that sizeof(IV) != sizeof(OP), then we probably do need to move IV constants out of the bytecode stream. Well, we recently went to all the trouble to decouple opcodes from IVs - I assume for a reason. Do we want to undo that, or move them into the constant table? Nope. If you re-couple the sizes, then you're pretty much committing to 64-bit opcodes, since you'll invariably want 64-bit IVs on platforms that support it. We guarantee integer constants that are no bigger than 32 bits can be embedded in the opcode stream. Since opcode_t is at least 32 bits this is OK. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Report on Linux/PowerPC w/64 bits
Still getting a lot of smoke from Linux/PowerPC with 64 bit integers. Failed TestStatus Wstat Total Fail Failed List of Failed t/op/basic.t 2 512 52 40.00% 2, 4 t/op/bitwise.t 4 1024 44 100.00% 1-4 t/op/integer.t12 307226 12 46.15% 1-7, 21-24, 26 t/op/number.t 1 256251 4.00% 24 t/op/stacks.t 1 256 91 11.11% 1 t/op/string.t 1 256101 10.00% 2 5 subtests skipped. Failed 6/8 test scripts, 25.00% okay. 21/99 subtests failed, 78.79% okay. make: *** [test] Error 29 Here's the full make and test output: perl5.6.1 make_op_header.pl opcode_table include/parrot/op.h cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o test_main.o -c test_main.c cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o global_setup.o -c global_setup.c perl5.6.1 build_interp_starter.pl cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o interpreter.o -c interpreter.c cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o parrot.o -c parrot.c cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o register.o -c register.c register.c: In function `Parrot_push_i': register.c:22: warning: cast from pointer to integer of different size register.c:22: warning: cast to pointer from integer of different size register.c: In function `Parrot_pop_i': register.c:47: warning: cast from pointer to integer of different size register.c:47: warning: cast to pointer from integer of different size register.c: In function `Parrot_push_s': register.c:88: warning: cast from pointer to integer of different size register.c:88: warning: cast to pointer from integer of different size register.c: In function `Parrot_pop_s': register.c:116: warning: cast from pointer to integer of different size register.c:116: warning: cast to pointer from integer of different size register.c: In function `Parrot_push_n': register.c:157: warning: cast from pointer to integer of different size register.c:157: warning: cast to pointer from integer of different size register.c: In function `Parrot_pop_n': register.c:182: warning: cast from pointer to integer of different size register.c:182: warning: cast to pointer from integer of different size register.c: In function `Parrot_push_p': register.c:223: warning: cast from pointer to integer of different size register.c:223: warning: cast to pointer from integer of different size register.c: In function `Parrot_pop_p': register.c:250: warning: cast from pointer to integer of different size register.c:250: warning: cast to pointer from integer of different size perl5.6.1 process_opfunc.pl basic_opcodes.ops cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o basic_opcodes.o -c basic_opcodes.c cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o memory.o -c memory.c memory.c: In function `mem_allocate_aligned': memory.c:61: warning: cast from pointer to integer of different size memory.c:61: warning: cast from pointer to integer of different size memory.c:62: warning: cast from pointer to integer of different size memory.c:62: warning: cast to pointer from integer of different size cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o packfile.o -c packfile.c cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o string.o -c string.c cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o strnative.o -c strnative.c strnative.c: In function `string_native_concat': strnative.c:47: warning: cast from pointer to integer of different size strnative.c:47: warning: cast to pointer from integer of different size strnative.c: In function `string_native_substr': strnative.c:76: warning: cast from pointer to integer of different size strnative.c:76: warning: cast to pointer from integer of different size cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o test_prog global_setup.o interpreter.o parrot.o register.o basic_opcodes.o memory.o packfile.o string.o strnative.o test_main.o -lnsl -lgdbm -ldbm -ldb -ldl -lm -lc -lcrypt -lutil perl5.6.1 t/harness t/op/basic..# Failed test (Parrot/Test.pm at line 74) # got: '268578272' # expected: '1' # Failed test (Parrot/Test.pm at line 74) # got: '268578272' # expected: '42' # Looks like you failed 2 tests of 5. dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 2, 4 Failed 2/5 tests,
RE: thread vs signal
At 10:45 AM 9/30/2001 -0700, Hong Zhang wrote: The same story may happen to Perl. If Perl make all operations on SV, AV, HV sync, the performance will be pathetic. Many SMP machines can only perform about 10M sync operations per second, because sync op requires system-wide bus lock or global memory transaction. This situation will not change much in the future. Only variables marked as shared will get locked, the rest won't. Each thread'll get its own interpreter, so there shouldn't be much at all in the way of global resources to go locking on, if we do things properly. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] Constant Access Macros
At 03:27 PM 10/1/2001 +0100, Simon Cozens wrote: On Mon, Oct 01, 2001 at 10:23:11AM -0400, Jason Gloudon wrote: What about the current macros for NUM_REG etc ? I'd probably rip 'em out too. Stops people accidentally hand hacking the .c file instead of the .ops file and then losing all their changes on rebuild. Not that I've ever done that trick, of course. :) Ripping 'em out when processing's fine, as long as they can stay in the .ops files. ;) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Linux/PowerPC w/o 64bits a-ok
Debian Linux/PowerPC without 64 bit integers tests out 100% ok. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Let's face it, said bearded Rusty Simmons, opening a can after the race. This is a good excuse to drink some beer. At 10:30 in the morning? Well, it's past noon in Dublin, said teammate Mike [Joseph] Schwern. It's our duty. -- Sure, and It's a Great Day for Irish Runners Newsday, Sunday, March 20, 1988
Re: SV: Parrot multithreading?
At 04:15 PM 9/30/2001 -0400, Sam Tregar wrote: On Sun, 30 Sep 2001, Nick Ing-Simmons wrote: The main problem with perl5 and threads is that threads are an afterthought. Which, of course, also goes for UNIX and threads and C and threads. It's good for us to be thinking about as early as possible but it's no garauntee that there won't be big problems anyway. Extensions in C come to mind... If they follow the rules, things'll be fine. We'll make sure it's all laid out clearly. Has anything come down from the mountain about the future of XS in Perl 6? Speaking of which, what's taking Moses so long? Work, life... y'know, the standard stuff. :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: SV: Parrot multithreading?
At 09:23 AM 10/1/2001 -0400, Michael Maraist wrote: Just because parrot knows what functions can croak, it doesn't mean that it can possibly know which locks have been taken out all the way back up the stack between the call to longjmp and the corresponding setjmp. And, under your scheme we would potentially end up with two copies of every utility function - one croak_safe and one croak_unsafe. Not very likely - the only reason I can find for most utility functions (other than possibly string coercions) to fail is either panic(out of memory!) or panic(data structures hopelessly confused!) (or maybe panic(mutexes not working!)) - anything likely to throw a programmatic exception would be at the opcode level, and so not be open to being called by random code. The perl6 high-level description currently sugests that op-codes can theoretically be written in perl. Perhaps these are only second-class op-codes (switched off a single user-defined-op-code), but that suggests that the good ole die/croak functionality will be desired. Sure, but that's no problem. Things should propagate up those code streams the way they do any other. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
