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: 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 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
> }
>
>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*
On Thu, Sep 20, 2001 at 04:25:45PM -0400, Dan Sugalski wrote: > At 01:06 PM 9/20/2001 -0700, Robert Spier wrote: > > 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 functions!" reaction. "char" is misnamed in C--it should have been called "byte". If you have a string of bytes, which you intend to treat as a string of bytes, then you should use a char* for it. (Well, unsigned char*.) The question is whether any given chunk of data is going to be treated as a string of bytes or not. I'm certain that there will be such data strings somewhere in Parrot; I'm not certain if the type of string which gets put into an SV will be of this type or not. - Damien
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 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
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: Draft switch for DO_OP() :-)
On Thu, Sep 20, 2001 at 04:24:19PM -0400, Dan Sugalski wrote:
> 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:
>
> I like that approach. I'd say go for it--got time to put this in?
It's a fairly simple change...I'm attaching an updated version. This
requires that "#define PARROT_OP_IMPLEMENTATION" be added to
interpreter.c, before interp_guts.h is included.
- Damien
#!/usr/bin/perl -w
use strict;
use Parrot::Opcode;
use Getopt::Std;
use Symbol;
# Arguments.
sub usage {
print STDERR "Usage: $0 -d [ ...]\n";
exit 1;
}
my %opts = (d => "function");
getopts("d:", \%opts) or usage;
if ($opts{d} ne "function" && $opts{d} ne "switch") {
print STDERR "Supported dispatch modes: function, switch.\n";
exit 1;
}
# Opcodes.
my $opcode_fingerprint = Parrot::Opcode::fingerprint();
my %opcodes= Parrot::Opcode::read_ops();
my @opcodes;
for my $name (keys %opcodes) {
my $op = $opcodes{$name};
push @opcodes, $op;
$op->{NAME} = $name;
}
@opcodes = sort { $a->{CODE} <=> $b->{CODE} } @opcodes;
my %files;
for my $f (@ARGV) {
($files{$f}{header}, $files{$f}{ops}) = read_ops($f);
}
# quoted() is used to simplify generation. The leading regex /\s*#/ is
# stripped from text, to allow here-docs to be set off from the surrounding
# Perl code. Lines beginning with /\s*\#\*/ are printed once for every
# opcode. Text surrounded in curly braces, like {THIS}, is replaced with
# the value of the appropriate field in the opcode definition.
sub quoted {
my $s = "";
for (split /\n/, $_[0]) {
if (s/^\s*\#\*//) {
for my $op (@opcodes) {
my $t = $_; $t =~ s/{(\w+)}/$op->{$1}/ge;
$s .= "$t\n";
}
}
elsif (s/^\s*\# ?//) {
$s .= "$_\n";
}
}
$s;
}
# op.h
open OP_H, "> include/parrot/op.h"
or die "include/parrot/op.h: $!\n";
print OP_H quoted(< include/parrot/interp_guts.h"
or die "include/parrot/interp_guts.h: $!\n";
print INTERP quoted(<{CODE}] = (void*)$op->{NAME}; \\\n";
} else {
print INTERP "\tx[$op->{CODE}] = NULL; \\\n";
}
}
print INTERP quoted({IMPL_BODY}) {
my $body = $op->{IMPL_BODY};
$body =~ s/RETVAL/return_offset/g;
$body =~ s/RETURN\(0\);/;/g;
$body =~ s/RETURN\((.*)\)/cur_opcode = cur_opcode + $1; break/g;
print INTERP " case $op->{CODE}: { \\\n";
for (split /\n/, $body) {
print INTERP "$_ \\\n";
}
print INTERP "cur_opcode += $op->{IMPL_RETURN_ADDR}; } \\\n";
print INTERP "break; \\\n";
}
}
print INTERP " default: \\\n";
print INTERP "exit(1); /* XXX: Better error trapping */ \\\n";
print INTERP " } } while(0)\n\n";
print INTERP "#ifdef PARROT_OP_IMPLEMENTATION\n";
for my $f (sort keys %files) {
print INTERP "\n/* $f */\n$files{$f}{header}";
}
print INTERP "\n#endif\n";
}
print INTERP quoted(< $output" or die "$output: $!\n";
print OUTPUT quoted(<{IMPL_BODY};
$body =~ s/RETVAL/return_offset/g;
$body =~ s/RETURN\(0\);/return 0;/g;
$body =~ s/RETURN\((.*)\)/return cur_opcode + $1/g;
print OUTPUT "#line $op->{IMPL_LINE} \"$op->{IMPL_FILE}\"\n";
print OUTPUT ("opcode_t *$op->{FUNC}(".
"opcode_t cur_opcode[], ".
"struct Parrot_Interp *interpreter".
") {\n");
print OUTPUT $body;
print OUTPUT " return cur_opcode + $op->{IMPL_RETURN_ADDR};\n}\n\n";
}
close OUTPUT;
}
# Read opcode function definitions.
#
# Opcode functions are in the format:
#
# AUTO_OP opname {
#
# ... body of function ...
#
# }
#
# Where the closing brace is on its own line. Alternately, for opcode
# functions that manage their own return values:
#
# MANUAL_OP opname {
#
#... body of function ...
#
#RETVAL = x;
#
# }
#
# There may be more than one RETVAL
#
# The functions have the magic variables Pnnn for parameters 1 through
# X. (Parameter 0 is the opcode number) Types for each, and the size
# of the return offset, are taken from the opcode_table file
sub read_ops {
my($file) = @_;
open INPUT, $file or die "$file: $!\n";
my @ops;
my $file_header = "";
my($name, $body, $footer, $offset, @pa
Re: Parrot multithreading?
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? - Damien
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?
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
_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 i
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: 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: Parrot multithreading?
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(). I'm being a bit pedantic here because I've been involved in heated debates in the past, which were resolved when the two sides realized that they were using different definitions of async I/O. :> - Damien
RE: Parrot multithreading?
> 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. > That sounds too ideal to me. The problem with aio is many implmenetations use sync io and thread. If we completely rely on aio, then we will have sync io on top of aio on top of thread+sync io. It is huge waste of resource and performance. Actually we lost more than that, atomicity. The Unix read/write/seek are atomic operations. With async implementation, we will lose it. It is huge impact on many people (at least me), who are relying on atomic operations instead of complicated file locking. The seek position is also lost with async io. > 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. > The async io may not be available universally. I have terrible experience with Win32 console stream. Some special device stream may not behave well under async io. Anyway, I don't any reason we have to choose one over the other. Can we just support both? What are we arguing for? Hong
Re: Name lengths in C code
At 02:17 PM 9/20/2001 -0700, Damien Neil wrote: >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. We're OK with 31 character, case insensitive, I think. That'll work on VMS, which is the most restrictive of the platforms in this regard that we'll build on. >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... Ah, that's explain the hideous symbols that always got spat out whenever I got a backtrace from a crashing oracle process. I understand. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] make realclean
> + cd t; make realclean
( from MM_Unix, sub clean
if ($Is_Win32 && Win32::IsWin95()) {
push @m, <{MAKEFILE}
\$(MAKE) clean
cd ..
EOT
}
else {
push @m, <{MAKEFILE} && \$(MAKE) clean
EOT
}
If you could change it to
cd t && ...
so at least it works on WinNT/2000, then I'll
do it the right way later
Thanks
Mattia
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 ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN sChWErn ScHWeRn schweRn sCHWErN schWeRnscHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern scHWerNscHWeRn scHWerNScHwerN SChWeRN scHWeRn SchwERNschwERnSCHwern sCHWErN SCHWErN sChWeRn
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
}
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: "Feature Freeze"
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> 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.
Tests cleanly on linux/x86:
perl t/harness
t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler
t/op/integerok
t/op/number.ok, 2/23 skipped: various reasons
t/op/string.ok, 1/5 skipped: I'm unable to write it!
t/op/trans..ok
All tests successful, 4 subtests skipped.
Files=5, Tests=74, 45 wallclock secs (38.60 cusr + 6.28 csys = 44.88 CPU)
Builds cleanly with -Wall with the exception of these warnings
in packfile.c:
packfile.c:964:3: warning: "/*" within comment
packfile.c:967:3: warning: "/*" within comment
packfile.c: In function `PackFile_unpack':
packfile.c:323: warning: int format, IV arg (arg 3)
packfile.c:344: warning: int format, IV arg (arg 3)
packfile.c:287: warning: unused variable `byte_code_ptr'
packfile.c:285: warning: unused variable `segment_ptr'
packfile.c: In function `PackFile_dump':
packfile.c:461: warning: unsigned int format, long unsigned int arg (arg 2)
packfile.c:474: warning: unsigned int format, long unsigned int arg (arg 2)
packfile.c:476: warning: unsigned int format, long unsigned int arg (arg 2)
packfile.c: In function `PackFile_ConstTable_dump':
packfile.c:938: warning: int format, IV arg (arg 2)
packfile.c: In function `PackFile_Constant_unpack':
packfile.c:1233: warning: unused variable `i'
packfile.c: In function `PackFile_Constant_dump':
packfile.c:1358: warning: unsigned int format, long unsigned int arg (arg 2)
The attached patch will clean up those warnings.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
Index: packfile.c
===
RCS file: /home/perlcvs/parrot/packfile.c,v
retrieving revision 1.4
diff -u -r1.4 packfile.c
--- packfile.c 2001/09/20 21:41:40 1.4
+++ packfile.c 2001/09/20 22:41:46
@@ -180,7 +180,7 @@
***/
-void
+void
PackFile_set_magic(PackFile * self, IV magic) {
self->magic = magic;
}
@@ -282,9 +282,7 @@
IV
PackFile_unpack(PackFile * self, char * packed, IV packed_size) {
-IV * segment_ptr;
IV segment_size;
-char * byte_code_ptr;
char * cursor;
IV * iv_ptr;
@@ -317,9 +315,9 @@
iv_ptr = (IV *)cursor;
segment_size = *iv_ptr;
cursor += sizeof(IV);
-
+
if (segment_size % sizeof(IV)) {
-fprintf(stderr, "PackFile_unpack: Illegal fixup table segment size %d (must
be multiple of %d!\n",
+fprintf(stderr, "PackFile_unpack: Illegal fixup table segment size %ld (must
+be multiple of %d!\n",
segment_size, sizeof(IV));
return 0;
}
@@ -338,13 +336,13 @@
iv_ptr = (IV *)cursor;
segment_size = *iv_ptr;
cursor += sizeof(IV);
-
+
if (segment_size % sizeof(IV)) {
-fprintf(stderr, "PackFile_unpack: Illegal constant table segment size %d
(must be multiple of %d!\n",
+fprintf(stderr, "PackFile_unpack: Illegal constant table segment size %ld
+(must be multiple of %d!\n",
segment_size, sizeof(IV));
return 0;
}
-
+
if (!PackFile_ConstTable_unpack(self->const_table, cursor, segment_size)) {
fprintf(stderr, "PackFile_unpack: Error reading constant table segment!\n");
return 0;
@@ -366,7 +364,7 @@
self->byte_code_size = 0;
return 0;
}
-
+
mem_sys_memcopy(self->byte_code, cursor, self->byte_code_size);
}
@@ -432,7 +430,7 @@
iv_ptr = (IV *)cursor;
*iv_ptr = const_table_size;
cursor += sizeof(IV);
-
+
PackFile_ConstTable_pack(self->const_table, cursor);
cursor += const_table_size;
@@ -458,7 +456,7 @@
PackFile_dump(PackFile * self) {
IV i;
-printf("MAGIC => 0x%08x,\n", self->magic);
+printf("MAGIC => 0x%08lx,\n", self->magic);
printf("FIXUP => {\n");
PackFile_FixupTable_dump(self->fixup_table);
@@ -471,9 +469,9 @@
printf("BCODE => [");
for (i = 0; i < self->byte_code_size / 4; i++) {
if (i % 8 == 0) {
-printf("\n%08x: ", i * 4);
+printf("\n%08lx: ", i * 4);
}
-printf("%08x ", ((IV *)(self->byte_code))[i]);
+printf("%08lx ", ((IV *)(self->byte_code))[i]);
}
printf("\n]\n");
@@ -837,7 +835,7 @@
iv_ptr = (IV *)cursor;
self->const_count = *iv_ptr;
cursor += sizeof(IV);
-
+
if (self->const_count == 0) {
return 1;
}
@@ -857,7 +855,7 @@
cursor += PackFile_Constant_pack_size(self->constants[i]);
}
-
+
return 1;
}
@@ -915,7 +913,7 @@
cursor += PackFile_Constant_pack_size(self->constants[i]);
}
-
+
return;
}
@@ -935,10 +933,10 @@
IV i;
for(i = 0; i < self->const_count; i++) {
-printf("# %d:\n", i);
+printf("# %ld:\n"
