Re: of Mops, jit and perl6
Dan Sugalski wrote: > At 10:44 AM +0200 7/28/02, Leopold Toetsch wrote: > >> 2) Some Mops numbers, all on i386/linux Athlon 800, slightly shortend: >> (»make mops« in parrot root) > > > Just out of curiosity, I presume the (rather abysmal) perl 6 numbers > include time to generate the assembly and assemble it--have you tried > running the generated code by itself as a test? (At the moment, the > assembler's rather slow) No, these Mopsen are pure run time. As Sean alredy stated, code quality is to blame. Times for individual steps are: $ time perl6 --imc mops.p6 real0m1.794s user0m1.690s sys 0m0.100s $ time ../imcc/imcc mops.imc mops.pasm 327 lines compiled. Compiling assembly module mops.pasm real0m0.032s user0m0.020s sys 0m0.000s [lt@thu8:~/src/parrot-007/languages/perl6] $ time perl ../../assemble.pl mops.pasm > mops.pbc real0m0.481s user0m0.470s sys 0m0.010s This adds up to 2.3s to get a perl6 program running. leo
Re: [perl #15800] [PATCH] lexical scope ops, test and example
--- Jonathan Sillito > close_lex # end of nested lexical scope > > find_lex P3, "a" > print P3 # prints 12 > print "\n" > end > That's a typo, right? It should print the first value of "a" (10). Just making sure I'm not crazy ... Stephen Rawls __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: of Mops, jit and perl6
Dan Sugalski wrote: > At 10:44 AM +0200 7/28/02, Leopold Toetsch wrote: > >> 2) Some Mops numbers, all on i386/linux Athlon 800, slightly shortend: > Just out of curiosity, I presume the (rather abysmal) perl 6 numbers After the bugfix in perlarray.pmc I can bring you new numbers, which are not that abysmal. Changing the while loop in mops.p6 to: $I4 = $I4 - $I3 # subI4, I4, I3 - while ($I4>0); # if I4, REDO + while ($I4); # if I4, REDO (which is more correct, comparing to e.g. mops.pl) $ time perl6 -Rj mops.p6 Iterations:100 Estimated ops: 200 Elapsed time: 1.032118 M op/s:1.937763 real0m3.357s user0m3.190s sys 0m0.150s We have already the same Mops as perl5, but additionaly 2.3 seconds overhead. Just running the byte code is as fast as perl5. Without jit, mops.p6 performs at 0.8 Mops. leo
Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening
On Mon, Jul 22, 2002 at 11:14:15AM +0100, Sam Vilain wrote: > "Sean O'Rourke" <[EMAIL PROTECTED]> wrote: > > > languages/perl6/README sort of hides it, but it does say that "If you have > > Perl <= 5.005_03, "$a += 3" may fail to parse." I guess we can upgrade > > that to "if you have < 5.6, you lose". > > I notice that DBI no longer supports Perl releases <5.6. Not true. The DBI supports 5.5.3. The most recent release announcement did say: NOTE: Future versions of the DBI may not support for perl 5.5 much longer. : If you are still using perl 5.005_03 you should be making plans to : upgrade to at least perl 5.6.1, or 5.8.0. Perl 5.8.0 is due to be : released in the next week or so. (Although it's a "point 0" release, : it is the most throughly tested release ever.) But that's just a "shot across the bows" alerting people to think about upgrading. I'm unlikely to actually require 5.6.1 for quite some time yet. Tim.
Re: of Mops, jit and perl6
At 10:23 AM 7/30/2002 +0200, Leopold Toetsch wrote: >Dan Sugalski wrote: >>Just out of curiosity, I presume the (rather abysmal) perl 6 numbers >We have already the same Mops as perl5, but additionaly 2.3 seconds >overhead. Just running the byte code is as fast as perl5. > >Without jit, mops.p6 performs at 0.8 Mops. While I don't mind worrying about the compile time numbers, it is probably way, way too early to be placing any value on MOPS numbers. We just barely got a compiler patched together with gum and tape before TPC and the code generated is t-t-t-terrible. Some of it is Sean's frontend and some is my backend. Toss in the fact that the VM still unoptimized in many areas and we basically have a LOT of work cut out for us. So lets archive these numbers, and see how much we can improve on them and not get too depressed. :) [Both the front and back end compilers are apt to be rewritten anyway] -Melvin
Re: [perl #15800] [PATCH] lexical scope ops, test and example
On Mon, 2002-07-29 at 17:12, Simon Glover wrote:
> I think you forgot to attach the patch...
oops, now the files are attached ...
- patch: lex.patch
- test file: lexicals.t
- example file: lexicals.pasm
On Tue, 2002-07-30 at 02:14, Stephen Rawls wrote:
> --- Jonathan Sillito
> > close_lex # end of nested lexical scope
> >
> > find_lex P3, "a"
> > print P3 # prints 12
> > print "\n"
> > end
> >
>
> That's a typo, right? It should print the first value
> of "a" (10). Just making sure I'm not crazy ...
Hey, thanks for reading this over. It is not a typo, but it may be
incorrect. My code does overwrite previous lexicals in enclosing scopes
(i.e. lexicals in pads lower on the stack), but maybe I have the
semantics of the store_lex op wrong? The following example shows what I
had in mind:
my $x = 13;
sub foo
{
$x = 12;
}
foo();
print $x; # prints 12
The alternative (what you have in mind I guess) is:
my $x = 13;
sub foo
{
my $x = 12; # notice the my
}
foo();
print $x; # prints 13
So I guess I see your point. Let me know if I should change the
implementation (it would be a quick change). Also note that there is
currently no support for accessing lexicals by index or for creating
pads from descriptors.
Thanks for any comments.
--
Jonathan Sillito
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.187
diff -u -r1.187 core.ops
--- core.ops 26 Jul 2002 19:15:56 - 1.187
+++ core.ops 29 Jul 2002 23:03:24 -
@@ -3604,6 +3604,24 @@
+=item B()
+
+Start a new lexical scope
+
+=item B()
+
+Close most recently opened lexical scope
+
+=item B(in PMC, in STR)
+
+Store object $1 as lexical symbol $2. This currently involves
+looking back through the stack of pads to see if there is an
+entry (corresponding to $2) that should be overwritten.
+
+=item B(in PMC, in STR)
+
+Find the lexical variable named $2 and store it in $1
+
=item B(in PMC, in STR)
Store global $1 as global symbol $2
@@ -3613,6 +3631,80 @@
Find the global named $2 and store it in $1
=cut
+
+op open_lex() {
+PMC* hash = pmc_new(interpreter, enum_class_PerlHash);
+stack_push(interpreter, &interpreter->ctx.pad_stack, hash, STACK_ENTRY_DESTINATION, STACK_CLEANUP_NULL);
+
+goto NEXT();
+}
+
+op close_lex() {
+stack_pop(interpreter, &interpreter->ctx.pad_stack, NULL, STACK_ENTRY_DESTINATION);
+goto NEXT();
+}
+
+op store_lex(in PMC, in STR) {
+Stack_Chunk_t *cur_stack;
+Stack_Entry_t *entry = NULL;
+PMC * cur_hash = NULL;
+PMC * found = NULL;
+unsigned int i;
+KEY key;
+Stack_entry_type type = 0;
+
+MAKE_KEY(key, $2, enum_key_string, struct_val);
+
+/* walk back through stack of pads for the key */
+cur_stack = interpreter->ctx.pad_stack;
+while (cur_stack) {
+if (cur_stack->buffer) {
+entry = (Stack_Entry_t *)(cur_stack->buffer->bufstart);
+for (i = 0; i < cur_stack->used; i++) {
+ cur_hash = (PMC *)entry[i].entry.pmc_val;
+ found = cur_hash->vtable->get_pmc_keyed(interpreter, cur_hash, &key);
+ if (found) break;
+}
+}
+cur_stack = cur_stack->prev;
+}
+
+if (!found) { /* set the top pad to be cur_hash */
+ cur_hash = (PMC *)stack_peek(interpreter, interpreter->ctx.pad_stack, &type);
+}
+cur_hash->vtable->set_pmc_keyed(interpreter, cur_hash, NULL, $1, &key);
+
+goto NEXT();
+}
+
+op find_lex(out PMC, in STR) {
+Stack_Chunk_t *cur_stack;
+Stack_Entry_t *entry = NULL;
+PMC * cur_hash = NULL;
+PMC * found = NULL;
+unsigned int i;
+KEY key;
+
+MAKE_KEY(key, $2, enum_key_string, struct_val);
+
+cur_stack = interpreter->ctx.pad_stack;
+while (cur_stack) {
+if (cur_stack->buffer) {
+entry = (Stack_Entry_t *)(cur_stack->buffer->bufstart);
+for (i = 0; i < cur_stack->used; i++) {
+ cur_hash = (PMC *)entry[i].entry.pmc_val;
+ found = cur_hash->vtable->get_pmc_keyed(interpreter, cur_hash, &key);
+ if (found) break;
+}
+}
+cur_stack = cur_stack->prev;
+}
+
+/* found will still be NULL if key was not found
+ * FIXME: should the not found case be an internal_exception ? */
+$1 = found;
+goto NEXT();
+}
op store_global(in PMC, in STR) {
KEY key;
Index: dod.c
===
RCS file: /cvs/public/parrot/dod.c,v
retrieving revision 1.8
diff -u -r1.8 dod.c
--- dod.c 23 Jul 2002 07:25:02 - 1.8
+++ dod.c 29 Jul 2002 23:03:24 -
@@ -92,6 +92,23 @@
}
}
+/* Walk lexical pad stack */
+cur_stack = interpreter->ctx.pad_stack;
+while (cur_stack) {
+if (cur_stack->buffer) {
+ buffer_lives(cur_stack->buffer);
+ entry =
Re: [perl #15800] [PATCH] lexical scope ops, test and example
See my 2 comments:
> new P0, .PerlInt
> new P1, .PerlInt
> new P2, .PerlInt
> new P3, .PerlInt
> set P0, 10
> set P1, 11
> set P2, 12
>
> # outer most lexical scope
> open_lex
New pad
> store_lex P0, "a"
> find_lex P3, "a"
> print P3 # prints 10
> print "\n"
>
># nested lexical scope
>open_lex
>store_lex P1, "b"
>find_lex P3, "b"
>print P3 # prints 11
>print "\n"
>
>store_lex P2, "a" # overwrites previous "a"
^ Should not "overwrite", should shadow since it is
stored
in the current pad
>find_lex P3, "a"
>print P3 # prints 12
>print "\n"
>
>close_lex # end of nested lexical scope
^ Pad goes away, with "b" and "a", so the outer values
should be back in effect.
>
> find_lex P3, "a"
> print P3 # prints 12
> print "\n"
> end
I'll apply this, since it is clean, but the semantics need adjustment.
Thanks,
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
Re: [perl #15805] [PATCH] some trivial offerings to the compiler gods
Thanks sir, applied. -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
drive-by-reminder: missing JITs
Nick Clark is working on ARM, but we are still missing at least the following importantish JIT implementations: * PPC - PowerPC (Motorola) and POWER (IBM) -- I know there's a "common" instruction set that works both on the "consumer" PPCs and the HPC (high performance computing) POWER chips. * MIPS - I know a little bit more about these, but I *suspect there's a simple common instruction set * HPPA - I know very little about these, is there a common instruction set? * IA64 - reports of the IA64 instruction set tell that it combines the "elegance" of the IA32 CISCy instruction set with the "elegance" of the HPPA RISCy instruction set... :-) I intend to do nothing on these except raise gui^H^H^Hawareness :-) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: [perl #15800] [PATCH] lexical scope ops, test and example
Thanks for the correction. May I ask about the find_lex op? In my implementation it looks back through the stack of pads for the given lexical: new P0, .PerlInt new P1, .PerlInt set P0, 10 open_lex store_lex P0, "a" # nested lexical scope open_lex find_lex P1, "a" print P1 # prints 10 # etc Also, should open_lex/close_lex be named new_pad/close_pad instead? If you want to hold off on applying the patch, I will submit one with the correct semantics in the next couple of hours. Or if you have already submitted it I will send a patch to fix it. Thanks again. -- Jonathan Sillito On Tue, 2002-07-30 at 10:47, Melvin Smith wrote: > See my 2 comments: > > > new P0, .PerlInt > > new P1, .PerlInt > > new P2, .PerlInt > > new P3, .PerlInt > > set P0, 10 > > set P1, 11 > > set P2, 12 > > > > # outer most lexical scope > > open_lex > New pad > > store_lex P0, "a" > > find_lex P3, "a" > > print P3 # prints 10 > > print "\n" > > > ># nested lexical scope > >open_lex > >store_lex P1, "b" > >find_lex P3, "b" > >print P3 # prints 11 > >print "\n" > > > >store_lex P2, "a" # overwrites previous "a" > ^ Should not "overwrite", should shadow since it is > stored >in the current pad > >find_lex P3, "a" > >print P3 # prints 12 > >print "\n" > > > >close_lex # end of nested lexical scope > ^ Pad goes away, with "b" and "a", so the outer values >should be back in effect. > > > > find_lex P3, "a" > > print P3 # prints 12 > > print "\n" > > end > > I'll apply this, since it is clean, but the semantics need adjustment. > Thanks, > > -Melvin Smith > > IBM :: Atlanta Innovation Center > [EMAIL PROTECTED] :: 770-835-6984 >
Re: we need more ops.
At 10:43 AM -0400 7/29/02, Melvin Smith wrote: >At 10:45 AM 7/29/2002 +0100, Nicholas Clark wrote: >>[Maybe we should have a competition to suggest the most crazy three character >>operator - ie state your sequence of three characters (not necessarily ASCII, >>but it helps), state their name, and state their purpose (including whether >>listop, binop, uniop, precedence, associativity or whatever else helps make >>your entry more humorous. So presumably there could be a :-) operator, but >>offhand I can't think of something plausible it could do. And does the >>tie-fighter need an X-wing operator to complement it? (not sure what that >>one would look like, let alone what it would do)] > >Thats funny, but you have a point there. > >The VM and assembler does not need to provide every operator as >an new 'op'. Eventually, languages with funky operators need to start thinking >about implementing them as methods or such. This is definitely true, for ease of use and maintenace if nothing else. However, if a language does want to provide ops for its operators, that's not really something we should care about. Also, the one big upside to ops is that they're JITtable, where method calls aren't. Ultimately doing things as a (dynamically loaded) op will make the running of the code faster, since op calls are lower overhead than method calls. The runtime will likely be smaller as well. The downside is a larger compiler side. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #15797] [PATCH] Regex speedup
At 9:47 PM + 7/29/02, Angel Faus (via RT) wrote: >I've made a patch for the regex engine, designed with the single goal >of seriously cheating for speed. :-) Wow. Register spilling, and now this. Damn, with all the folks doing clever things here, I'm feeling decidedly superfluous. :) But... Could you regenerate this as a patch using either the -u or -c switches to patch? The default diff doesn't apply well. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: admin question: mail gets tagged as spam when mailingbugs..@perl..
At 8:12 AM +0200 7/30/02, =?latin1?Q?Josef_H=F6=F6k?= wrote: >As im not that familiar with spamassasin maybe someone could help me >stop getting my mail tagged as spam when mailing patches.. Sure. I'd send this privately, but as it affects some other folsk as well... The biggest thing that kills your mail is your service provider. The IP address of the sending machine's in the DSBL, and that rates you three points towards being spam. (Default setup requires five points total) SpamAssassin is also unhappy with the explicit latin-1 tagging in your headers. Specifically the From: header, I think. For me it comes through as "=?latin1?Q?Josef_H=F6=F6k?=" and that rates you an extra 3.1 points. (For my mailer, the header doesn't actually resolve, it stays the mush of characters. I had to hit the web to get the proper spelling of your name for the presentation slides) Altering the from: header will probably be sufficient to stop getting tagged as spam, though getting off the DSBL list would be better. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: I'm back...
At 8:53 PM -0700 7/29/02, Sean O'Rourke wrote:
>On Mon, 29 Jul 2002, Dan Sugalski wrote:
>> If I thought anyone'd do control flow with it, I'd have a version of
>> the op for that, but I don't think we're going to see that, and perl
>> doesn't do it, so...
>
>Okay, writing this email has convinced me that maybe we don't need these
>ops. If Perl's going to do things like this:
>
> $x = 1; $y = 2; $z = "grape";
> if $z < $x < $y lt $z { print "strange, but true" }
>
>then it seems like they'll be used for control flow just like anything
>else. The alternative would be to do this with the Ix versions like so:
>
> cmpn I0, Px, Py
> unless I0, -1, l_false
>
>Or with the current set of ops, through temps like so:
>
> set N0, Px
> set N1, Py
> ge N0, N1, l_false
I need to get Larry to nail some things down. On the one hand, he's
said that chained comparisons evaluate their parameters just once.
That argues for moving the values to N or S registers. On the other,
comparisons are overloadable, which means we need to call the PMC's
vtable entries. But chained comparisons will result in us calling
those entries multiple times, when we've been declared to call them
only once.
Hrmf. Time to nudge. Oh. Larry :)
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: ARM Jit v2
At 10:34 PM -0300 7/29/02, Daniel Grunblatt wrote: >On Mon, 29 Jul 2002, Nicholas Clark wrote: > > As you can see from the patch all it does is implement the end >and noop ops. >> Everything else is being called. Interestingly, JITing like this is slower >> than computed goto: > >Yes, function calls are generally slower than computing a goto. Yup. There's the function preamble and postamble that get executed, which can slow things down relative to computed goto, which doesn't have to execute them. This brings up an interesting point. Should we consider making at least some of the smaller utility functions JITtable? Not the opcode functions, but things in string.c or pmc.c perhaps. (Or maybe getting them inlined would be sufficient for us) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: drive-by-reminder: missing JITs
On Tue, 30 Jul 2002, Jarkko Hietaniemi wrote: > Nick Clark is working on ARM, but we are still missing at least the > following importantish JIT implementations: > > * PPC - PowerPC (Motorola) and POWER (IBM) -- I know there's a "common" > instruction set that works both on the "consumer" PPCs and the HPC > (high performance computing) POWER chips. I'm working on this. > > * MIPS - I know a little bit more about these, but I *suspect there's > a simple common instruction set > > * HPPA - I know very little about these, is there a common instruction set? > > * IA64 - reports of the IA64 instruction set tell that it combines > the "elegance" of the IA32 CISCy instruction set with > the "elegance" of the HPPA RISCy instruction set... :-) > > I intend to do nothing on these except raise gui^H^H^Hawareness :-) Or give me an acount? ;) Daniel Grunblatt.
Re: ARM Jit v2
Yes, we can do that, we can also try to go in and out from the computed goto core if available. Daniel Grunblatt. On Tue, 30 Jul 2002, Dan Sugalski wrote: > At 10:34 PM -0300 7/29/02, Daniel Grunblatt wrote: > >On Mon, 29 Jul 2002, Nicholas Clark wrote: > > > As you can see from the patch all it does is implement the end > >and noop ops. > >> Everything else is being called. Interestingly, JITing like this is slower > >> than computed goto: > > > >Yes, function calls are generally slower than computing a goto. > > Yup. There's the function preamble and postamble that get executed, > which can slow things down relative to computed goto, which doesn't > have to execute them. > > This brings up an interesting point. Should we consider making at > least some of the smaller utility functions JITtable? Not the opcode > functions, but things in string.c or pmc.c perhaps. (Or maybe getting > them inlined would be sufficient for us) > -- > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even >teddy bears get drunk >
Re: [perl #15800] [PATCH] lexical scope ops, test and example
At 10:16 AM -0600 7/30/02, Jonathan Sillito wrote: >Hey, thanks for reading this over. It is not a typo, but it may be >incorrect. My code does overwrite previous lexicals in enclosing scopes >(i.e. lexicals in pads lower on the stack), but maybe I have the >semantics of the store_lex op wrong? Yup, lexical pads should go away and their effects go away when you exit their scope. Fix that and this patch can go in, as it gets a good chunk of the semantics we need. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: drive-by-reminder: missing JITs
> > * MIPS - I know a little bit more about these, but I *suspect there's > > a simple common instruction set > > > > * HPPA - I know very little about these, is there a common instruction set? > > > > * IA64 - reports of the IA64 instruction set tell that it combines > > the "elegance" of the IA32 CISCy instruction set with > > the "elegance" of the HPPA RISCy instruction set... :-) > > > > I intend to do nothing on these except raise gui^H^H^Hawareness :-) > > Or give me an acount? ;) For the HPPA and IA64 I think getting an account in the HP/CPQ Test Drive machines should help: http://www.testdrive.compaq.com/ For MIPS, I dunno whether SGI has something similar. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: [perl #15800] [PATCH] lexical scope ops, test and example
At 11:01 AM -0600 7/30/02, Jonathan Sillito wrote:
>Thanks for the correction. May I ask about the find_lex op? In my
>implementation it looks back through the stack of pads for the given
>lexical:
One thing we need to add is a constant type to initialize pads. It's
perfectly acceptable, and in fact a design goal, to have a PMC in
multiple pads with the same name.
So, for example, if you had:
my $foo;
{
my $bar;
$foo = 12;
}
at the perl level, there'd be two pads, one for the block and one for
the outer scope. The PMC for $foo would be in *both* of them, and the
lookup wouldn't go past the inner pad. (And the lookup would be by
number rather than name as well, since we know the position in the
pad of the lexical)
>Also, should open_lex/close_lex be named new_pad/close_pad instead?
Yeah, I think so. Or new_pad/pop_pad, since we may keep the pad
around when we take it off the current pad stack.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: I'm back...
On Tue, 30 Jul 2002, Dan Sugalski wrote: > I need to get Larry to nail some things down. On the one hand, he's > said that chained comparisons evaluate their parameters just once. > That argues for moving the values to N or S registers. I read that as "expressions are evaluated once", not "PMC's are accessed once". So something like 2 < $i++ < 23 will do the expected -- increment $i once, keeping the result in a PMC temporary. The temp will necessarily be accessed more than once, but to me that doesn't count as evaluating the expression multiple times. > On the other, comparisons are overloadable, which means we need to > call the PMC's vtable entries. That gets us into that mess. But we can still evaluate the expression to a PMC temporary, then get its value more than once. And if you've tied a variable to have side effects every time it's accessed, you shouldn't care if the results are unpredictable. /s
Re: we need more ops.
Dan wrote: >At 10:43 AM -0400 7/29/02, Melvin Smith wrote: >>At 10:45 AM 7/29/2002 +0100, Nicholas Clark wrote: >>The VM and assembler does not need to provide every operator as >>an new 'op'. Eventually, languages with funky operators need to start thinking >>about implementing them as methods or such. > >This is definitely true, for ease of use and maintenace if nothing >else. However, if a language does want to provide ops for its >operators, that's not really something we should care about. Also, >the one big upside to ops is that they're JITtable, where method >calls aren't. Aha! You said it yourself, instructions are JITtable. So why shouldn't we concentrate on providing enough _primitives_ to allow people to write anything and everything in Parrot. New ops then become JITable and the upside is there is no language specific ops file needed. That way any language compiling to Parrot will run on any Parrot with standard ops. >Ultimately doing things as a (dynamically loaded) op will make the >running of the code faster, since op calls are lower overhead than >method calls. The runtime will likely be smaller as well. The >downside is a larger compiler side. The other downside is that Parrot turns into a Linux kernel and forever accumulates custom ops, PMCs. I think of Parrot as a CPU. When we have adequately designed the CPU, people don't need new ops. -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
Re: I'm back...
On Tue, 30 Jul 2002, Sean O'Rourke wrote: > And if you've tied a variable to have side effects every time it's > accessed, you shouldn't care if the results are unpredictable. s/tied a variable/implemented a type/. Argh. /s
Re: we need more ops.
On Tue, 30 Jul 2002, Melvin Smith wrote: > I think of Parrot as a CPU. When we have adequately designed the CPU, > people don't need new ops. I think of it as a VAX, in which case "adequately designed" means "just a few microcode ops" ;). /s
[perl #15845] [BUG] GC segfault
# New Ticket Created by Simon Glover # Please include the string: [perl #15845] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=15845 > This code segfaults: sweepoff set I0, 0 LOOP: new P0, .PerlString set P0, "ABC" save P0 inc I0 lt I0, 127, LOOP end It doesn't so this if you remove the , or if you make the number in the loop smaller, which suggests that it's crashing when it runs out of headers to allocate. Here's the stack trace: Program received signal SIGSEGV, Segmentation fault. 0x080aa242 in get_free_buffer (interpreter=0x8133be8, pool=0x813c008) at headers.c:84 84 pool->free_list = *(void **)buffer; (gdb) bt #0 0x080aa242 in get_free_buffer (interpreter=0x8133be8, pool=0x813c008) at headers.c:84 #1 0x080aa56e in new_string_header (interpreter=0x8133be8, flags=0) at headers.c:216 #2 0x0807c1a9 in string_copy (interpreter=0x8133be8, s=0x8147be0) at string.c:225 #3 0x080bbf64 in Parrot_PerlString_set_string_native () #4 0x080899b4 in cg_core (cur_opcode=0x8149c64, interpreter=0x8133be8) at core.ops:583 #5 0x0807d7f0 in runops_cgoto_core (interpreter=0x8133be8, pc=0x8149c48) at runops_cores.c:52 #6 0x08049942 in runops_generic (core=0x807d7dc , interpreter=0x8133be8, pc=0x8149c48) at interpreter.c:80 #7 0x0804a18d in runops (interpreter=0x8133be8, code=0x8145b48, offset=0) at interpreter.c:474 #8 0x0808592a in Parrot_runcode (interpreter=0x8133be8, argc=1, argv=0xbfffe148) at embed.c:304 #9 0x080bf38a in main (argc=1, argv=0xbfffe148) at test_main.c:49 #10 0x400b4627 in __libc_start_main (main=0x80bf2f8 , argc=2, ubp_av=0xbfffe144, init=0x8048e34 <_init>, fini=0x80bf650 <_fini>, rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xbfffe13c) at ../sysdeps/generic/libc-start.c:129 Simon
Re: I'm back...
On Tue, Jul 30, 2002 at 11:08:46AM -0700, Sean O'Rourke wrote: > On Tue, 30 Jul 2002, Dan Sugalski wrote: > > I need to get Larry to nail some things down. On the one hand, he's > > said that chained comparisons evaluate their parameters just once. > > That argues for moving the values to N or S registers. > > I read that as "expressions are evaluated once", not "PMC's are accessed > once". That was my understanding too. Graham.
Re: I'm back...
At 7:28 PM +0100 7/30/02, Graham Barr wrote: >On Tue, Jul 30, 2002 at 11:08:46AM -0700, Sean O'Rourke wrote: >> On Tue, 30 Jul 2002, Dan Sugalski wrote: >> > I need to get Larry to nail some things down. On the one hand, he's >> > said that chained comparisons evaluate their parameters just once. >> > That argues for moving the values to N or S registers. >> >> I read that as "expressions are evaluated once", not "PMC's are accessed >> once". > >That was my understanding too. If that's true, then I'm happy. (And I can live with being the only person confused about this, since it doesn't hurt to check) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #15846] [PATCH] lexical scope ops, test and example
# New Ticket Created by Jonathan Sillito
# Please include the string: [perl #15846]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15846 >
This patch supersedes my previous lexical scope patch
http://rt.perl.org/rt2/Ticket/Display.html?id=15800 >
In this implementation, find_lex and store_lex only operate on the
current pad, and open_lex/close_lex have been renamed to
new_pad/pop_pad.
The implementation is still quite simple (no pad descriptors, no
accessing by index), but is at least a start on what is needed.
The files affected by the patch are:
- core.ops: added implementation the 4 ops.
- dod.c: added interpreter->ctx.pad_stack to the initial first dod pass
(I am not sure how to test if this is correct ...)
- interpreter.c and interpreter.h: added pad_stack to Parrot_Context.
In addition to the patch an updated test and example pasm file are
attached:
- lexicals.t: simple tests for the 4 ops that should to in t/op/
- lexicals.pasm: simple example that should go in examples/assembly/
Again, comments welcome.
--
Jonathan Sillito
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/32009/26690/0ce4d7/lex.patch
-- attachment 2 --
url: http://rt.perl.org/rt2/attach/32009/26691/38d4e4/lexicals.t
-- attachment 3 --
url: http://rt.perl.org/rt2/attach/32009/26692/dc2ab1/lexicals.pasm
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.187
diff -u -r1.187 core.ops
--- core.ops 26 Jul 2002 19:15:56 - 1.187
+++ core.ops 30 Jul 2002 18:42:45 -
@@ -3604,6 +3604,23 @@
+=item B()
+
+Create a new lexical scope pad and push it onto the
+current lexical scope stack.
+
+=item B()
+
+Pop the current lexical scope pad off the stack
+
+=item B(in PMC, in STR)
+
+Store object $1 as lexical symbol $2
+
+=item B(in PMC, in STR)
+
+Find the lexical variable named $2 and store it in $1
+
=item B(in PMC, in STR)
Store global $1 as global symbol $2
@@ -3613,6 +3630,41 @@
Find the global named $2 and store it in $1
=cut
+
+op new_pad() {
+PMC* hash = pmc_new(interpreter, enum_class_PerlHash);
+stack_push(interpreter, &interpreter->ctx.pad_stack, hash, STACK_ENTRY_DESTINATION, STACK_CLEANUP_NULL);
+
+goto NEXT();
+}
+
+op pop_pad() {
+stack_pop(interpreter, &interpreter->ctx.pad_stack, NULL, STACK_ENTRY_DESTINATION);
+goto NEXT();
+}
+
+op store_lex(in PMC, in STR) {
+PMC * hash = NULL;
+KEY key;
+Stack_entry_type type = 0;
+MAKE_KEY(key, $2, enum_key_string, struct_val);
+hash = (PMC *)stack_peek(interpreter, interpreter->ctx.pad_stack, &type);
+hash->vtable->set_pmc_keyed(interpreter, hash, NULL, $1, &key);
+goto NEXT();
+}
+
+op find_lex(out PMC, in STR) {
+PMC * hash = NULL;
+KEY key;
+Stack_entry_type type = 0;
+MAKE_KEY(key, $2, enum_key_string, struct_val);
+hash = (PMC *)stack_peek(interpreter, interpreter->ctx.pad_stack, &type);
+$1 = hash->vtable->get_pmc_keyed(interpreter, hash, &key);
+
+/* FIXME: should the not found case be an internal_exception ? */
+
+goto NEXT();
+}
op store_global(in PMC, in STR) {
KEY key;
Index: dod.c
===
RCS file: /cvs/public/parrot/dod.c,v
retrieving revision 1.8
diff -u -r1.8 dod.c
--- dod.c 23 Jul 2002 07:25:02 - 1.8
+++ dod.c 30 Jul 2002 18:42:45 -
@@ -92,6 +92,23 @@
}
}
+/* Walk lexical pad stack */
+cur_stack = interpreter->ctx.pad_stack;
+while (cur_stack) {
+if (cur_stack->buffer) {
+ buffer_lives(cur_stack->buffer);
+ entry = (Stack_Entry_t *)(cur_stack->buffer->bufstart);
+ for (i = 0; i < cur_stack->used; i++) {
+if (STACK_ENTRY_PMC == entry[i].entry_type &&
+entry[i].entry.pmc_val) {
+last = mark_used(entry[i].entry.pmc_val, last);
+}
+ }
+ }
+
+cur_stack = cur_stack->prev;
+}
+
/* Finally the general stack */
cur_stack = interpreter->ctx.user_stack;
Index: interpreter.c
===
RCS file: /cvs/public/parrot/interpreter.c,v
retrieving revision 1.93
diff -u -r1.93 interpreter.c
--- interpreter.c 18 Jul 2002 04:29:39 - 1.93
+++ interpreter.c 30 Jul 2002 18:42:45 -
@@ -570,6 +570,9 @@
interpreter->DOD_block_level--;
interpreter->GC_block_level--;
+/* Stack for lexical pads */
+interpreter->ctx.pad_stack = new_stack(interpreter);
+
/* Need a user stack */
interpreter->ctx.user_stack = new_stack(interpreter);
Index: include/parrot/interpreter.h
===
Targeting Parrot slides
The slides for the talk I presented at the O'Reilly Open Source conference last week in Sad Diego are now available: http://www.astray.com/targeting_parrot/ Note that more Parrot talks are at http://www.parrotcode.org/talks/ FYI The conference went well and I'm sure Dan will get his slides up soon. BTW anyone want to work on getting Parrot to use less memory so it can run on palmtops? ;-) Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ Try? Try not. Do, or do not. There is no try
[perl #15850] [PATCH] imcc - interference analysis again
# New Ticket Created by Angel Faus
# Please include the string: [perl #15850]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15850 >
Hi,
This patch makes imcc again take in account the data-flow information
gathered, in order to reduce the number of interferences between
vars.
It apparently does this without even segfaulting. :)
It's tested with the perl6 compiler, and it passes the same number of
tests (so things don't get worse at least)
-àngel
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/32017/26698/c87def/imcc_patch.diff
diff -ur imcc/cfg.c imcc_patched/cfg.c
--- imcc/cfg.c Sun Jul 21 07:43:04 2002
+++ imcc_patched/cfg.c Wed Jul 31 05:05:13 2002
@@ -143,7 +143,7 @@
for(i = 0; i < HASH_SIZE; i++) {
SymReg * r = hash[i];
for(; r; r = r->next) {
- if (r->type == VTIDENTIFIER)
+ if (r->type == VTIDENTIFIER || r->type == VTREG)
analyse_life_symbol(r);
}
}
diff -ur imcc/imc.c imcc_patched/imc.c
--- imcc/imc.c Mon Jul 29 09:56:18 2002
+++ imcc_patched/imc.c Wed Jul 31 05:05:13 2002
@@ -158,7 +158,8 @@
*/
int interferes(SymReg * r0, SymReg * r1) {
-
+
+int i;
/* Register doesn't interfere with itself, and register sets
* don't interfere with each other.
*/
@@ -181,13 +182,15 @@
/* Now: */
-/* XXX This caused core dumps because l0 and l1 are not initialized.
- * Disabling for now
- */
-#if 0
for (i=0; i life_info == NULL) return 0;
+ if (r1->life_info == NULL) return 0;
+ l0 = r0->life_info[i];
+ l1 = r1->life_info[i];
+
if ( (l0->flags & LF_lv_all&& l1->flags & LF_lv_inside)
|| (l0->flags & LF_lv_inside && l1->flags & LF_lv_all)
|| (l0->flags & LF_lv_in && l1->flags & LF_lv_in)
@@ -211,7 +214,6 @@
}
}
}
-#endif
return 1;
}
Re: Targeting Parrot slides
On Tue, 30 Jul 2002, Leon Brocard wrote: > The slides for the talk I presented at the O'Reilly Open Source > conference last week in Sad Diego are now available: > http://www.astray.com/targeting_parrot/ > Note that more Parrot talks are at http://www.parrotcode.org/talks/ > > FYI The conference went well and I'm sure Dan will get his slides up > soon. BTW anyone want to work on getting Parrot to use less memory so > it can run on palmtops? ;-) > I'm told it will take much more than just reducing the memory it uses. Daniel Grunblatt. > Leon > -- > Leon Brocard.http://www.astray.com/ > scribot.http://www.scribot.com/ > > Try? Try not. Do, or do not. There is no try >
Re: of Mops, jit and perl6
On Sun, 28 Jul 2002, Leopold Toetsch wrote: > [lt@thu8:~/src/parrot-007/examples/mops] > $ perl mops.pl > Iterations:1000 > M op/s:2.22 > > (Iteration count for mops.pl was reduced, patch sent) > > Summary: > Program > Mops > perl5.005_03 > 2.2 > perl6 > 0.3 > perl6 jit 1.1 > parrot interpreted 18 > parrot compiled 200 > parrot jit363 > plain c 366 > > Remarks: > - jit is a lot faster then compiled > - plain mops.c is only slightly faster the jit, i.e. 1% > - perl6-jit, albeit still totally unoptimized, doesn't compare too bad >to perl5 > - mops is a silly test ;-) > You didn't use -O3 while compiling mops.c, did you? Daniel Grunblatt.
Re: ARM Jit v2
On Mon, Jul 29, 2002 at 10:34:00PM -0300, Daniel Grunblatt wrote: > On Mon, 29 Jul 2002, Nicholas Clark wrote: > > > Here's a very minimal ARM jit framework. It does work (at least as far as > > passing all 10 t/op/basic.t subtests, and running mops.pbc) > > Cool, I have also been playing with ARM but your approach is in better > shape. (I'll send you a copy of what I got here anyway because it's bit > more documented and you might want to merge it). It's very documented, and I did merge it. Thanks. Expect to recognise large chunks of it in a day or two when I get to a suitable point to submit a better patch. > Yes, function calls are generally slower than computing a goto. > > 7: Debian define the archname on their perl as "arm", whereas building from > >the source tree gets me armv4l (from uname) hence the substitution for > >armv[34]l? down to arm. I do have a machine with an ARM3 here (which I > >think would be armv2) but it is 14 years old, and doesn't currently have > >Linux on it (or a compiler for RISC OS, and I'm not feeling up to > >attempting a RISC OS port for parrot just to experiment with JITs) > >It's probably quite feasible to make the JIT work on everything back to > >the ARM2 (ARM1 was the prototype and I believe was never used in any > >hardware available outside Acorn, and IIRC all ARM1 doesn't have is the > >multiply instruction, so it could be done) > > Ofcourse I didn't even noticed about all those problem, I'm using TD's > ARM. Well, I didn't notice it the first time I worked on the JIT. I found that /usr/bin/perl decided I was on an "arm", and /usr/local/bin/perl decided "arm4l". (version 4 instructions, plus long multiply) > > I'll start writing some real JIT ops over the next few days, although > > possibly only for the ops mops and life use :-) > > Yay!, the ARM will be the first one with string opcodes jitted, I'm > looking forward to see if we get good speed up. Er, because I'm going to be writing the string opcodes? :-) > > Oh, and prepare an acceptable version of this patch once people decide what > > is acceptable Hint. Please. (Dan?) On Mon, Jul 29, 2002 at 11:04:58PM -0300, Daniel Grunblatt wrote: > I thing I forgot to tell is that I also have added a constant pool which > could be usefull for the ARM too, it's on my local tree,I don't know > exactly when I'm going to finish it. Useful. I suspect I can live without it, with the temporary pain of extra branches round inlined constants. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: drive-by-reminder: missing JITs
On Tue, Jul 30, 2002 at 08:45:58PM +0300, Jarkko Hietaniemi wrote: > For the HPPA and IA64 I think getting an account in the HP/CPQ Test > Drive machines should help: > > http://www.testdrive.compaq.com/ > > For MIPS, I dunno whether SGI has something similar. PlayStation is little endian mips, so it would be interesting if one core can do both that and the big endian SGI. There are some big endian ARM development boards out there, but I don't think there are any consumer products running big endian, and I've not been "good" in being endian neutral. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
On JITs and regexps (was several threads)
On Mon, Jul 29, 2002 at 09:47:53PM +, Angel Faus wrote: > I've made a patch for the regex engine, designed with the single goal > of seriously cheating for speed. :-) And what would be unperlish about this "cheating" concept? :-) > Anyway, this patch has brought me the personal conviction that parrot > regexes can be as fast or faster than their perl equivalents, if we > put a bit of effort on optimitzation. This sounds very promising. Thanks for doing this. On Mon, Jul 29, 2002 at 10:34:00PM -0300, Daniel Grunblatt wrote: > On Mon, 29 Jul 2002, Nicholas Clark wrote: > > [although I strongly suspect that JITting the ops the regexps compile down > > to would be the first real world JIT priority. How fast would perl6 regexps > > be with that?] > > Yes, that should be one of the priorities. On Tue, Jul 30, 2002 at 01:21:30PM -0400, Dan Sugalski wrote: > At 10:34 PM -0300 7/29/02, Daniel Grunblatt wrote: > >On Mon, 29 Jul 2002, Nicholas Clark wrote: > > > As you can see from the patch all it does is implement the end > >and noop ops. > >> Everything else is being called. Interestingly, JITing like this is > >> slower > >> than computed goto: > > > >Yes, function calls are generally slower than computing a goto. > > Yup. There's the function preamble and postamble that get executed, > which can slow things down relative to computed goto, which doesn't > have to execute them. > > This brings up an interesting point. Should we consider making at > least some of the smaller utility functions JITtable? Not the opcode > functions, but things in string.c or pmc.c perhaps. (Or maybe getting > them inlined would be sufficient for us) I'm not sure. Effectively we'd need to define them well enough that we can support n parallel implementations - 1 in C for "everyone else", and 1 per JIT architecture. On Tue, Jul 30, 2002 at 03:14:48PM -0300, Daniel Grunblatt wrote: > Yes, we can do that, we can also try to go in and out from the computed > goto core if available. This sounds rather scary to me. I've managed to delete a message (I think by Simon Cozens) which said that perl5 used to have a good speed advantage over the competition, but they'd all been adding optimisations to their regexp engines (that we had already) and now they're as fast. My thoughts are: If on a particular platform we don't have a JIT implementation for a particular op then we have to JIT a call to that op's C implementation. Do enough of these (what proportion?) and the computed goto core is faster than the JIT. I think (I could look at the source code, but that would break a fine Usenet tradition) that for ops not in the computed goto core we have to make a call from either JIT or computed goto core, so there's no speed difference on them. *BUG* Also, we are currently failing to distinguish the size of INTVALs and NUMVALs in our JIT names (so this makes 4 possible JIT variants on most CPUs) IIRC there are currently >500 ops in the core, which makes it unlikely that we'll have sufficient people to JIT most ops on most CPUs. So we have the danger of the JIT being slower in the general case. IIRC the intent was that regexps would compile to regular parrot subs I would assume (please correct me) that the regexp engine is only going to use a small subset of parrot's ops in the subroutines it generates. Therefore, can we make it so that on a JIT-enabled platform the JIT can be run optionally over individual subs, replacing them with JITted versions? That way, perl could compile its regexps to a sub of opcodes, and then we can JIT that sub into native code. We'd only have to ensure that the majority of regexp related ops (ie rx and core ops used) to be fast than the GC core. (Rather than the majority of all the ops commonly used) [We might want to make it a pragmatic hint flag on the regexp to say "please try harder to optimise this regexp", with one form of "harder" being the JIT. Also, we might like to provide an attribute to hint that a particular sub would like to be optimised more] Hopefully regexps run as native code would give perl6 a stonking great advantage in the regexp speed arms race :-) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
[perl #15865] SGI: two errors, one warning
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #15865] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=15865 > Regarding the remaining warnings from perl #15805: SGI cc takes really unkindly to them (IOW, refuses to compile) === 1 === === 2 === Also, one more void return is detected === 3 ===. === 1 === cc -n32 -D_BSD_TYPES -D_BSD_TIME -woff 1009,1110,1174,1184,1552 -OPT:Olimit=0:space=ON -I/usr/local/include -DLANGUAGE_C -I../include -o coroutine.o -c coroutine.c cc-1140 cc: WARNING File = coroutine.pmc, Line = 329 A value of type "struct Parrot_Sub *" cannot be used to initialize an entity of type "struct Parrot_Coroutine *". struct Parrot_Coroutine* co = (struct Parrot_Sub*)pmc->data; ^ cc-1119 cc: ERROR File = coroutine.pmc, Line = 333 The "return" expression type differs from the function return type. return co->init; ^ cc-1119 cc: ERROR File = coroutine.pmc, Line = 336 The "return" expression type differs from the function return type. return co->resume; ^ 2 errors detected in the compilation of "coroutine.c". *** Error code 2 (bu21) *** Error code 1 (bu21) === 2 === cc -n32 -D_BSD_TYPES -D_BSD_TIME -woff 1009,1110,1174,1184,1552 -OPT:Olimit=0:space=ON -I/usr/local/include -DLANGUAGE_C -I../include -o sub.o -c sub.c cc-1119 cc: ERROR File = sub.pmc, Line = 331 The "return" expression type differs from the function return type. return ((struct Parrot_Sub*)pmc->data)->init; ^ 1 error detected in the compilation of "sub.c". *** Error code 2 (bu21) === 3 === cc -n32 -D_BSD_TYPES -D_BSD_TIME -woff 1009,1110,1174,1184,1552 -OPT:Olimit=0:space=ON -I/usr/local/include -DLANGUAGE_C -I./include -o core_ops.o -c core_ops.c cc-1116 cc: WARNING File = core.ops, Line = 4260 Non-void function "Parrot_callcc_p" (declared at line 4247) should return a value. } ^ -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
[perl #15870] [PATCH] UNICOS/mk: need hint ld
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #15870] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=15870 > (Kind of a patch...) It seems that UNICOS/mk needs ld to be cc for Configure.pl to work (the alignment test fails with "CRAY-T3E not found" in test.ldo): Therefore, here is the kind of a patch: cp config/init/hints/dec_osf.pl config/init/hints/unicosmk.pl echo config/init/hints/unicosmk.pl >> MANIFEST sort -o MANIFEST MANIFEST But then the compiler dies over the same errors SGI's did (see [perl #15865]), which is not surprising since it is the same MIPS cc (for Alpha chips, which Cray-T3X still use, and Digital used to use before porting the GEM cc to Tru64) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: [perl #15846] [PATCH] lexical scope ops, test and example
At 06:56 PM 7/30/2002 +, via RT wrote: ># New Ticket Created by Jonathan Sillito ># Please include the string: [perl #15846] ># in the subject line of all future correspondence about this issue. ># http://rt.perl.org/rt2/Ticket/Display.html?id=15846 > > > >This patch supersedes my previous lexical scope patch >http://rt.perl.org/rt2/Ticket/Display.html?id=15800 > Applied, thanks Jonathan. -Melvin
Re: [perl #15850] [PATCH] imcc - interference analysis again
At 07:21 PM 7/30/2002 +, via RT wrote: ># New Ticket Created by Angel Faus ># Please include the string: [perl #15850] ># in the subject line of all future correspondence about this issue. ># http://rt.perl.org/rt2/Ticket/Display.html?id=15850 > > >This patch makes imcc again take in account the data-flow information >gathered, in order to reduce the number of interferences between >vars. Applied. Sean, might want to test the effects on P6C. -Melvin
Re: [PATCH] [perl #15267] Re: [perl fix rot in pxs and Qt example broken
At 02:48 PM 7/22/2002 +, Stéphane Payrard wrote: >On Sun, Jul 21, 2002 at 02:05:42PM +, s. payrard @ wanadoo. fr wrote: > > # New Ticket Created by [EMAIL PROTECTED] > > # Please include the string: [perl #15267] > > # in the subject line of all future correspondence about this issue. > > # http://rt.perl.org/rt2/Ticket/Display.html?id=15267 > Resubmit this as a unified diff and I'll toss it in. -Melvin
[perl #15872] UNICOS/mk: statics need not apply?
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #15872] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=15872 > cc -DNO_RCHECK -I/usr/local/include -I./include -o platform.o -c platform.c CC-5 cc: ERROR File = platform.c, Line = 7 The source file "dlfcn.h" is unavailable. #include ^ 1 error detected in the compilation of "platform.c". Well, UNICOS/mk does not have dynamic loading of any kind. Are static builds of Parrot not supported? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
maybe-PATCH: sub/continuation/dlsym/coroutine clean-up
This patch implements native extensions and continuations as pmcs. It also cleans up the existing Sub and Coroutine types, and removes the following now-obsolete ops: callco callcc capturecc call callnative These are all handled through various uses of "invoke" (see t/pmc/sub.t for simple examples). The patch also fixes some GC unfriendliness issues with stack-copying for continuations. Good things: - less ops - maybe even less lines of code Things that could be better: - it fixes stack-copying by reaching in and turning off GC. - testing is light (though the continuations work for P6C's exception-handling as well). - take a look at "new" in core.ops. Creating a new continuation captures context, but the register holding that continuation is part of the context. Unfortunately, it doesn't know what register it's in until after it captures the context, so it has to go back and fill that in afterwards. Blech. - the way continuations work has the interesting side-effect that you can capture context in one place, but tell the continuation to resume somewhere else. - not integrated with lexicals. Parrot is a fast-moving target nowadays! - the new utility functions it adds live in continuation.pmc and csub.pmc. This is probably not a good permanent home -- some should go into the PXS API, some elsewhere. Not sure where, so I put them all in one place for the moment, so they're easy to keep track of. Anyways, please try these out and let me know if you run into problems, or hate the design, or can think of a better way, or whatever. /s subs.tgz Description: Binary data
[perl #15876] [PATCH] rx.dev and rx.c documentation
# New Ticket Created by Stephen Rawls # Please include the string: [perl #15876] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=15876 > NOTE: I'm resending this now that the minitutorial has come out saying how to send updates. The machine I'm using (Solaris 5.7) doesn't have a -u option for diff, so I used diff -e. If that's a problem I can log onto a different machine tommorow and recreate the diff file. In light of the recent discussion on .dev files I've updated this. It now describes how bitmaps work, and the reason to use them over other methods. Also attached is an update to rx.c, which adds the comments that were in rx.dev next to the actual functions in rx.c. Thanks! Stephen Rawls __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- attachment 1 -- url: http://rt.perl.org/rt2/attach/32145/26748/4c8a06/rx.dev -- attachment 2 -- url: http://rt.perl.org/rt2/attach/32145/26749/fa98f1/rx.c.diff rx.dev Description: rx.dev rx.c.diff Description: rx.c.diff
Over-eager spam filtering runs amuck
In my never-ending crusade to try and keep the bug system from passing on lots of spam, some messages have been falsely flagged as spam. Please look at tickets 15748 and 15877. We've done a bunch of tweaking tonight, so hopefully the falsepos count will drop and falseneg count will go up. In good news, we recieve an amazing amount of spam at the bugtracker's various addresses, and at least 95% of it is properly caught. -R (at least a week behind on p6i.)
[perl #15879] [PATCH] UNICOS/mk ld hinting
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #15879] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=15879 > Using ld for ld does not work. diff -ruN parrot/config/init/hints/unicosmk.pl parrot+cast/config/init/hints/unicosmk.pl --- parrot/config/init/hints/unicosmk.pl1970-01-01 02:00:00.0 +0200 +++ parrot+cast/config/init/hints/unicosmk.pl 2002-07-31 07:43:54.0 +0300 @@ -0,0 +1,3 @@ +Configure::Data->set( + ld => "cc" +); diff -ruN parrot/MANIFEST parrot+cast/MANIFEST --- parrot/MANIFEST 2002-07-29 07:43:21.0 +0300 +++ parrot+cast/MANIFEST2002-07-31 07:43:29.0 +0300 @@ -75,6 +75,7 @@ config/init/hints/dec_osf.pl config/init/hints/mswin32.pl config/init/hints/os2.pl +config/init/hints/unicosmk.pl config/init/hints/vms.pl config/init/manifest.pl config/init/miniparrot.pl -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
[perl #15880] [PATCH] generic platform.c should not assume dynaloading
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #15880]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15880 >
I think the generic platform.c should not assume dynamic loading.
This patch helps enough so that UNICOS/mk (which has only static
loading) compiles and tests okay.
diff -ruN parrot/config/gen/platform/generic.c
parrot+cast/config/gen/platform/generic.c
--- parrot/config/gen/platform/generic.c2002-06-10 00:12:42.0 +0300
+++ parrot+cast/config/gen/platform/generic.c 2002-07-31 08:02:40.0 +0300
@@ -70,7 +70,11 @@
void *
Parrot_dlopen(const char *filename)
{
+#ifdef HAS_DLOPEN
return dlopen(filename, PARROT_DLOPEN_FLAGS);
+#else
+return 0;
+#endif
}
@@ -81,7 +85,11 @@
const char *
Parrot_dlerror(void)
{
+#ifdef HAS_DLOPEN
return dlerror();
+#else
+return 0;
+#endif
}
@@ -92,7 +100,11 @@
void *
Parrot_dlsym(void *handle, const char *symbol)
{
+#ifdef HAS_DLOPEN
return dlsym(handle, symbol);
+#else
+return 0;
+#endif
}
@@ -103,7 +115,11 @@
int
Parrot_dlclose(void *handle)
{
+#ifdef HAS_DLOPEN
return dlclose(handle);
+#else
+return -1;
+#endif
}
/*
diff -ruN parrot/tools/dev/lib_deps.pl parrot+cast/tools/dev/lib_deps.pl
--- parrot/tools/dev/lib_deps.pl2002-06-08 03:43:54.0 +0300
+++ parrot+cast/tools/dev/lib_deps.pl 2002-07-31 08:04:01.0 +0300
@@ -330,6 +330,7 @@
ctime time.h
difftimetime.h
div stdlib.h
+dlopen dlfcn.h
erf math.h
erfcmath.h
erfcf math.h
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
[perl #15882] [PATCH] Test.pm glitch
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #15882]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15882 >
I thought "exit code 0.01171875" was odd.
diff -ruN parrot/lib/Parrot/Test.pm parrot+cast/lib/Parrot/Test.pm
--- parrot/lib/Parrot/Test.pm 2002-07-29 10:59:28.0 +0300
+++ parrot+cast/lib/Parrot/Test.pm 2002-07-31 08:11:50.0 +0300
@@ -40,7 +40,7 @@
}
system "$^X -e \"$redir_string;system q{$command};\"";
- my $exit_code = $? / 256;
+ my $exit_code = $? >> 8;
$Builder->diag("'$command' failed with exit code $exit_code") if $exit_code;
}
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: [perl #15879] [PATCH] UNICOS/mk ld hinting
At 05:21 AM 7/31/2002 +, via RT wrote: ># New Ticket Created by Jarkko Hietaniemi ># Please include the string: [perl #15879] ># in the subject line of all future correspondence about this issue. ># http://rt.perl.org/rt2/Ticket/Display.html?id=15879 > > > >Using ld for ld does not work. Applied. -Melvin
[perl #15883] [PATCH] can't do bit arithmetics with enums
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #15883] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=15883 > SGI cc gets upset by enum bit arithmetics. diff -ruN parrot/stacks.c parrot+cast/stacks.c --- parrot/stacks.c 2002-07-04 23:39:44.0 +0300 +++ parrot+cast/stacks.c2002-07-31 07:47:03.0 +0300 @@ -90,7 +90,7 @@ last = new_chunk; } new_chunk->used = old_chunk->used; -new_chunk->flags = old_chunk->flags & ~STACK_CHUNK_COW_FLAG; +new_chunk->flags = (Stack_chunk_flags)((int)old_chunk->flags & +~(int)STACK_CHUNK_COW_FLAG); /* Can't do bit arithmetics on enums. */ /* Copy stack buffer */ new_chunk->buffer = new_buffer_header(interp); Parrot_allocate(interp, new_chunk->buffer, -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: [perl #15880] [PATCH] generic platform.c should not assume dynaloading
At 05:24 AM 7/31/2002 +, via RT wrote: ># New Ticket Created by Jarkko Hietaniemi ># Please include the string: [perl #15880] ># in the subject line of all future correspondence about this issue. ># http://rt.perl.org/rt2/Ticket/Display.html?id=15880 > > > >I think the generic platform.c should not assume dynamic loading. >This patch helps enough so that UNICOS/mk (which has only static >loading) compiles and tests okay. Applied. -Melvin
Re: [perl #15882] [PATCH] Test.pm glitch
At 05:26 AM 7/31/2002 +, via RT wrote: ># New Ticket Created by Jarkko Hietaniemi ># Please include the string: [perl #15882] ># in the subject line of all future correspondence about this issue. ># http://rt.perl.org/rt2/Ticket/Display.html?id=15882 > > > >I thought "exit code 0.01171875" was odd. Applied. -Melvin
Re: [perl #15883] [PATCH] can't do bit arithmetics with enums
At 05:28 AM 7/31/2002 +, via RT wrote: ># New Ticket Created by Jarkko Hietaniemi ># Please include the string: [perl #15883] ># in the subject line of all future correspondence about this issue. ># http://rt.perl.org/rt2/Ticket/Display.html?id=15883 > > > >SGI cc gets upset by enum bit arithmetics. Eep, that would be mine. Applied thanks. -Melvin
[perl #15885] [PATCH] string.t hangs on perl 5.005_03
# New Ticket Created by Leopold Toetsch # Please include the string: [perl #15885] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=15885 > Hi, attached Patch fixes a small problem with string_2.pasm. assemple.pl:_annotate_contents() hangs on removing the trailing comment. Propably the RE is too complex for 5.005_03. leo -- attachment 1 -- url: http://rt.perl.org/rt2/attach/32436/26776/63f47e/t_op_string.t.diff --- ../parrot/t/op/string.t Sat Jul 27 23:21:01 2002 +++ t/op/string.t Wed Jul 31 08:52:21 2002 @@ -22,7 +22,8 @@ clone S1, "Bar\n" print S1 -chopn S1, 1 # Check that the contents of S1 are no longer constant + # Check that the contents of S1 are no longer constant +chopn S1, 1 print S1 print "\n"
Re: of Mops, jit and perl6
Daniel Grunblatt wrote: > On Sun, 28 Jul 2002, Leopold Toetsch wrote: [ Mops ] >>plain c 366 > You didn't use -O3 while compiling mops.c, did you? No. Just Makefile's options as defined. But interesting idea. It makes the inner loop look like this: ..L492: decl %ebx jnz .L492 and doubles the Mops ;-) > Daniel Grunblatt. leo
