Re: [perl #16274] [PATCH] Keyed access
In message <[EMAIL PROTECTED]> Mike Lambert <[EMAIL PROTECTED]> wrote: > Anyways, cd to languages/BASIC, run basic.pl, type "LOAD wumpus", and > watch it die on "Not a string!". It could be that basic is using keys in > weird ways, or it could be that the key patch is borked...I haven't looked > into it enough to determine the true cause here. The problem is that it is trying to index a hash using a number and that is no longer allowed. At some point it is going to be allowed again, but it won't do what the code there wants it to do - it won't stringify the number and then use that as a key. What it will do is some sort of back door reference directly to an entry in the hash table without going through a hash lookup. Dan has said that this is needed for efficient access to scratchpads or something although I'm not quite sure how it is supposed to work given that the hash may decide to rearrange itself if it gets too full. What the BASIC interpreter probably needs to do is stringify those keys itself before trying to look them up. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu
Re: [perl #16274] [PATCH] Keyed access
? basic.pbc ? merged_basic.pasm Index: basicvar.pasm === RCS file: /cvs/public/parrot/languages/BASIC/basicvar.pasm,v retrieving revision 1.10 diff -u -r1.10 basicvar.pasm --- basicvar.pasm 20 Jun 2002 00:05:09 - 1.10 +++ basicvar.pasm 21 Aug 2002 07:51:21 - @@ -166,22 +166,26 @@ restore I0# Line number to fetch. set I2, I0 eq I0, -1, CFETCHSTART -set S0, P22[I0] + set S0, I0 +set S0, P22[S0] ne S0, "", CFETCHEND # Not found. Let's see if this is a +1 dec I0 -set S0, P22[I0] + set S0, I0 +set S0, P22[S0] ne S0, "", CFETCHNEXT branch CNOTFOUND CFETCHNEXT: -set I1, P23[I0] # Okay, got the line before + set S0, I0 +set I1, P23[S0] # Okay, got the line before inc I1 gt I1, I28, COVERFLOW set I0, P24[I1] # Next line number is... eq I0, 0, COVERFLOW -set S0, P22[I0] # Fetch it. + set S0, I0 +set S0, P22[S0] # Fetch it. ne S0, "", CFETCHEND branch CNOTFOUND # This is a should-not-happen, I think. @@ -190,7 +194,8 @@ gt I6, I28, COVERFLOW set I0, P24[I6] eq I0, 0, COVERFLOW -set S0, P22[I0] # Fetch line + set S0, I0 +set S0, P22[S0] # Fetch line ne S0, "", CFETCHEND branch CNOTFOUND # This is a should-not-happen, I think. @@ -241,7 +246,8 @@ CLOAD: set I0, 0 CNEXT: gt I0, I28, CEND set I3, P24[I0] # Get the next line -set S1, P22[I3] # Get the line code itself + set S1, I3 +set S1, P22[S1] # Get the line code itself inc I0 eq I3, I1, CNEXT # Skip this, it's being replaced. save S1 @@ -271,9 +277,10 @@ restore S0 # Code line set I1, S0 # Line Number -set P22[I1], S0 # The line itself + set S1, I1 +set P22[S1], S0 # The line itself inc I28 -set P23[I1], I28 # Index back to array +set P23[S1], I28 # Index back to array set P24[I28], I1 dec I5 branch STOREC Index: instructions.pasm === RCS file: /cvs/public/parrot/languages/BASIC/instructions.pasm,v retrieving revision 1.10 diff -u -r1.10 instructions.pasm --- instructions.pasm 20 Jun 2002 00:05:09 - 1.10 +++ instructions.pasm 21 Aug 2002 07:51:21 - @@ -898,7 +898,8 @@ LIST_ONE_LINE: - set S0, P22[I2] + set S0, I2 + set S0, P22[S0] print S0 print "\n" branch END_LIST @@ -917,7 +918,8 @@ DO_I_LIST: set I0, 0 DOLISTL: gt I0, I28, END_LIST set I1, P24[I0] # Get the next line -set S0, P22[I1] # Get the line code itself + set S0, I1 +set S0, P22[S0] # Get the line code itself eq I3, -1, LIST_SHOW lt I2, I1, LIST_NEXT gt I3, I1, LIST_NEXT
Re: GC generation?
[EMAIL PROTECTED] (Dan Sugalski) writes: > Rollover won't really matter much, if we're careful with how we > document things. Still, a UINTVAL should be at least 2^32--do you > really think we'll have that many GC generations in a few hours? ... but having stuff running for months and months isn't that uncommon. :-) - ask (bikeshed color expert) -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
design of bytecodes for interpretation
Raph Levien - http://www.advogato.org/person/raph and http://www.levien.com/ - talks about bytecode interpreters at http://www.advogato.org/person/raph/diary.html?start=261 With references to David McCusker http://treedragon.com/ged/map/ti/newAug02.htm#14aug02-stack-machines and to Pierre Phaneuf http://advogato.org/person/pphaneuf/diary.html?start=63 - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: [perl #16274] [PATCH] Keyed access
Tom Hughes wrote: > Index: basicvar.pasm > === ... > Index: instructions.pasm > === ... Fixes the bug, and wumpus plays yet again. Applied, thanks. Mike Lambert
Re: [perl #16269] [PATCH] COW...Again and Again
Just to complete this thread, I have committed the current version of my COW code, as I promised earlier this week. Below is my response to Peter's most recent email. > > Note that the comparison against parrot-grey is not > > exactly fair, because it dodn't use system stackwalking. > > Note that I have only commented out the call to the stackwalk > function - for COW benchmarking purposes you could always > reinstate it. But that is beside the point now - your COW has > been fixed, and the benchmarks confirm that gc_generations > is equally unfriendly to all cows. There will always be programs > that don't benefit and therefore only get the overhead - but in > typical perl usage, I would expect that the majority of programs > will benefit significantly, for example regex capture will be able > to use COWed substrings. Yeah, regex capture should be benefit *big* from COW. It also technically helps make strings act more perl5-like, where you may easily chop characters off the front and end of the string without reallocation. We could even have the non-COW copy collection use strstart and strlen to compact memory usage, giving the best of both worlds for those kinds of applications. > This should finally bring about the demise of grey, as I don't > believe there is room for two totally different implementations > of COW, and my buffer linked list, which is already expensive, > gets absurdly so with the addition of strstart also. This saddens me, and I hope it's not a permanent death. Grey was a very good sanity check for me, at least. It caused us to get a 20% performance in stackwalking (I think), motivated me to improve parrot's cow abilities and performance, and was in general a good wake-up call that some of our decisions were having a negative impact, and should be reconciled. In reality, all that differs between grey's cow and mine, is that mine allows for COWing of substrings with constant strings, and has a modified string.c interface that improves clarity, imo. Fundamentally, it's the original COW you provided a long time ago. I'd hate to make you discontinue your side project because I committed a different implementation of COW that wasn't directly compatible. If you don't mind, please feel free to continue your work on parrot-grey. I'd love to see the other ideas you had mentioned in your previous emails that hadn't yet made it to grey, as some of them didn't sound entirely illegal. You said that parroy grey was a fun project to play around with performance numbers, and I'd hate to be the reason you stopped having fun. :) Thanks, Mike Lambert
Re: [perl #16274] [PATCH] Keyed access
Mike Lambert wrote:
> Anyways, cd to languages/BASIC, run basic.pl, type "LOAD wumpus", and
> watch it die on "Not a string!".
Tracing this beast down, needs attached patch, to cut displayed arg strings.
BTW trace.c nether frees this escaped string.
The last instruction executed is:
PC=1457; OP=102 (set_p_ki_s); ARGS=(P22=0x81565d4, [I1=1], S0="1 REM
Taken from
David Ahl's 101 BASIC G...")
Not a string!
where actually the hash key I1 is not a string.
AFAIK this behaviour is intended.
The key patch is working fine, all perl6 tests succeed as before.
leo
--- debug.c Tue Aug 20 07:06:07 2002
+++ /home/lt/src/parrot-007/debug.c Wed Aug 21 09:39:42 2002
@@ -497,10 +497,19 @@
{
const char *end = string + length;
char *new,*fill;
+int cut = 0;
+#define DISP_LEN 40
/* Return if there is no string to escape*/
if (!string || !*string)
return NULL;
+/* if string is too long, cut it */
+if (length > DISP_LEN) {
+length = DISP_LEN;
+end = string + length;
+cut = 1;
+length += 2;
+}
fill = new = (char *)mem_sys_allocate(length * 2 + 1);
@@ -539,6 +548,11 @@
break;
}
}
+if (cut) {
+*(fill++) = '.';
+*(fill++) = '.';
+*(fill++) = '.';
+}
*fill = '\0';
return new;
}
Re: [perl #16269] [PATCH] COW...Again and Again
Mike Lambert wrote:
> Just to complete this thread, I have committed the current version of my
> COW code, as I promised earlier this week.
Some final 5000 life results from my system, and a few improvements
I believe are still possible:
Before COW: 172 seconds
After COW: 121 seconds
A 30% improvement in performance is not too bad, I suppose.
Well done Mike!
CVS/COW with stack pointer alignment = four: 93 seconds
Above plus pre-mask for PMC/Buffer alignment = four: 90 seconds
The first of these improvements is achieved by determining
the alignment with which pointers are actually placed on the
stack, versus PARROT_PTR_ALIGNMENT, which is the
minimum alignment permitted by the underlying system.
On an Intel x86 platform running linux, I have been unable to
persuade any pointer to live on the stack other than on a
four-byte alignment, except by placing it in a struct, and
telling the compiler to pack structs. A simple C program is
included below which illustrates this point.
The second improvement achieves very little incremental
improvement (possibly more would be achieved if the
first change was not in place). It takes advantage of the
current alignment (again on my specific platform) of
both PMC and Buffer/String structures on 4-byte size
boundaries; this means that the low-order 2 bits of any
valid pointer will always be zero, which can be quickly
checked before the slower checks are performed.
> If you don't mind, please feel free to continue your work on parrot-grey.
The problem arises with trying to do new experimental development,
which still keeping sufficiently in sync with cvs parrot that I can do a
'cvs update' from time to time without getting dozens of conflicts.
A case in point is the new 'strstart' field - grey doesn't need it, but to
leave it out would create a large number of differences between the
two versions, with code having to be changed every time somebody
writes a new reference to it - therefore if I do continue with grey, I will
just probably just leave strstart in, and ignore the memory overhead.
The next item on the list for grey was paged memory allocation - this
may be usable to some extent without the buffer linked lists; so I will
probably give that a spin anyway.
--
Peter Gibbs
EmKel Systems
main()
{
void * a;
void * b;
char c;
void * d;
struct {
void * a;
void * b;
char c;
void * d;
} x;
if (a > b) {
printf("Stack grows downwards\n");
printf("Pointer alignment on stack = %ld\n",
((int)&b - (int)&d) - ((int)&a - (int)&b));
}
else {
printf("Stack grows upwards\n");
printf("Pointer alignment on stack = %ld\n",
((int)&d - (int)&b) - ((int)&b - (int)&a));
}
printf("Pointer alignment in struct = %ld\n",
((int)&x.d - (int)&x.b) - ((int)&x.b - (int)&x.a));
}
Re: GC generation?
I'd have to concur. I'm working on an integration engine entirely in Perl and expect many processes to stay up for months under heavy IO loads. I hope^H^H^H^Hhave confidence that p6 will be a major boon to my efforts, not a hindrance. :-) Mike >>> Ask Bjoern Hansen <[EMAIL PROTECTED]> 08/21/02 03:59AM >>> [EMAIL PROTECTED] (Dan Sugalski) writes: > Rollover won't really matter much, if we're careful with how we > document things. Still, a UINTVAL should be at least 2^32--do you > really think we'll have that many GC generations in a few hours? but having stuff running for months and months isn't that uncommon. :-) - ask (bikeshed color expert) -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
[perl #16689] [NIT] trailing commas in enumerator lists bad
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #16689] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=16689 > Freshly checked out parrot moans a lot: cc: Info: ./include/parrot/string.h, line 56: Trailing comma found in enumerator list. (trailcomma) } TAIL_flags; ^ Trailing commas in enumerator lists is unportable behaviour in C. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: imcc hack for perl6 regexes
At 09:49 PM 8/20/2002 -0700, Sean O'Rourke wrote: >This is what you'll need. It uses dlopen(), and is likely Bad in a number >of other ways, but if you're on a fairly normal UNIX, it should allow imcc >to grok what P6C produces for regexes. Sean, I'm replying publicly because I'd like to hear other opinions than mine, yours, Angel's and Leopold's. I still prefer infix notation to prefix notation for an intermediate language. I don't understand why it is so hard to adopt. imcc is supposed to be a step closer to higher level languages, which is why I went that way. I do realize imcc needs a lot of work (it was just a toy), and I haven't had the time to put into it, for example, a proper code generator like BURG, but I would prefer that people to give me convincing arguments on the syntax issue. What I have heard is, "Why make imcc use a different syntax, it requires people to learn a Parrot assembler _and_ imcc." My answer: 1) People in general don't need to learn either; compiler writers might. 2) If imcc merges toward Parrot syntax, it simply diverges from the next platform we attempt to target that is not similar to Parrot. 3) imcc will, by definition, have different syntax because it supports higher level constructs (if statements, call, subs, classes, etc.) I'm still for what we talked about, where any imcc directive uses a leading '.' and the rest of the ops are passed through; with the primary exemption being those ops like set, add, etc. that have more common infix version like: a = 1 b = a + 1 All other ops could be looked up from libparrot as I think your patch attempts to do. Then we can provide enough metadata so the compiler can know enough to do correct optimization on "pass-through" Parrot ops. -Melvin
[perl #16690] Disable t/src under testj
# New Ticket Created by Daniel Grunblatt
# Please include the string: [perl #16690]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16690 >
This patch disables running the tests in t/src under a make testj.
Apart from that, does anyone know why test doesn't run on OpenBSD?
I get:
ar: illegal option -- s
usage: ar -d [-Tv] archive file ...
ar -m [-Tv] archive file ...
ar -m [-abiTv] position archive file ...
ar -p [-Tv] archive [file ...]
ar -q [-cTv] archive file ...
ar -r [-cuTv] archive file ...
ar -r [-abciuTv] position archive file ...
ar -t [-Tv] archive [file ...]
ar -x [-CouTv] archive [file ...]
*** Error code 1
Daniel Grunblatt.
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/35349/28632/5d0ee0/harness.patch
Index: t/harness
===
RCS file: /cvs/public/parrot/t/harness,v
retrieving revision 1.12
diff -u -r1.12 harness
--- t/harness 15 Aug 2002 05:01:57 - 1.12
+++ t/harness 21 Aug 2002 14:04:54 -
@@ -17,6 +17,7 @@
$ENV{PARROT_QUICKTEST} = grep $_ eq 'quick', @ARGV;
@ARGV = grep $_ ne 'quick', @ARGV;
+my @dir = ($ENV{TEST_PROG_ARGS} =~ /j/) ? ( qw(op pmc) ) : ( qw(src op pmc) );
# Pass in a list of tests to run on the command line, else run all the tests.
-my @tests = @ARGV ? @ARGV : map { glob( "t/$_/*.t" ) } ( qw(src op pmc) );
+my @tests = @ARGV ? @ARGV : map { glob( "t/$_/*.t" ) } @dir;
runtests(@tests);
Re: imcc hack for perl6 regexes
Replying to myself because I forgot to include these files... /s anyop.tgz Description: Binary data
Re: imcc hack for perl6 regexes
> I still prefer infix notation to prefix notation for an intermediate > language. I don't understand why it is so hard to adopt. imcc is supposed > to be a step closer to higher level languages, which is why I went that > way. Hi, I think we all agree that since parrot can have dynamic oplibs (and core parrot has hundreds of ops), imcc needs some way to directly express them. The idea of having parrot ops be included as such, and imcc directives be prepended with "." looks fair to me. So we end having: a) imcc becomes like parrot assembly, but with virtual registers and a few administrative ops (for calls and such), that start with "." or b) imcc becomes like parrot assembly, but with virtual registers, a few administrative ops, and some convenient infix notation like for stuff like "a =1" or "b = a + 1", There isn't much difference between both proposals, when you think about it. The only benefit of proposal b) is that hand-writing of imc becomes nicer, but i would not expect much of it. Additional to the learning benefit for developers of parrot-based languages, the usage of parrot ops "as is" is good for us, because we don't need to invent, develop, and document, another language. It lets us focus on making imcc do well a few tasks (ahem) such as register allocation and language-neutral optimitzations. >From a more conceptual point of view, I would favour imcc being as similiar to the assembler as possible because: - parrot assembler is already very high-level - imcc won't probably be retargeted to a different plataform. If we really wanted to make imcc retargetable, we would need much more than a friendlier syntax; and honestly I am not sure that is worth it. To sum up, my vote would be for a assembler-like imcc. The infix notation doesn't add much value in a intermediate language such as imcc. I am not a priori against imcc diverging from assembly. But I think the only good reason for divergence should be making the task of the language compiler simpler. About the implementation, I think we will need the following metadata about each op: i) the opcode, and the op name. ii) the type of arguments, including in/out/etc.. iii) whether the opcode has side-effects or not. This is important for a number of optimizations: constant-folding, optimitzations that work by moving a instruction to a more convenient point, etc. Best, -angel
Re: imcc hack for perl6 regexes
On Wed, 21 Aug 2002, Angel Faus wrote: > About the implementation, I think we will need the following metadata about > each op: > > i) the opcode, and the op name. > ii) the type of arguments, including in/out/etc.. Both of these are available, though there currently isn't an efficient interface to say "give me all possible sets of parameter types for an op called 'X'" -- you can only look up the op quickly if you know the exact parameter types. This lookup would be easy to add, though. > iii) whether the opcode has side-effects or not. This, unfortunately, is not available. Since many ops just call into vtable methods, it would need to be set in stone in the vtable doc as well, e.g. "the add op MUST NOT appear to have a side-effect", and vtable writers would need to take this into account. /s
Re: [perl #16689] [NIT] trailing commas in enumerator lists bad
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
># New Ticket Created by Jarkko Hietaniemi
># Please include the string: [perl #16689]
># in the subject line of all future correspondence about this issue.
># http://rt.perl.org/rt2/Ticket/Display.html?id=16689 >
>
>
>Freshly checked out parrot moans a lot:
>
>cc: Info: ./include/parrot/string.h, line 56: Trailing comma found in enumerator
>list. (trailcomma)
>} TAIL_flags;
>^
>
>Trailing commas in enumerator lists is unportable behaviour in C.
And in case anyone has not come accross the "trick" before it is not uncommon
to have
enum foo {
/* auto-genererated stuff */
foo_MAX
};
where foo_MAX is a handy "number of entries" value as well
as avoiding the trailing comma issue.
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
Re: [perl #16269] [PATCH] COW...Again and Again
Yay! The COW has landed! All praise the newly bovine Parrot! (Now THAT's an odd image... gimp, anyone?) Favorite quote from the patch: + /* Buffer's memory data is in this header's header pool's memory pool */ Many thanks to Peter and Mike for implementing this and pushing it all the way through. Since this was the one major outstanding patch that I was aware of, what do people think of applying Brent's struct Parrot_Interp cleanup now?
Re: imcc hack for perl6 regexes
On Wed, 21 Aug 2002 18:02:51 +0200 Angel Faus <[EMAIL PROTECTED]> wrote:
>I think we all agree that since parrot can have dynamic oplibs (and core
>parrot has hundreds of ops), imcc needs some way to directly express them.
>The idea of having parrot ops be included as such, and imcc directives be
>prepended with "." looks fair to me.
Ok, then this point is settled.
>a) imcc becomes like parrot assembly, but with virtual registers and a few
>administrative ops (for calls and such), that start with "."
>
>or
>
>b) imcc becomes like parrot assembly, but with virtual registers, a few
>administrative ops, and some convenient infix notation like for stuff like "a
=1" or "b = a + 1",
No. :)
c) imcc becomes a "middle" level language.
I never meant it to be an assembler. In practice
intermediate languages provide other constructs
such as aggregate type definition that are not
available in the assembler.
type i : packed int[32]
type r : record { foo : int, bar : string }
This is not assembler. This is medium level
computer language in my book. You could even
see things like
..pragma classes_are_hashes
or something that would tell the compiler that
aggregates should be implemented as standard
"Perl" hashes in this piece of code, whereas
others might want "packed" aggregates with
no runtime introspection capability.
>the usage of parrot ops "as is" is good for us, because we don't need to
>invent, develop, and document, another language. It lets us focus on making
>imcc do well a few tasks (ahem) such as register allocation and
>language-neutral optimitzations.
But I'm willing to invent and develop another language. And it should be a lot
richer than
just an assembler with a register allocator
and spiller. :)
>I am not a priori against imcc diverging from assembly. But I think the only
>good reason for divergence should be making the task of the language compiler
>simpler.
But that was my whole reason for writing it in
the first place. I did not want to target
the assembler directly.
-Melvin
Re: [perl #16269] [PATCH] COW...Again and Again
On Wed, Aug 21, 2002 at 02:10:22PM +0200, Peter Gibbs wrote: > Mike Lambert wrote: > > If you don't mind, please feel free to continue your work on parrot-grey. > The problem arises with trying to do new experimental development, > which still keeping sufficiently in sync with cvs parrot that I can do a > 'cvs update' from time to time without getting dozens of conflicts. > A case in point is the new 'strstart' field - grey doesn't need it, but to > leave it out would create a large number of differences between the > two versions, with code having to be changed every time somebody > writes a new reference to it - therefore if I do continue with grey, I will > just probably just leave strstart in, and ignore the memory overhead. > The next item on the list for grey was paged memory allocation - this > may be usable to some extent without the buffer linked lists; so I will > probably give that a spin anyway. I know very well what you mean, but this particular case could be bludgeoned to death with a #define strstart bufstart, no? I'm also inclined to think that Peter's parrot-grey experimentation is important enough right now to commit using #ifdef PARROT_GREY. Sure, it's a rotten long-term solution, but we could take it out before too long. (And Peter would have to be okay with other people periodically breaking his stuff by doing commits that don't update the PARROT_GREY path, since most people wouldn't be testing it. But it'd still be easier than maintaining something like that externally.) What do people think? After all, this strongly impacts one of the top stated goals for Parrot: more speed. Oh, and it might have to be only partial, to keep the more "illegal" bits out of CVS. Peter would have to decide whether it would be worth it then. Or we could just commit a test that does a couple of things like longjmp() that will break parrot-grey, and maybe Peter will figure out a way around it. :-)
Re: GC generation?
At 9:03 AM -0400 8/21/02, Mike Litherland wrote: >I'd have to concur. I'm working on an integration engine entirely >in Perl and expect many processes to stay up for months under heavy >IO loads. I hope^H^H^H^Hhave confidence that p6 will be a major >boon to my efforts, not a hindrance. :-) Okay, Okay, I get the point! :) Bad idea. Plan B time. > >>> Ask Bjoern Hansen <[EMAIL PROTECTED]> 08/21/02 03:59AM >>> >[EMAIL PROTECTED] (Dan Sugalski) writes: > >> Rollover won't really matter much, if we're careful with how we >> document things. Still, a UINTVAL should be at least 2^32--do you >> really think we'll have that many GC generations in a few hours? > > but having stuff running for months and months isn't that >uncommon. :-) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: GC generation?
At 2:58 AM -0400 8/21/02, Mike Lambert wrote: > > At 6:16 PM -0400 8/20/02, John Porter wrote: >> >Dan Sugalski wrote: >> >> I expect a UINTVAL should be sufficient to hold the counter. >> > >> >Why? Because you don't expect a perl process to run longer >> >than a couple hours? Or because rollover won't matter? >> >> Rollover won't really matter much, if we're careful with how we >> document things. Still, a UINTVAL should be at least 2^32--do you >> really think we'll have that many GC generations in a few hours? > >Currently, 5000 iterations of life execute in 6 seconds, with 42K DOD >runs. At that rate, we have a rollover every week. Not really a problem, >but if we have code which doesn't allow for rollover, it is a problem. That feels like we're doing far too many DOD runs there, but that's a tuning issue. [Sensible stuff snipped] >So in conclusion, generational systems can be done using at most a byte or >a short, and it's even possible to do them with nothing at all. So until >the need arises, I don't think the generations count would be worth it. >Especially since I plan to try and prove the need for a header pool >pointer at some point. :) Fair enough. It was a fairly stupid suggestion, as we already *have* the counter in the interpreter, and its reasonably obvious that it's not a good idea to use this data for anything other than informational purposes. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Off-list discussions, was Re: imcc hack for perl6 regexes
On Wed, Aug 21, 2002 at 10:05:57AM -0400, Melvin Smith wrote: > > Sean, I'm replying publicly because I'd like to hear other opinions than > mine, yours, Angel's and Leopold's. Can I respectfully request that you guys make a lot more of your discussions public? languages/imcc and languages/perl6 are very major components, and they have been very little discussed on-list. imcc didn't bother me that much because I thought mainly just Melvin was working on it (I spend enough time listening to the voices in my head that I don't really need to hear the voices in everyone else's). But perl6 seems like something the wider community just might be interested in hearing about... ;-)
Re: Off-list discussions, was Re: imcc hack for perl6 regexes
>Can I respectfully request that you guys make a lot more of your >discussions public? languages/imcc and languages/perl6 are very major >components, and they have been very little discussed on-list. imcc Sure, I have no problem with it. At one time someone suggested making a separate list for Parrot compilers, so I took it as a hint that maybe we were spamming. >didn't bother me that much because I thought mainly just Melvin was >working on it (I spend enough time listening to the voices in my head To be fair, Angel has been doing most of the work lately. Work has had me pinned. I'm hoping with Sean's first cut at Perl6, we can identify weakness and requirements concerning an intermediate language, and re-architect when we are done with the "use cases." >perl6 seems like something the wider community just might be >interested in hearing about... ;-) You _would_ think so, wouldn't you? :) Personally I've been a little disappointed in the involvement(interest) of late. -Melvin
Re: Off-list discussions, was Re: imcc hack for perl6 regexes
> > Sure, I have no problem with it. At one > time someone suggested making a separate > list for Parrot compilers, so I took it as > a hint that maybe we were spamming. > I am all for the creation of a new list for stuff such as imcc, and perl6 compilers. ([EMAIL PROTECTED]?) So people interested in parrot internals (the hard stuff: GC, JIT,..) don't need to listen our discussions about bugs on imcc, feature requests, etc.. On the other hand people like me that cannot keep track of all that happens on perl6-internals, would have an easier way of focusing on areas were we can actually contribute something. -angel
Re: Off-list discussions, was Re: imcc hack for perl6 regexes
At 8:05 PM +0200 8/21/02, Angel Faus wrote: > > >> Sure, I have no problem with it. At one >> time someone suggested making a separate >> list for Parrot compilers, so I took it as >> a hint that maybe we were spamming. >> > >I am all for the creation of a new list for stuff such as imcc, and perl6 >compilers. ([EMAIL PROTECTED]?) > >So people interested in parrot internals (the hard stuff: GC, JIT,..) don't >need to listen our discussions about bugs on imcc, feature requests, etc.. > >On the other hand people like me that cannot keep track of all that happens on >perl6-internals, would have an easier way of focusing on areas were we can >actually contribute something. If there's no objection, I'll ask Ask or Robert to set this up. Everyone's got until, say, Friday noon my time (GMT-500) to object. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Off-list discussions, was Re: imcc hack for perl6 regexes
Angel Faus wrote: > I am all for the creation of a new list for stuff such as imcc, and perl6 > compilers. ([EMAIL PROTECTED]?) I wonder if maybe perl6-internals should have been named parrot, anyway. By being less overtly perl-centric, and thus more HLL-neutral, we could have gotten more direct involvement from other language camps. There's a lot of expertise out there, we should be leveraging. -- John Douglas Porter
Re: Off-list discussions, was Re: imcc hack for perl6 regexes
> You _would_ think so, wouldn't you? :) > Personally I've been a little disappointed > in the involvement(interest) of late. > > -Melvin I wonder how many interested observers of this list there are like myself. I only wish I had the time & experience/skill/knowledge to contribute. Keep up the good work. - XImon
Re: Off-list discussions, was Re: imcc hack for perl6 regexes
>> You _would_ think so, wouldn't you? :) >> Personally I've been a little disappointed >> in the involvement(interest) of late. >> >> -Melvin > > I wonder how many interested observers of this list there are like > myself. I only wish I had the time & experience/skill/knowledge to > contribute. > > Keep up the good work. > > - XImon me 3 -- Mark Koopman WebSideStory San Diego CA 92121 .. perl -e 'print chr hex(/8/?"0A":/[afebc]/?"4$_":/[D4-7A]/?ord $_:"".41+$_)for q,a756-210ef6DA4-219A4c-21D02bA48,=~/-..|./g'
Possible bug in new string COW code
Reading through the latest version of string.c, pondering the best way to integrate the grey and (what colour is cvs parrot?) versions, I came across the following line in unmake_COW: s->buflen = s->strlen; which got be a little confused - I seem to recall buflen as being in bytes, and strlen as being in encoding-defined characters. Did something change when I wasn't looking, or is this a bug just waiting for somebody to actually implement Unicode? -- Peter Gibbs EmKel Systems
DOD etc
In this Brave New World of DOD and GCC, what guarantees (if any)
will we be making at the Perl 6 language level for the timely calling of
object destructors at scope exit?
ie the classic
{ my $fh = IO::File->new(...); }
I know there's been lots of discussion on this over the months,
but I'm slighly confused as to what the outcome was.
--
"You're so sadly neglected, and often ignored.
A poor second to Belgium, When going abroad."
Monty Python - "Finland"
Re: Off-list discussions, was Re: imcc hack for perl6 regexes
At 2:35 PM -0400 8/21/02, John Porter wrote: >Angel Faus wrote: >> I am all for the creation of a new list for stuff such as imcc, and perl6 >> compilers. ([EMAIL PROTECTED]?) > >I wonder if maybe perl6-internals should have been named parrot, anyway. That would've required a bit of time-travel, as the list was set up and running before Parrot was named. :) Still, it would be nice. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: DOD etc
On Wed, Aug 21, 2002 at 08:25:10PM +0100, I wrote: > In this Brave New World of DOD and GCC, what guarantees (if any) s/GCC/GC/ What with PMC, PDD, COW etc, I have TLA on the brain. :-) -- Nothing ventured, nothing lost.
Re: imcc hack for perl6 regexes
> c) imcc becomes a "middle" level language.
> I never meant it to be an assembler. In practice
> intermediate languages provide other constructs
> such as aggregate type definition that are not
> available in the assembler.
>
> type i : packed int[32]
> type r : record { foo : int, bar : string }
>
> This is not assembler. This is medium level
> computer language in my book. You could even
> see things like
>
> ..pragma classes_are_hashes
>
> or something that would tell the compiler that
> aggregates should be implemented as standard
> "Perl" hashes in this piece of code, whereas
> others might want "packed" aggregates with
> no runtime introspection capability.
>
Now, this is interesting. I confess I was only thinking on dynamic perl-like
languages, but I think you have some secret plans..
But, this features don't change the point about the fact that infix notation
doesn't make the job of the language compiler easier (neither it makes it
harder) and is a duplicate feature once we have direct access to parrot ops.
>
> But I'm willing to invent and develop another language. And it should be a
> lot richer than
> just an assembler with a register allocator
> and spiller. :)
>
Don't forget optimitzations. That's where the real fun is.. :)
-angel
Re: imcc hack for perl6 regexes
Melvin Smith wrote: > Sean, I'm replying publicly because I'd like to hear other opinions than > mine, yours, Angel's and Leopold's. I'll answer here to Melvin's mail, but I'll try to make a summary of all point's taken in this thread + some more. > I still prefer infix notation to prefix notation for an intermediate > language. The current infix notation is fine. It makes intermediate code, and perl6 IMCC code generation more readable. Sean (IMHO) is not trying to give it up. But: - infix notation (and imcc internals) are currently limited to 4 registers per instruction, so what about: $S0 = _AV_a1[$I0;$I1;$I2] (which - with the key patch - is now working in .pasm) - imcc.y implements currently a very small (but common) subset of .pasm instructions. Sean was working on rx-ops, so he needed a solution to get them through imcc, including register allocation, so his patch is a nice thing to have _arbitrary_ ops in imcc. - currently, imcc register allocation is br0ken[1]. I tried hard today to find _some_ of the bugs, but did not succeed finally - til now ;-) [1] some internals, as Steve mentioned, such discussions should be more public: o in cfg:spill() the branch flags in ->type are not copied ... emitb( mk_instruction(tmp->fmt, r0, r1, r2, r3, tmp->flags) ); + instructions[n_instructions - 1]->type = old_instructions[i]->type; so after spilling there was/is only one basic_block. o symregs->first and ->last are off by one compared to life_info's. o memory allocation/freeing is a mess: e.g. it seems that a symreg->fmt get's corrupted sprintf(buf, "%c%d", reglist[x]->set, reglist[x]->color); in cfg:try_allocate() helps. (reglist is from my tries = ..graph[x]) I did not succeed finally: PC=90; OP=108 (set_i_p_ki); ARGS=(I0=2, P0=0x8059068, [I1=0]) Subscript on something that's not an aggregate! So please, first, let's consider the status quo, not the future. Above error is from perl6's test 3_2.p6. Simplifying the test by one line (and thus using less registers, helps aka let it succeed). So the problem is definitely imcc's register allocation and spilling. Angel, Melvin, if there are any patches, check them in _early_^Wnow - please. > I don't understand why it is so hard to adopt. imcc is supposed to be > a step closer to higher level languages, which is why I went that way. No problem here, it is called _intermediate_ ..., which is a worthful step in code generation, but - as always - there is a but, it should supply the infrastructure to generate _all_ possible .pasm code. Concluding: _SV_s1 = clone $P1 $S3 = _SV_s1 $I4 = 0 goto L_startre4 L_advance5: rx_advance $S3, $I4, L_rx_fail6 contains imcc language elements (infix) + pure pasm ops, which get looked up via core.ops aka libparrot.so, but profit from register allocation. > What I have heard is, "Why make imcc use a different syntax, it requires > people to learn a Parrot assembler _and_ imcc." Melvin, Sean's patch is not agaist imcc's syntax, it _extends_ the syntax with badly needed pasm syntax. There a currently 261 basic ops variating to a total of 844 different ops, why should imcc all implement _all_ and still permanently changing ops mow. I personally like imcc's syntax, it's a lot more readable compared to pasm. > I'm still for what we talked about, where any imcc directive uses a > leading '.' > and the rest of the ops are passed through; with the primary exemption > being those ops like set, add, etc. that have more common infix version > like: > > a = 1 > b = a + 1 So, finally, we all concede :-) Let's keep the high level infix instructions for the most common ops and unknown ops should be looked up dynamically. Of course, register allocation is still done for these. > -Melvin Thanks for reading til here, leo
INP ("imcc's not parrot") (was: Re: imcc hack for perl6 regexes)
Leopold Toetsch wrote: > > I don't understand why it is so hard to adopt. imcc is supposed to be > > a step closer to higher level languages, which is why I went that way. > > No problem here, it is called _intermediate_ ..., which is a worthful > step in code generation, but - as always - there is a but, it should > supply the infrastructure to generate _all_ possible .pasm code. If the point is that every feature of parrot should be exposed in imcc's ui, then that sounds reasonable, since the converse would be that some features of parrot are hidden. But obversely, parrot does not exist to supply features to imcc alone, it is meant to be targeted by many languages/compilers. I.e. "imcc is not the only path to parrot", and part of the design is to allow specially designed ops to exist for the support of specific languages. Seems to me that to say that every feature of parrot must be exposed in imcc is to imply that all upper-level languages must go through imcc -- and that's something I don't think we should mandate. Certainly it was not the original intention. > Melvin, Sean's patch is not agaist imcc's syntax, it _extends_ the > syntax with badly needed pasm syntax. There a currently 261 basic ops > variating to a total of 844 different ops, why should imcc all implement > _all_ and still permanently changing ops mow. > > I personally like imcc's syntax, it's a lot more readable compared to pasm. The outstanding question is, "Is imcc a part of the parrot system?" When compiler writers target parrot, do we really want them to target imcc? I have a feeling some of you would answer "yes" to that question all too blithely. But I don't see imcc mentioned in the PDD's. Heck, pasm itself is little more than a "possible variation"; the PDD's strongly imply that the perl6 compiler will compile directly to parrot bytecode. -- John Douglas Porter
RE: INP ("imcc's not parrot") (was: Re: imcc hack for perl6 regexes)
John Porter:
# languages. Seems to me that to say that every feature of parrot
# must be exposed in imcc is to imply that all upper-level
# languages must go through imcc -- and that's something I
Let me see if I can follow your logic: IMCC gives access to all Parrot
features, therefore IMCC must be used.
Ahem.
I don't think a full-featured IMCC implies that it must be used to
generate Parrot code, any more than saying that language X is the only
way to program because it's the msot full featured. It may well be that
IMCC is the best way to generate Parrot bytecode, but nobody's saying
it's the *only* way.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"Java golf. That'd be a laugh. 'Look, I done it in 15!' 'Characters?'
'No, classes!'"
--Ferret, in the Monastery
Re: INP ("imcc's not parrot") (was: Re: imcc hack for perl6 regexes)
Brent Dax wrote: > John Porter: > # languages. Seems to me that to say that every feature of parrot > # must be exposed in imcc is to imply that all upper-level > # languages must go through imcc -- and that's something I > > Let me see if I can follow your logic: IMCC gives access to all Parrot > features, therefore IMCC must be used. > . . . > It may well be that IMCC is the best way to generate Parrot bytecode, > but nobody's saying it's the *only* way. No; but statements like "imcc MUST provide access to ALL of parrot's (still very dynamic) feature set" and discussions of imcc syntax naturally lead to questions of imcc's role in the parrot project. E.g. "will the perl6 compiler target imcc?" While imcc is cool and worthy, it probably oughtn't be discussed on this list untless/until it is a "blessed" member of the parrot suite. -- John Douglas Porter
Re: [perl #16269] [PATCH] COW...Again and Again
On Wed, Aug 21, 2002 at 04:17:30AM -0400, Mike Lambert wrote: > Just to complete this thread, I have committed the current version of my > COW code, as I promised earlier this week. Did you try running tests with GC_DEBUG on? I get numerous failures. Here's a patch with a couple of fixes (not all of them gc-related), though I should warn you that it is rather roughly carved out of my local copy, which has far too many modifications at the moment. With this patch, things work for me, but I punted in one place: if you look at unmake_COW() in string.c, I just disabled garbage collection around the reallocation. The problem seems to be that you change where s->bufstart points to, then call Parrot_reallocate_string() on s. But that can trigger a collection, and it gets confused by the inconsistent state. --- This patch also contains a debugging aid that I was speculating on earlier. Whenever a buffer is marked as being live, it checks to see if the buffer is on the free list. If so, it whines and complains. (This is for finding premature killing of newborn Buffers; they'll go through one sweep and get put on the free list, then get anchored to the root set somehow. The next sweep will find them.) This is not 100% accurate, because the stackwalk is conservative: it assumes that anything whose pointer is in the appropriate range and otherwise smells right must be a live PMC or Buffer. I thought that finding old Buffers on the stack would be rare, but I was wrong -- the problem is that if they were buried in some deeply nested call chain, then because stack frames are not zeroed out upon allocation (which would be horribly slow), a later call chain will dig them back up. And the stackwalking code itself is deep enough and has large enough stack frames to dig up quite a bit of junk. So for the debugging code, I set a global flag CONSERVATIVE_POINTER_CHASING when we're walking the stack, just so that finding the living dead isn't such a traumatic affair. The rest of the time, it will abort immediately. Note that this is a real bug; we really shouldn't be poking into dead Buffers. There's no telling what the current state of decomposition is. A seg fault might jump out and bite us, or worse, because that pointer may have been used by something else for its own twisted purposes. And that something else could get very upset when it returns to find that we've jammed flags into the corpse and used its liver for a link in the ->next_for_GC chain. It is unlikely to cause problems accidentally, I suppose -- pointers are checked to make sure they're within one of the pools, so the only way to run into problems is to have a pointer on the stack to somewhere within a Buffer's memory, kill off the Buffer by forgetting about it, then have DOD add the bogus Buffer back onto the free list. Or have the COW code chase down a bogus tail pointer. Or use a bogus PMC instead -- then you have ->vtable->mark() to worry about. Hm, maybe it is dangerous. Am I missing some reason why this is not a problem? It would slow allocation and stackwalking way down if we have to keep a hashtable of valid pointers on the side. Index: dod.c === RCS file: /cvs/public/parrot/dod.c,v retrieving revision 1.19 diff -p -u -r1.19 dod.c --- dod.c 21 Aug 2002 08:00:10 - 1.19 +++ dod.c 21 Aug 2002 23:27:49 - @@ -14,6 +14,11 @@ #include "parrot/parrot.h" +#if GC_DEBUG +/* Set when walking the system stack */ +int CONSERVATIVE_POINTER_CHASING = 0; +#endif + static size_t find_common_mask(size_t val1, size_t val2); PMC * @@ -64,7 +69,9 @@ trace_active_PMCs(struct Parrot_Interp * last = mark_used(current, last); /* Find important stuff on the system stack */ +CONSERVATIVE_POINTER_CHASING = 1; last = trace_system_stack(interpreter,last); +CONSERVATIVE_POINTER_CHASING = 0; /* Now, go run through the PMC registers and mark them as live */ /* First mark the current set. */ @@ -221,6 +228,12 @@ trace_active_buffers(struct Parrot_Inter buffer_lives((Buffer *)interpreter->ctx.string_reg.registers[i]); } } + +/* The interpreter has a few strings of its own */ +if (interpreter->current_file) +buffer_lives((Buffer*)interpreter->current_file); +if (interpreter->current_package) +buffer_lives((Buffer*)interpreter->current_package); /* Now walk the string stack. Make sure to walk from top down * since stack may have segments above top that we shouldn't walk. */ Index: headers.c === RCS file: /cvs/public/parrot/headers.c,v retrieving revision 1.8 diff -p -u -r1.8 headers.c --- headers.c 21 Aug 2002 08:00:10 - 1.8 +++ headers.c 21 Aug 2002 23:27:50 - @@ -101,7 +101,18 @@ get_free_buffer(struct Parrot_Interp *in /* Don't let it point to garbage memory */ buffer->bufstart = NULL;
Re: INP ("imcc's not parrot")
At 05:44 PM 8/21/2002 -0400, John Porter wrote: >The outstanding question is, "Is imcc a part of the parrot system?" >When compiler writers target parrot, do we really want them to target imcc? >I have a feeling some of you would answer "yes" to that question all too My answer is "yes", not because I dictate anything, but because I would direct people to the fastest path. People that want to duplicate effort are welcome here too. I can also foresee that people might not like the C implementation, so once they bootstrap a compiler, they may wish to write imcc out of the picture. I for one am not happy with the current speed of Perl for compiling or assembling, so I wish to stick with C. At some point, I hope to finish a C# like language for Parrot at which time I hope to write a LALR generator in that language and reimplement the compiler completely in pure Parrot, including imcc. >blithely. But I don't see imcc mentioned in the PDD's. >Heck, pasm itself is little more than a "possible variation"; >the PDD's strongly imply that the perl6 compiler will compile directly >to parrot bytecode. imcc is part of a toolkit, as I see it. It is there to make your life easier. Why not invest in it? -Melvin
Re: INP ("imcc's not parrot")
At 07:00 PM 8/21/2002 -0400, 'John Porter' wrote: >No; but statements like "imcc MUST provide access to ALL of parrot's >(still very dynamic) feature set" and discussions of imcc syntax >naturally lead to questions of imcc's role in the parrot project. >E.g. "will the perl6 compiler target imcc?" Good question. The problem is, there is no one but us to answer that question. Or who are we waiting for? >While imcc is cool and worthy, it probably oughtn't be discussed on >this list untless/until it is a "blessed" member of the parrot suite. It is currently part of the prototype perl6 compiler. We should discuss it here unless we are going to move _all_ compiler discussion to another list (which I am ok with if that is the consensus). For now, I'd hoped we could keep it all on one list, until it becomes a problem. -Melvin
Re: imcc hack for perl6 regexes
At 11:15 PM 8/21/2002 +0200, Leopold Toetsch wrote: >So please, first, let's consider the status quo, not the future. Agree. >_SV_s1 = clone $P1 I've considered changing '=' to mean clone, and add ':=' to imply set. What do you think? -Melvin
Re: imcc hack for perl6 regexes
On Wed, 21 Aug 2002, Melvin Smith wrote: > At 11:15 PM 8/21/2002 +0200, Leopold Toetsch wrote: > >_SV_s1 = clone $P1 > > I've considered changing '=' to mean clone, and add ':=' to imply set. > What do you think? Heh. What's the universal sign for "assign" (as opposed to "clone" or "set")? Since we're going to have all three at some point, we'll need to come up with something for that, too. /s
Re: INP ("imcc's not parrot")
On Wed, 21 Aug 2002, Melvin Smith wrote: > At 07:00 PM 8/21/2002 -0400, 'John Porter' wrote: > >No; but statements like "imcc MUST provide access to ALL of parrot's > >(still very dynamic) feature set" and discussions of imcc syntax > >naturally lead to questions of imcc's role in the parrot project. > >E.g. "will the perl6 compiler target imcc?" > > Good question. The problem is, there is no one but us to answer > that question. Or who are we waiting for? I can see a need for either an "IMCC quick mode" or a way for the compiler to bypass IMCC when handling things like evals and one-liners, where startup time dominates. However, if we already have a working register allocator and peephole optimizer, I see little reason to write another. > >While imcc is cool and worthy, it probably oughtn't be discussed on > >this list untless/until it is a "blessed" member of the parrot suite. As opposed to the blessed BASIC and Befunge? I personally don't see that there's enough traffic to justify a separate parrot-languages list. For the time being, p6i and p6l seem to divide things up enough (maybe too much, given how many things are cross-posted, and how many people are subscribed to both). /s
Re: imcc hack for perl6 regexes
On Wed, 21 Aug 2002, Leopold Toetsch wrote: > Melvin Smith wrote: > > I still prefer infix notation to prefix notation for an intermediate > > language. > > The current infix notation is fine. It makes intermediate code, and > perl6 IMCC code generation more readable. > > Sean (IMHO) is not trying to give it up. Well, Sean's not quite sure about that. I agree with Melvin that using PASM syntax for IMCC could make it harder to target other platforms. However, I'm leery of learning yet another syntax and maintaining yet another language. Also, Parrot's opcodes and basic types are different from those of most other machines out there, so targeting other platforms sounds difficult enough to be unlikely. Furthermore, we're going to have prefix/pasm syntax for some ops -- there are simply too many ops and not enough ASCII characters -- and mixed infix/prefix syntax is ugly. I don't have strong opinions about this so long as it's possible to get at all of Parrot through IMCC. With the current CVS code, this is not the case, and my opinions are a bit stronger ;). > - infix notation (and imcc internals) are currently limited to >4 registers per instruction, so what about: Agreed -- we need to change this to conform to parrot/opcode.h's PARROT_MAX_ARGS. /s
Re: Off-list discussions, was Re: imcc hack for perl6 regexes
On Wed, 21 Aug 2002 [EMAIL PROTECTED] wrote: > >Can I respectfully request that you guys make a lot more of your > >discussions public? I'd like to dispel rumors of a vast off-list conspiracy. I've been taking and discussing patches to languages/perl6 from a couple of people (hi, Leo) off-list, and there's been a bit of IMCC discussion. While more discussion certainly occurs off-list than on, it's not exactly a "vast user community". > You _would_ think so, wouldn't you? :) > Personally I've been a little disappointed > in the involvement(interest) of late. Likewise, though more by the relative quiet on IRC. List traffic certainly seems heavier than a month ago, if nothing like it appears to have been back in 2000. /s
Re: INP ("imcc's not parrot")
Sean O'Rourke wrote: > However, if we already have a working register > allocator and peephole optimizer, I see little reason to write another. Maybe you're taking a very perl6-centric view. (I don't know.) But as someone who's writing an Tcl-to-parrot compiler (for (hypothetical) example), I might very well want to implement a different allocator and optimizer. > > >While imcc is cool and worthy, it probably oughtn't be discussed on > > >this list untless/until it is a "blessed" member of the parrot suite. > > As opposed to the blessed BASIC and Befunge? No. Basic, befunge, et alia exist as "standard proofs of concept" for HLL compilers targeting parrot. If y'all want to consider imcc as just another member of that class, fine! But if we tell compiler writers "You should target imcc, not parrot directly", then imcc is clearly in a class by itself. And why did I not squawk about the befunge matter a few days ago? Because that wasn't about befunge syntax (AFAICT). And no one has suggested that HLL compiler writers shoudl emit befunge. Yet. :-) But OTOH, I don't really mind if the imcc stuff is discussed here; I'm more interested in a resolution to the question of how blessed a child we mean it to be. -- John Douglas Porter
Re: INP ("imcc's not parrot")
Melvin Smith wrote: > Good question. The problem is, there is no one but us to answer > that question. Or who are we waiting for? I'd like to think that Dan would just declare on the matter and put it to rest. But what I *really* think is that Larry, or at least Damian, might have something very pertinent to say about it. -- John Douglas Porter
Re: INP ("imcc's not parrot")
On Wed, 21 Aug 2002, 'John Porter' wrote: > Sean O'Rourke wrote: > > However, if we already have a working register > > allocator and peephole optimizer, I see little reason to write another. > > Maybe you're taking a very perl6-centric view. (I don't know.) I usually tend to do so, but I'm not sure that I did in this case. My impression was that IMCC would mostly do low-level things for which there's basically one right way. Hopefully most language-dependent things would happen at a higher level. Unless IMCC's quality/time tradeoff isn't right for your Tcl compiler (hypothetically speaking, of course...), I'd be surprised if it didn't suit. And if it doesn't maybe it should be changed so it does. Melvin? > > > >While imcc is cool and worthy, it probably oughtn't be discussed on > > > >this list untless/until it is a "blessed" member of the parrot suite. > > > > As opposed to the blessed BASIC and Befunge? > > No. Basic, befunge, et alia exist as "standard proofs of concept" Sorry if that came off a bit snippy. I just couldn't resist the alliteration. > for HLL compilers targeting parrot. If y'all want to consider imcc > as just another member of that class, fine! But if we tell compiler > writers "You should target imcc, not parrot directly", then imcc > is clearly in a class by itself. I'm not sure this is what we're trying to say. The message is basically "every compiler needs to do this, and we have it implemented here". If it's useful, IMCC will live and grow. If not, it will end up being assimilated by the projects taht use it. > And no one has suggested that HLL compiler writers shoudl emit > befunge. Yet. :-) Forth, maybe. /s
Re: INP ("imcc's not parrot")
At 10:59 PM 8/21/2002 -0400, 'John Porter' wrote: >Sean O'Rourke wrote: > > However, if we already have a working register > > allocator and peephole optimizer, I see little reason to write another. > >Maybe you're taking a very perl6-centric view. (I don't know.) >But as someone who's writing an Tcl-to-parrot compiler >(for (hypothetical) example), I might very well want to >implement a different allocator and optimizer. Thats true. Of course you'd get off the ground a lot faster if you start out targetting imcc. >for HLL compilers targeting parrot. If y'all want to consider imcc >as just another member of that class, fine! But if we tell compiler >writers "You should target imcc, not parrot directly", then imcc >is clearly in a class by itself. Lets let the market decide. :) If we write a good enough intermediate language and listen and assimilate what people need, I think we can end up better off for it, with a common back-end compiler, and people will want to use it anyway. -Melvin
Re: INP ("imcc's not parrot")
At 11:02 PM -0400 8/21/02, 'John Porter' wrote: >Melvin Smith wrote: >> Good question. The problem is, there is no one but us to answer >> that question. Or who are we waiting for? > >I'd like to think that Dan would just declare on the matter >and put it to rest. But what I *really* think is that Larry, >or at least Damian, might have something very pertinent to say >about it. Neither Larry nor Damian have much to say in this regards. My intention is to get IMCC rolled into the Parrot executable, as the point between the parser and the interpreter. The intent ultimately is that you hand an AST, and potentially some rules, to IMCC and it creates bytecode for you from it. Offline compilers are under no obligation to use it, but it'll be built into Parrot. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: INP ("imcc's not parrot")
On Thursday 22 August 2002 01:24, Melvin Smith wrote: > >for HLL compilers targeting parrot. If y'all want to consider imcc > >as just another member of that class, fine! But if we tell compiler > >writers "You should target imcc, not parrot directly", then imcc > >is clearly in a class by itself. > > Lets let the market decide. :) If we write a good enough > intermediate language and listen and assimilate what people > need, I think we can end up better off for it, with a common > back-end compiler, and people will want to use it anyway. I personally think IMCC is a great thing, that *should* be treated as something special. It happens to (or intends to) share a near 1:1 relationship with PASM, at least on the conceptual level, which is very special. I don't believe that it should be the target, but it's a wonderful intermediate language for the intermediate in development. Use of IMCC as a target means a third step in final (bytecode) compilation/assembly, (SourceLanguage->IMCC->PASM->PBC,) though I'm not sure if IMCC ever intends to generate PBCs itself. (Forgive me, but I haven't been around long.) I don't think this is really acceptable in a "final product" sort of way. At the same time, if IMCC does become a cross-assembler then perhaps the third step is warranted, or perhaps support for IMCC as an optional target is warranted, for portability (outside of parrot, that is.) Alternatively, could IMCC be used as a sort of library to support efforts to compile to PASM? Perhaps some of the time-saving aspects could be capitalized upon so that less tedious work and more conceptualization can be put into projects that intend to target PASM itself. That said, given a project that intends to target PASM, I'd first target IMCC until everything was ironed out, and then move on to targetting PASM directly. I'd certainly keep the IMCC target support kicking around. Disclaimer: Forgive me if I'm way off on any of this... especially if I've made any undue assumptions about anything. As I've mentioned before, I am relatively new to the list, but equally (or more so) interested in development of these tools, as well as perl6 (and it's internals) itself. - Steve
Re: DOD etc
> In this Brave New World of DOD and GCC, what guarantees (if any)
> will we be making at the Perl 6 language level for the timely calling of
> object destructors at scope exit?
>From the straight GC perspective, none. There might be workarounds at
higher-levels, however.
> ie the classic
>
> { my $fh = IO::File->new(...); }
>
> I know there's been lots of discussion on this over the months,
> but I'm slighly confused as to what the outcome was.
I'm not sure if there ever was a consensus. A few ideas that I recall
being brought up were:
a) allow the ability to force a DOD run at block exit. This would emulate
perl5 behavior, and would be necessary when porting perl5 code with
DESTROY methods. I can imagine having a "block-exit-var-in-scope" flag
somewhere, that's set when we create a magic filehandle var, and possibly
unset with each dod run if the variable goes out of scope. When this flag
is set, the interpreter can force a DOD on on some block_exit() opcode, or
whatever the interface.
b) We can make a special property for these variables:
my $fh is stack_freed = IO::File->new(...);
When this variable's stack frame goes out of scope, it automatically has
it's destructor called, regardless of other references, since it can't
detect them. It would leave the actual PMC header as "live" until the next
DOD pass, when it would be truly freed. If the next DOD pass finds it
alive, it could barf. This isn't entirely safe, but it does offer the best
performance, I think.
c) similar to b, but more programmer-directed. I believe .NET has two
concepts of destruction. IO filehandles can have an active destroy method
called directly on them with 'delete someobject', leaving the actual
memory hanging around until the next GC (dod) run, at which point it
really deletes the header.
..NET improves upon Java's inability to give timely constructors to
objects, by allowing the user to manually delete things when they know
there are no other references for things that need to free resources.
Other than the above, I'm not sure what other methods could be used to
force destruction. And I'm not sure if a decree has been made about what
Perl6 will do.
Mike Lambert
[COMMIT] Some of you may have noticed...
The mass of ICU code that's been added to Parrot. It's taking an amazingly long time to import, and I'm apologizing profusely in advance for this massive import. However, one of our goals -is- to do Unicode out of the gate, and the easiest way to do this is adapt the ICU library for our own nefarious purposes. I'm going to go through and clean out some of the code that we won't use, but it's not going to help download times very much. If nothing else, this will add an incentive to not delete your parrot/ directory... It's probably not going to go into the MANIFEST until we decide what pieces we actually need, but we at least need the Unicode tables and basic libraries to properly handle Unicode character sets. Parrot won't actually -use- any of this for at least one or two versions, so there isn't much need to panic just yet. I also don't expect that anyone is going to actually do anything with this aside from me, so I'm going to start locally working on interlocking Parrot with this, and not commit things until we have the build infrastructure and such in place. Contrary to rumor I didn't do this to push my 'bytes added' count past Simon or Dan :) Again, my most profuse apologies, but we have to get this thing into the Unicode era. If it has to be kicking and screaming, my apologies but so be it. -- Jeff <[EMAIL PROTECTED]>
Re: [COMMIT] Some of you may have noticed...
At 1:20 AM -0400 8/22/02, Jeff wrote: >Contrary to rumor I didn't do this to push my 'bytes added' count past >Simon or Dan :) One important safety tip for the bandwidth-impaired. Add the -z3 flag to your cvs updates, like so: cvs -z3 update That'll use gzip compression on the data stream, which'll make a *big* difference on your speeds if you're on a slowish stream. (If you have CPU to burn, you might try a higher number with z. It's the same switch as gzip takes, so you can go up to -z9) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Possible bug in new string COW code
> Reading through the latest version of string.c, pondering the > best way to integrate the grey and (what colour is cvs parrot?) > versions, I came across the following line in unmake_COW: > s->buflen = s->strlen; > which got be a little confused - I seem to recall buflen as being > in bytes, and strlen as being in encoding-defined characters. > Did something change when I wasn't looking, or is this a bug > just waiting for somebody to actually implement Unicode? Yep, you're right, that's definitely a bug waiting for unicode. My intention there was to only copy as much data as was needed when we uncowify a buffer. I believe changing strlen to bufused is the proper fix, and have committed said change. Thanks, Mike Lambert
Re: INP ("imcc's not parrot")
On Jeudi 22 Août 2002 04:59, 'John Porter' wrote : > And no one > has suggested that HLL compiler writers shoudl emit befunge. > Yet. :-) Since we're talking about this, I have a suggestion... :o) Jerome -- [EMAIL PROTECTED]
Re: [COMMIT] Some of you may have noticed...
Jeff wins the "Who took all the inodes?" prize for 2002. -Melvin
Re: [COMMIT] Some of you may have noticed...
At 1:55 AM -0400 8/22/02, Melvin Smith wrote: >Jeff wins the "Who took all the inodes?" prize for 2002. And he's not even committed the data yet... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #16269] [PATCH] COW...Again and Again
> Some final 5000 life results from my system, and a few improvements > I believe are still possible: > > Before COW: 172 seconds > After COW: 121 seconds > A 30% improvement in performance is not too bad, I suppose. > Well done Mike! Thanks! > CVS/COW with stack pointer alignment = four: 93 seconds > Above plus pre-mask for PMC/Buffer alignment = four: 90 seconds > > The first of these improvements is achieved by determining > the alignment with which pointers are actually placed on the > stack, versus PARROT_PTR_ALIGNMENT, which is the > minimum alignment permitted by the underlying system. > On an Intel x86 platform running linux, I have been unable to > persuade any pointer to live on the stack other than on a > four-byte alignment, except by placing it in a struct, and > telling the compiler to pack structs. A simple C program is > included below which illustrates this point. Jason Gloudon has also said that x86 has a four-byte pointer alignment. I seem to recall a pointer aligned to an odd value that I found in a stack walk once, but I'm unable to reproduce it in extensive fiddling with your test program. As such, it's probably worthwhile to implement such a change, although I'm not quite sure the best way to do it. Should this be a configure.pl-determined constant? Should we hardcode it to sizeof(void*)? Is this behavior guaranteed by the C spec? Can we assume it across all platforms even if it is not guaranteed? > > If you don't mind, please feel free to continue your work on parrot-grey. > The problem arises with trying to do new experimental development, > which still keeping sufficiently in sync with cvs parrot that I can do a > 'cvs update' from time to time without getting dozens of conflicts. > A case in point is the new 'strstart' field - grey doesn't need it, but to > leave it out would create a large number of differences between the > two versions, with code having to be changed every time somebody > writes a new reference to it - therefore if I do continue with grey, I will > just probably just leave strstart in, and ignore the memory overhead. > The next item on the list for grey was paged memory allocation - this > may be usable to some extent without the buffer linked lists; so I will > probably give that a spin anyway. I think a union in the string header might do quite nicely in your case. I had the chance to look into your next/prev buffer linking code the other night. Interesting approach, but I have a few questions. :) In your collection phase, you give up header pool cache-coherency in favor of the memory pool. Your headers are organized by bufstart, essentially. Likewise, your use of the circular linked list of headers to add stuff to the front and ends of the header list as necessary is also interesting, and thrw me for a loop for a little while. :) The current cvs approach has an approach which is mostly cache-coherent. It iterates over ALL (not just live ones, as you do) buffers in header pools. And since the last collection, we can assume that most of the data hasn't changed (a harder assumption if we have a generational collector), and so the pool locality should follow the header locality, due to the nature of the copying. I'm not trying to argue which one is better, but merely try and state the differences in implementations to see if I got it straight. Might I ask what your motivation was for the header linked list? I can see that it solves the problem of: set S0, some_large_data_file_contents substr S1, S0, 0, 1 #get first character as COW set S0, "" sweep collect In current CVS, the large data file is kept around, whereas in your implementation, it would only copy the single character. However, there is an easy way to achieve nearly the same behavior as above in the current CVS. When we copy a COW string, it's initially marked as non-COW. In the subsequent collection, we have a really large buffer with a strstart and bufused that are quite small in total usage. If we only copy necessary data for non-COW strings, then the second sweep performed would eliminate the wasted memory copy. Not quite as fast in eliminating the memory usage as the above solution, but since we are guaranteed of collections happening throughout the lifetime of any program that does something with strings, I think it's an okay tradeoff. Were there any other reasons for implementing the above linked list technique that I missed? Thanks, Mike Lambert
Re: [COMMIT] Basic BNF and Parse::RecDescent grammar for Perl6 rx// operator
[EMAIL PROTECTED] (Jeff) writes:
> The subject pretty much says it all. The format pretty much corresponds
> to the upcoming Exegesis. Major changes were to the modifiers, and a few
> syntax changes in the depths.
I've started rewriting my Shishi P6 RE module since it was becoming
way too cluttered.
Here's the P::RD it uses, in case anyone is interested. It covers
rather more of A4 than Jeff's version, and is a bit easier to turn
into real Shishi nodes.
package Shishi::Perl6RE;
use Parse::RecDescent;
use Data::Dumper;
undef $/;
my $g = ;
my $re = new Parse::RecDescent($g);
print Dumper($re->expr(shift));
__DATA__
expr: term altlist(?)
{ $return = bless {
mainline => $item[1],
@{$item[2]} ? (
alternation => [@{$item[2][0]}]
) : ()
}, "P6RE::Expression"
}
altlist : '|' term altlist
{ $return = [ $item[2], @{$item[3]} ] }
| '|' term
{ $return = [ $item[3] ] }
term: factor factor(s?)
{ bless [ $item[1], $item[2] && @{$item[2]} ],
"P6RE::Term"
}
factor : bit repspec
{ $return = {
type => "repeat",
repspec => $item[2],
stuff=> $item[1]
}
}
| bit
| terminal_dollar
bit : brackets
| colons
| hypo
| interp_scalar
| "\\" backwhack
| '.' { $return = { type => "any" } }
| ordinary_string
hypo: /[\$\@\%]\w+/ ':=' term # Very ugly.
{ $return = { type => "hypo",
target => $item[1],
expr => $item[3] }
}
interp_scalar: '$' /\w+/
{ $return = {
type => "text",
target => "\$$item[2]",
interp => 1
}
}
brackets: '<' anglestuff '>'
{ $return = $item[2] }
| '(' expr ')'
{ $return = [
{ type => "start" },
$item[3],
{ type => "stop" }
]
}
| '[' expr ']'
{ $return = $item[3] } # Brackets are merely syntactic
| {
if ($return = extract_codeblock($text, '{')) {
$return = { type => "code", code => $return }
}
}
repspec : /[+?*]\??/
| /\??/
| / "backtrack", severity => length $item[0] }
}
anglestuff : /!?(\d*,\d*|\$\w+,\$\w+)>\??/
# I'm actually a repetition specifier, not a directive
| # <'foo'>
{
if ($return = extract_delimited($text, "'")) {
$return =~ s/^.//; chop $return;
$return = { type => "text", target => $return }
}
}
| 'commit'
{ $return = { type => "backtrack", severity => 4 } }
| 'sp'
{ $return = { type => "char", target => " " }
# XXX Not Unicode aware
}
| /!?\s*(before|after) expr/
{ die "Unsure how to implement this" }
| /[\&\$\@\%]\w+/
{ $return = { type => "delayed", target => $item[1], interp=>1 } }
| charclass
{ $return = { type => "class", target => $item[1] } }
| '-' '<' charclass '>'
{ $return = { type => "negclass", target => $item[3] } }
| /\w+/
{ $return = { type => "subrule", target => $item[1] } }
| { if ($return = extract_bracketed($text, '()')) {
$return = { type => "code", code => $return, assertion => 1 }
}
}
| { if ($return = extract_codeblock($text, '{}')) {
$return = { type => "delayed", code => $return, interp => 1 }
}
}
| { if ($return = extract_bracketed($text, '[]')) {
chop $return; $return =~ s/.//;
$return = { type => "anyof", target => $return }
}
}
| '-' { if ($return = extract_bracketed($text, '[]')) {
chop $return; $return =~ s/.//;
$return = { type => "neganyof", target => $return }
}
}
| '.' { $return = { type=>"anyuni" } }
charclass : 'alpha' | 'ws' # add more here
backwhack : /[dswDSW]/
{ $return = { type => "class", target => $item[1] } }
| /htvrfn/
{ $return = { type => "metachar", target => $item[1] } }
| /HTVRFN/
{ $return = { ty
