Re: [perl #32280] [PATCH] Detects presence of perldoc at configuration time
James deBoer [EMAIL PROTECTED] wrote: [ to OP ] This patch will test to see if perldoc actually works, aborting the configuration if it does not. Can you convert that test to produce a fat warning and skip targets relying on perldoc? Thanks, leo
Re: Strings, charsets, and encodings, oh my!
Thursday, November 11, 2004, 5:42:29 PM, Dan Sugalski wrote: Or something like that. [snip] FWIW, I really like the idea. Will there be a data type for characters, or are those just strings with a single grapheme? As a side note, the Java people decided for UTF-16 Unicode chars, and some good time getting Supplementary Characters ( U+) to work. http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ Ron
Re: Continuations, basic blocks, loops and register allocation
Matt Fowles [EMAIL PROTECTED] wrote: Jeff~ Yes, but in the case of the continuation resuming after foo, the continuation should restore the frame to the point where it was taken. Thus all of the registers will be exactly as they were when the continuation was taken (i.e. in the correct place). Yes, but Jeff's example wasn't really reflecting the problem. The case I've shown looks like: .local pmc arr1, arr2 arr1=[1,3,5] arr2=[1,5,9] x = choose(arr1) y = choose(arr2) # arr2 never used beyond $P0 = ... At the last line the register allocator happily reuses the register that arr2 had for $P0. That's totally legal in the absence of continuations. So it doesn't suffice that the register frame is restored and that variables are in the same place. The effect of the continuation is the creation of a loop in the CFG. Life time of variables and thus register allocation is different within loops. Exceptions handlers, on the other hand, are a different story, because anything that is used in the catch block must be kept in the correct place through out the entire try block. No they aren't really different. The presence of an exception handler (and the code for installing such a handler) is more visible in PIR. That's the only difference. But again up to the above continuation example. The scheme source of the relevant parts is this: (define (choose . all-choices) (let ((old-fail fail)) (call-with-current-continuation (lambda (continuation) ... (let ((x (choose 1 3 5)) (y (choose 1 5 9))) In that source it's obvious that the continuations of choose are captured in the local closures created by the lambda. So it's probably just a lack of the compiler (and a lack of PIR syntax) to express the relevant information that the call to choose has the possible side-effect of being resumed just after the created invokecc opcode. So from a HLL point of view that's all visible and clear. cite author=PiersAnd, damnit, making a full continuation isn't something a programmer should do lightly. /cite And of course an HLL compiler can't and doesn't emit some code that captures a continuation silently and w/o any reason. So what to do: 1) Extending register frame size ad infinitum and never reuse a Parrot register will definitely blow caches. 2) Generating an edge for every call to every previous calls will blow the CFG and cause huge pressure on the register allocator. A lot of spilling will be the result. 3) Using lexicals all over is slower (but HLL compilers will very likely emit code that does exactly that anyway). So the problem may not be a real problem anyway. We just know that an optimizer can't remove the refetch of lexicals in most of the subroutines. 4) Having an explicit syntax construct (call-with-current-continuation that expresses verbatim, what's going on, like e.g. with a reserved word placed as a label: RESUMEABLE: x = choose(arr1) leo
[PATCH] A little more Configure info
This adds information about the result of a test if the information is
terse enough. i.e. changes:
Determining whether your cc is actually gcc...done.
Into:
Determining whether your cc is actually gccyes.
Enjoy,
Luke
Index: config/auto/aio.pl
===
RCS file: /cvs/public/parrot/config/auto/aio.pl,v
retrieving revision 1.1
diff -u -u -r1.1 aio.pl
--- config/auto/aio.pl 31 May 2004 11:54:46 - 1.1
+++ config/auto/aio.pl 14 Nov 2004 11:47:12 -
@@ -37,6 +37,7 @@
INFO=42\n
ok/x) {
print (yes) if $verbose;
+$Configure::Step::result = 'yes';
Configure::Data-set(
aio = 'define',
@@ -50,5 +51,6 @@
else {
Configure::Data-set('libs', $libs);
print (no) if $verbose;
+$Configure::Step::result = 'no';
}
}
Index: config/auto/byteorder.pl
===
RCS file: /cvs/public/parrot/config/auto/byteorder.pl,v
retrieving revision 1.2
diff -u -u -r1.2 byteorder.pl
--- config/auto/byteorder.pl26 Feb 2004 00:43:02 - 1.2
+++ config/auto/byteorder.pl14 Nov 2004 11:47:12 -
@@ -34,16 +34,18 @@
byteorder = $byteorder,
bigendian = 0
);
+$Configure::Step::result = 'little-endian';
}
elsif($byteorder =~ /^(8765|4321)/) {
Configure::Data-set(
byteorder = $byteorder,
bigendian = 1
);
+$Configure::Step::result = 'big-endian';
}
else {
die Unsupported byte-order [$byteorder]!;
}
}
-1;
\ No newline at end of file
+1;
Index: config/auto/cgoto.pl
===
RCS file: /cvs/public/parrot/config/auto/cgoto.pl,v
retrieving revision 1.17
diff -u -u -r1.17 cgoto.pl
--- config/auto/cgoto.pl25 Mar 2004 16:52:53 - 1.17
+++ config/auto/cgoto.pl14 Nov 2004 11:47:12 -
@@ -56,9 +56,11 @@
cg_flag = '-DHAVE_COMPUTED_GOTO'
);
print (yes) if $verbose;
+$Configure::Step::result = 'yes';
}
else {
print (no) if $verbose;
+$Configure::Step::result = 'no';
Configure::Data-set(
TEMP_cg_h= '',
TEMP_cg_c= '',
Index: config/auto/env.pl
===
RCS file: /cvs/public/parrot/config/auto/env.pl,v
retrieving revision 1.4
diff -u -u -r1.4 env.pl
--- config/auto/env.pl 6 Mar 2004 22:24:30 - 1.4
+++ config/auto/env.pl 14 Nov 2004 11:47:13 -
@@ -50,15 +50,19 @@
if ($setenv $unsetenv) {
print (both) if $_[0];
+$Configure::Step::result = 'both';
}
elsif ($setenv) {
print (setenv) if $_[0];
+$Configure::Step::result = 'setenv';
}
elsif ($unsetenv) {
print (unsetenv) if $_[0];
+$Configure::Step::result = 'unsetenv';
}
else {
print (no) if $_[0];
+$Configure::Step::result = 'no';
}
}
Index: config/auto/funcptr.pl
===
RCS file: /cvs/public/parrot/config/auto/funcptr.pl,v
retrieving revision 1.4
diff -u -u -r1.4 funcptr.pl
--- config/auto/funcptr.pl 6 Mar 2004 22:24:30 - 1.4
+++ config/auto/funcptr.pl 14 Nov 2004 11:47:13 -
@@ -46,6 +46,7 @@
}
cc_clean();
print (yes) if $_[0];
+$Configure::Step::result = 'yes';
}
}
Index: config/auto/gcc.pl
===
RCS file: /cvs/public/parrot/config/auto/gcc.pl,v
retrieving revision 1.20
diff -u -u -r1.20 gcc.pl
--- config/auto/gcc.pl 10 Nov 2004 00:29:26 - 1.20
+++ config/auto/gcc.pl 14 Nov 2004 11:47:13 -
@@ -42,6 +42,7 @@
my $minor = $gnuc{__GNUC_MINOR__};
unless (defined $major) {
print (no) if $_[1];
+$Configure::Step::result = 'no';
return;
}
if ($major =~ tr/0-9//c) {
@@ -55,6 +56,7 @@
$gccversion .= .$minor if defined $minor;
}
print (yep: $gccversion ) if $_[1];
+ $Configure::Step::result = 'yes';
if ($gccversion) {
# If using gcc, crank up its warnings as much as possible and make it
Index: config/auto/gmp.pl
===
RCS file: /cvs/public/parrot/config/auto/gmp.pl,v
retrieving revision 1.3
diff -u -u -r1.3 gmp.pl
--- config/auto/gmp.pl 12 Oct 2004 09:00:15 - 1.3
+++ config/auto/gmp.pl 14 Nov 2004 11:47:13 -
@@ -52,6 +52,7 @@
$test = cc_run();
if ($test eq 4950\n) {
print (yes) if $verbose;
+$Configure::Step::result = 'yes';
Configure::Data-set(
gmp = 'define',
@@ -65,6 +66,7 @@
Configure::Data-set('ccflags', $ccflags);
Configure::Data-set('linkflags', $linkflags);
print (no) if $verbose;
+
[perl #32434] [PATCH] Data/Dumper tidbits
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #32434] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32434 Hi, this patch adds support for the String PMC to Data/Dumper/Default.imc. It is treated just like the PerlString PMC. The new .return () syntax is now used in Data/Dumper.imc, Data/Dumper/Base.imc and Data/Dumper/Default.imc. It looks like the DESCRIPTION section was mixed up in the POD of Base.imc and Default.imc. CU, Bernhard -- /* [EMAIL PROTECTED] */ NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl GMX DSL-Netzanschluss + Tarif zum supergnstigen Komplett-Preis! data_dumper_20041114.patch Description: Binary data
Another issue with pdd03
As outlined in the analysis of dumper.t failures with the new register allocator, we have another problem with current calling or better return conventions. Given this simple program: $ cat ret.imc .sub main @MAIN P5 = new PerlString P5 = ok\n foo() print P5 .end .sub foo .local pmc ok ok = new PerlString ok = bug\n .return(ok) .end $ parrot ret.imc bug The usage of the register P5 in main isn't invalid: the register allocator might have (in a more complex program) just not found any other free register. And as the main program just calls a function in void context the register P5 could have been used. Defining now that P5 has to be preserved in main, because it's a possible return result of foo() and therefore may be clobbered by foo() is meaning, that we have effectively just 16 registers per kind available for allocation around a function call. If the latter is true according to current pdd03 then we are wasting half of our registers for a very doubtful advantage: being able to pass return values in R5..R15. leo
Re: [PATCH] A little more Configure info
Luke Palmer [EMAIL PROTECTED] wrote: This adds information about the result of a test if the information is terse enough. i.e. changes: Determining whether your cc is actually gcc...done. Into: Determining whether your cc is actually gccyes. Thanks, applied. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker There is no cabal.
Re: Strings, charsets, and encodings, oh my!
At 1:04 PM +0100 11/14/04, Ron Blaschke wrote: Thursday, November 11, 2004, 5:42:29 PM, Dan Sugalski wrote: Or something like that. [snip] FWIW, I really like the idea. Will there be a data type for characters, or are those just strings with a single grapheme? Strings with a single grapheme. Characters can be multiple code points, so it's the only way to do it properly. There is direct code point access, and those are 32-bit unsigned ints. We're going to frown on most uses of those, since it's a good way to find yourself behaving really badly in a number of cases. Luckily Leo's last name'll make sure that we at least manage it properly in parrot. :) As a side note, the Java people decided for UTF-16 Unicode chars, and some good time getting Supplementary Characters ( U+) to work. http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ Yeah, that was something I didn't want to deal with. Unicode's got the largest range of code points, and it says 32 bits are enough. If it goes 64-bit at some point, well... Hopefully I'll be long-retired and not caring any more. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continuations, basic blocks, loops and register allocation
At 11:01 PM +0100 11/13/04, Leopold Toetsch wrote: Matt Fowles [EMAIL PROTECTED] wrote: I get the feeling that this is equivalent to requiring exception handlers to be a locally defined closure, which is another way we could go about this. Yes. That solves it. OTOH going all along with lexicals could be pretty inefficient. We're dealing with languages that pretty much mandate inefficiency in many ways. Since, for example, it's completely reasonable (well, likely at least) for a called sub to rebind lexicals in its parent, refetching's pretty much required. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continuations, basic blocks, loops and register allocation
At 5:53 PM +0100 11/13/04, Leopold Toetsch wrote: As the analysis of test errors of the new reigster allocator has shown, we have a problem WRT register allocation. This problem isn't new, but as the allocator is more efficiently reusing registers (or reusing them in a different way) it's exposed again. We don't really have that much of a problem. What we have is just something more simple -- the target of a continuation marks the start of a basic block. That means that we have to assume everything we don't get handed back from the function's dirty and should be refetched. Or, alternately, if we declare that the top half of the register set is preserved on function call and return we can assume that the PMCs and values in there are acceptable for use, though any that map to lexicals or globals ought to be refetched, since we have the possibility that the names have been rebound. I'm perfectly fine in declaring that this is *only* legitimate in mainline code, and that code generators don't have to deal with the possibility that vtable or MMD function code has rebound names. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] allow find-method to be inherited
Sam Ruby wrote: A patch is attached, but it bears a little discussion. Well, that didn't exactly work. I've since commmitted these patches, and more. A the moment, all the python and pirate unit tests pass. (Woot!) In the absense of other direction, I plan to write more tests and use them to drive the evolution of object.c and related sources. A description of my current thinking can be found at[1], but I am open to any implementation which continues to pass the tests that I define. In fact, the unit tests can change, as long as alternatives are provided that I can build upon to get the desired functionallity as defined by the pirate tests. Now that dynclasses build as a part of the 'all' target, I'm planning on adding the dynclass tests to the 'test' target. I've noticed that the test target is not successful unless the all target had been built previously, so this should not be a problem. If anybody has an issue with this then perhaps a 'testall' target can be defined. - Sam Ruby [1] http://www.intertwingly.net/blog/2004/11/14/Parrot-classes
Re: Continuations, basic blocks, loops and register allocation
On Nov 14, 2004, at 1:53 PM, Dan Sugalski wrote: Since, for example, it's completely reasonable (well, likely at least) for a called sub to rebind lexicals in its parent What does that mean, exactly? It seems like that directly contradicts the meaning of lexical. For instance, see Larry's comments from Re: Why lexical pads at September 25, 2004 10:01:42 PM PDT (the first of the 3 messages from him on that day). JEff
Re: Another issue with pdd03
PDD03: Responsibility for environment preservation PDD03: PDD03: The caller is responsible for preserving any environment it is interested PDD03: in keeping. This includes any and all registers, lexical scoping and PDD03: scratchpads, opcode libraries, and so forth. PDD03: PDD03: Use of the savetop opcode is recommended if the caller wishes to save PDD03: everything, and the restoretop opcode to restore everything savetop saved. PDD03: This saves off the top 16 of each register type, leaving the bottom 16 PDD03: registers, which generally contain the return values, intact. The way I read it, paragraph one implies that when you print P5 after calling foo(), you are expecting to get the return value. You didn't save and restore register P5, so you wanted foo() to do something to it. The above docs may be slightly ambiguous. The first paragraph says that you have to save everything. The seconds says that savetop/restoretop commands are there to help the user, by allowing them to take care of registers 16-31, but what about 0-15? Is there an implication that you don't have to save those? Based on the way people are coding IMC, that seems to be the case. Both the old and new register allocator are kind of hands off the first 16 registers. Recall that I was asking about this some time ago, and found that if the allocator tries to use the bottom half first, chaos ensues. Our convention then ... our interpretation of the calling convention, is that we try to allocate only the top 16 registers. If more are needed, the new allocator starts from R15, and go on downward. The old one just went up from R0. Note that PDD03 is specifying a dynamic calling convention. Because of this, the register allocator cannot use the convention to find what should be saved, and what it can use. If this were indicated at compile time, the register allocator could keep hands off only the used registers. As it is, we may need to do as you suggest, and leave the bottom 16 registers for parameter passing, and the top 16 for local symbols and register allocation. If so, we will obviously need a better register allocator. One exception to this. If a sub calls no other subs, it can use all 32 registers. Also, P4, S1-S4, N0-N4 seem to be free. ~Bill On Sun, 14 Nov 2004 18:32:50 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: As outlined in the analysis of dumper.t failures with the new register allocator, we have another problem with current calling or better return conventions. Given this simple program: $ cat ret.imc .sub main @MAIN P5 = new PerlString P5 = ok\n foo() print P5 .end .sub foo .local pmc ok ok = new PerlString ok = bug\n .return(ok) .end $ parrot ret.imc bug The usage of the register P5 in main isn't invalid: the register allocator might have (in a more complex program) just not found any other free register. And as the main program just calls a function in void context the register P5 could have been used. Defining now that P5 has to be preserved in main, because it's a possible return result of foo() and therefore may be clobbered by foo() is meaning, that we have effectively just 16 registers per kind available for allocation around a function call. If the latter is true according to current pdd03 then we are wasting half of our registers for a very doubtful advantage: being able to pass return values in R5..R15. leo
Re: Continuations, basic blocks, loops and register allocation
On Sun, 14 Nov 2004 17:03:33 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: At 5:53 PM +0100 11/13/04, Leopold Toetsch wrote: As the analysis of test errors of the new reigster allocator has shown, we have a problem WRT register allocation. This problem isn't new, but as the allocator is more efficiently reusing registers (or reusing them in a different way) it's exposed again. We don't really have that much of a problem. What we have is just something more simple -- the target of a continuation marks the start of a basic block. That means that we have to assume everything we don't get handed back from the function's dirty and should be refetched. I tend to agree that this is not such a problem. Basically, Parrot has various control flow possibilities that were not previously considered. (1) An exception can happen in a try block, so CFG arcs need to be added from statements within the try block to the catch. (2) Continuations, which I don't pretend to understand, can also flow in previously unconsidered directions. Those arcs need to be added to the CFG. Alternately, for exceptions, it may be possible to circumvent that process, and just add symbolic interfenence to all vars in the try block with all vars in the catch block. For continuations, however, it seems like those really are control flow arcs that need to be added. If analysis can trim a few of them, then that would be great, but if people are using continuations, maybe they shouldn't expect high performance, and extra register spilling may be another side effect. ~Bill
