Re: Parrot bc?
Ron Blaschke schrieb: I'm feeling rather dumb asking this, but F says: Currently GNU bc is only used for doublechecking Parrot bc. Now, my question is: Where is "Parrot bc?" "Parrot bc" is sitting on my local disk, being very disfunctional. I'll check it in, as soon as it does something useful. It will Python code generated by ANTLR, and the problem is that I know neither ANTLR nor Python. CU, Bernhard
[perl #36251] Parrot_call_method ... both name and sub should be optional
# New Ticket Created by Chip Salzenberg # Please include the string: [perl #36251] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36251 > There should be no need to pass name if sub is passed, and vice versa. Passing both should be legal; it should indicate that the given sub was found under the given name. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: PMCs and Objects question
Leopold Toetsch wrote: Klaas-Jan Stol wrote: hi, My question concerns functionality of PMCs and Objects. while reading the docs about the functionality of classes and objects, I read that the vtable entries of a class can be overridden to give the class special behaviour. I'd like to know if I'm correct (I just realized this), if I say that: you can give a variable the same behaviour by either write it as a pmc, or as class. When giving the functionality to a PMC, you write it in C, when doing it with a class, you write it in PIR. Am I correct? Yes, you can implement almost everything a class needs inside a PIR file. Have a look at languages/lisp for a PIR-ony implementation. If I understand correctly, the object system and the PMC types are very much related. I read that when creating a new class, then a new ParrotClass is created. (ParrotObject is the PMC that takes care of the implementation of a run-time object in Parrot, right?). But, a new class can inherit from a built-in PMC type, right? I try to understand the difference between PMCs and user-defined classes. If so, why then would one ever want to write a PMC (maybe for speed?) Yep Furthermore, if my assumption above is correct, then "morphing" and stuff works the same way? HLLs usually don't morph their objects. Instead new objects of the desired type are returned. It's probably just perl with it's references that needs morphing. Anyway messing with PMC internals isn't exposed, you'd need e.g. call a NCI function to accomplish this task. I meant (but I think I got your point of returning an object of the desired type), suppose the Perl datatypes were not implemented as PMCs but rather as user-defined classes (written in PIR). So: # Let's assume there are no PMC's at all, not even the built-in Integer and Float (and others), # otherwise we could just as well inherit the Integer PMC, if I'm correct (and then no attribute "value" were needed) # # define a new class class $P0, "PerlInt" addattribute $P0, "value" # define the methods for this class .namespace ["PerlInt"] .sub __set_integer_native method .param int i # set "value" attribute of this object to i's value .end This would work too, right? In fact, suppose all methods that are implemented for the PerlInt PMC were written as methods in the PerlInt class' namespace, like above, the system would behave exactly the same way, right? (except, of course, it's not as fast). In fact, suppose there were not built-in PMC's at all (of course, there has to be something implementing the object system, now done by ParrotClass if I understand correctly), but all these types were written in PIR (also the hash pmc's), then the system, again except for speed, would behave just the same, right? klaas-jan
Re: [perl #31178] [TODO] IO - off with its head! er, opcodes!
On Sun, Jun 12, 2005 at 01:44:43AM -, Will Coleda via RT wrote: > Any tickets which list "will-parrotodo ..." don't need to have replies OK. > And, "chip claimed a ticket???!?" > * gets the vapors. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Parrot bc?
Bernhard Schmalhofer wrote: > Ron Blaschke schrieb: >>Now, my question is: Where is "Parrot bc?" > "Parrot bc" is sitting on my local disk, being very disfunctional. > I'll check it in, as soon as it does something useful. I see. > It will Python code generated by ANTLR, and the problem is that I know > neither ANTLR nor Python. Oh, now I see why the ANTLR and Python tests are in. ;-) I've asked about this, because with r8305 "...the 'bc' config test hangs on Win32." Well, it seems to work fine on my Win32 box. I guess I shouldn't care about this, but I would like to provide a Win32 test box, with all possible optional things installed. Is this, well, out of focus? C:\>bc -v bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. Determining whether python is installed.yes, 2.4.1. Determining whether antlr is installedyes, with python. Determining whether GNU bc is installedyes. Ron
Unexpected behaviour calling method of attribute
Hi,
I have a class A, that has an object of class B as an attribute.
I've overriden the add() method of class A, and I want to let class B
handle the actual work.
The idea is to make this class B replacable by the user, so he can
override the behaviour of a certain object of A, without disturbing
other objects of A.
so, pseudocode may look like this:
class A
{
B b;
method init()
{
b = new B();
}
method __add(left, right)
{
b.__add(left, right); //***
}
}
class B
{
method __add(left, right)
{
// standard behaviour:
print("No __add() defined for objects of ");
}
method someCustomAddMethod(left, right)
{
print("Ok!");
}
}
function main()
{
A a1, a2, sum;
sum = a1 + a2;
}
It seems that at the line, marked with "//***", not the __add method of
b is called, but that A's __add method is called again.
However, when this call is replaced by a call to
b."someCustomAddMethod"(left, right), everything is working as expected.
I translate the above pseudo code to: (which runs ok, except for the
"//***"-marked line)
.sub main
# create the classes
newclass $P0, "A"
newclass $P1, "B"
addattribute $P0, "b"
# make sure there's an constructor for A creating its member variable b.
new $P10, .String
set $P10, "_new"
setprop $P0, "BUILD", $P10
# create instances of a, and add them
find_type $I0, "A"
new $P20, $I0
new $P21, $I0
new $P22, $I0
$P22 = $P20 + $P21
end
.end
.namespace ["A"]
# constructor for A
.sub _new method
find_type $I0, "B"
new $P0, $I0
setattribute self, "b", $P0
.end
.sub __add method
.param pmc self
.param pmc left
.param pmc right
# get fully qualified named attribute b
getattribute $P1, self, "A\0b"
# now, $P1 should hold the "b", right?
# checking by:
print $P1
# works, 'cause it calls the __get_string() method of B
#scenario 1: doesn't work
# call B's __add() method
#$P1."__add"(left, right) #//*** this does not work!
#scenario 2: works ok
$P1."someCustomAddMethod"(left, right)
.end
.namespace ["B"]
.sub __add method
printerr "No __add() defined for objects of "
.end
.sub someCustomAddMethod method
printerr "Adding with custom method"
# ...
.end
.sub __get_string method
print "this is B"
.end
The error I get is this:
[EMAIL PROTECTED]:~/parrot$ parrot cltest.pir
No such attribute 'A\0b'
current instr.: 'A :: __add' pc 64 (cltest.pir:36)
called from Sub 'A :: __add' pc 95 (cltest.pir:40)
called from Sub 'main' pc 31 (cltest.pir:15)
It looks as if the .invocant is not set properly, effectively calling
the __add() method on the wrong object (self, instead of b).
Now, the trouble is, it's not doing what I'd expected. It may of course
well be that I'm not thinking right, and I wrote buggy code. OTOH, it
may be it's a bug. Just checking here.
thanks,
klaas-jan
Re: None vs. Undef vs. Null, and opcode trimming
On Sun, Jun 12, 2005 at 12:52:03AM -0400, William Coleda wrote: > open currently returns an Undef PMC if it fails to open a file. Should it > instead return a None? Or, IMO, a Null? Undef PMC ... or more precisely, any old PMC value that is not defined() ... seems the most useful return value. I think it's a Good Thing that the return value of open() is always a valid PMC; it can then be stored without first having to be checked for isnull. BTW, for those of you who don't monitor RT (and why aren't you?), the IO opcodes will not be opcodes for much longer. They'll be library functions. We're hoping to bring the number of opcodes down for various reasons that should be obvious. But if you write PIR, you probably won't have to change much. And in any case the semantics of an error return are orthogonal. > FWIW, it also seems unfair (or at least, unobvious) that there is > are C and C opcodes, but no corresponding codes for > Undef or None. "Well, don't do that, then." You shouldn't have to check for the precise PMC type after open. Just check for definedness. Granted, that's two opcodes and an integer register: $P0 = open "/etc/motd", "<" $I0 = defined $P0 unless $I0, b0rken But, Shirley, that's not an excessive burden. -- Chip Salzenberg <[EMAIL PROTECTED]>
Parrot Goals and Priorities; "Help Save The World"
Greetings from the Toetch residence in lovely Herrnbaumgarten, Austria. The hackathon continues apace. This morning, we've dropped into communal typing with occasional conversation. I'm focussing on documentation and cherry picking recent p6i traffic. And speaking of documentation: At the Austrian Perl Workshop I spoke on the subject of the Parrot project and its priorities. Since most of the Perl/Parrot community wasn't there to hear it, I've put the slides up in both their original format and an autrijus-contributed PDF export: http://feather.perl6.nl/~chip/Chip_APW.sxi http://feather.perl6.nl/~chip/Chip_APW.pdf Share and/or enjoy! PS: Pugs has macros now. Those guys rock. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: PMCs and Objects question
On Sun, Jun 12, 2005 at 10:52:37AM +0200, Klaas-Jan Stol wrote: > I read that when creating a new class, then a new ParrotClass is > created. (ParrotObject is the PMC that takes care of the > implementation of a run-time object in Parrot, right?). But, a new > class can inherit from a built-in PMC type, right? Yes, there's a PMC inheritance mechanism that works for things that wouldn't be called "classes" in Perl 6. For example, PerlUndef is a PMC that's derived from PerlInt. (Someday, I hope to know why.) > suppose the Perl datatypes were not implemented as PMCs but rather > as user-defined classes (written in PIR). [...] This would work > too, right? I think so, though I imagine it would be a bit of work to make sure the ParrotObjects were actually complying 100% with the API provided by the current PMCs. I can imagine that for debugging purposes -- or maybe just for the sheer fun of it -- someone will eventually try it. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: PGE, namespace'd rules.
On Fri, Jun 10, 2005 at 05:18:19PM -0400, William Coleda wrote: > Looking through the PGE test examples, it *looks* like subrules are just > globals. I'm sure that's not how it'll behave when it's done, though I don't know PGE well enough yet to suggest how it will work exactly. In the meantime, I guess you'll need to use the standard mangling tricks (e.g. prepending "__pge_" to rule names). -- Chip Salzenberg <[EMAIL PROTECTED]>
Attack of the fifty foot register allocator vs. the undead continuation monster
On Wed, Jun 08, 2005 at 10:26:59PM +0100, The Perl 6 Summarizer wrote:
> Loop Improvements
> Oh no! It's the register allocator problems again. One of these days I
> swear I'm going to swot up on this stuff properly, work out whether it's
> really the case that full continuations break any conceivable register
> allocator and summarize all the issues for everyone in a nice white
> paper/summary.
"It's not really that complicated. It just takes a long time to explain."
-- Dr. Howland Owll, on SubGenius doctrine
Consider this code:
sub example1 {
my $a = foo();
print $a;
my $b = bar();
print $b;
}
It's obvious that $a and $b can be allocated the same register because
once $b has been set, $a is never used again.
(Please ignore that $a and $b are variables that can't be stored
purely in registers. The real world case that I'm illustrating deals
with temporaries and other values that lack user-visible names. But
the issue is best illustrated this way.)
Now consider this:
sub example2 {
my $a = foo();
do {
print $a;
$b = bar();
print $b;
} while ($b);
}
You can see that it's now *not* OK to allocate $a and $b to the same
register, because the flow of control can jump back to the print $a
even after $b is assigned.
Look at the first function again, and consider what happens if &foo
captures its return continuation _and_&bar_invokes_it_. It would
effectively amount to the same issue as example2:
sub foo {
$a = 1;
foo();
_implicit_label_for_return_continuation:
print $a;
$b = bar();
print $b;
}
bar() {
if rand() < 0.5 { goto _implicit_label_for_return_continuation }
return "lucky";
}
Therefore, register allocation must allow for implicit flow of control
from *every* function call to *every* function return ... or, more
precisely, to where *every* continuation is taken, including function
return continuations.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: Unexpected behaviour calling method of attribute
On Sun, Jun 12, 2005 at 12:43:17PM +0200, Klaas-Jan Stol wrote: > It seems that at the line, marked with "//***", not the __add method of > b is called, but that A's __add method is called again. Well, __add is a multimethod now, not a vtable function. I'm not surprised your code doesn't work as you expect, but I *am* surprised that Parrot let you execute: $P1."__add"(left, right) and didn't die or at least warn that "This does not mean what you think it means". Leo? -- Chip Salzenberg <[EMAIL PROTECTED]>
MMD; exceptions (was Summary)
On Wed, Jun 08, 2005 at 10:26:59PM +0100, The Perl 6 Summarizer wrote: > Missing MMD default functions > Dan was somewhat bemused to find that the MMD functions' defaults had > disappeared when he did a sync with subversion. He wondered whether this > was deliberate. Turns out that it was. I'm not sure whether Chip's ruled > that it was Right though. I'm leaning toward It's Right. Once MMD came onto the scene, the mere existence of vtable functions was no longer a strong determinant of correct actions, but rather the formal class and its inheritance. So right now, if you're writing a PMC that should participate in MMD like a Float, you're going to have to go to the extremely painful and time-consuming step of deriving from Float. And you can be sure that you won't be used as a Float if you don't derive. I have a hard time seeing a down side here. In fact, I'm really wondering whether, someday, in a distant galaxy's source code repository, vtables could be completely replaced with an MMD mechanism, presumably one optimized for single invocants. But that's hardly a topic for today. > A note WRT exception handlers > Leo posted a quick discussion of the correct use of exception handlers > in Parrot. Essentially, the rule is, your exception handler should jump > back to the point just after the exception handler block: > > push_eh except_N > # Code that might fail > clear_eh > resume_N: > ... > except_N: > ... > goto resume_N > > Easy eh? Yeah, but p6i archives are a poor substitute for documentation. Somebody want to find a good pod to document this, and do so? -- Chip Salzenberg <[EMAIL PROTECTED]>
[perl #36255] [TODO] Exceptional Documentation
# New Ticket Created by Will Coleda # Please include the string: [perl #36255] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36255 > Neither are p6i archives a good place to keep TODO items. =-) Chip said that Leo said: >> A note WRT exception handlers >> Leo posted a quick discussion of the correct use of exception handlers >> in Parrot. Essentially, the rule is, your exception handler should jump >> back to the point just after the exception handler block: >> >> push_eh except_N >> # Code that might fail >> clear_eh >> resume_N: >> ... >> except_N: >> ... >> goto resume_N >> >> Easy eh? > Yeah, but p6i archives are a poor substitute for documentation. > Somebody want to find a good pod to document this, and do so?
Re: Unexpected behaviour calling method of attribute
Klaas-Jan Stol wrote:
method __add(left, right)
{
b.__add(left, right); //***
}
.sub __add method
.param pmc self
.param pmc left
.param pmc right
The function signatures of your __add methods are bogus.
Pd = Pl + Pr
is the same as:
Pd = __add(Pl, Pr)
or
Pd = Pl.__add(Pr)
The difference between function and method call is just the lookup, if
there are multisubs defined. And both of these ought to return a new PMC
of the desired type:
.sub __add method
.param right
# add self to right giving d
.return (d)
.end
or as function
.sub __add
.param left
.param right
...
leo
Re: Unexpected behaviour calling method of attribute
On Sun, Jun 12, 2005 at 03:42:14PM +0200, Leopold Toetsch wrote: > Klaas-Jan Stol wrote: > >.sub __add method > > .param pmc self > > .param pmc left > > .param pmc right > > The function signatures of your __add methods are bogus. Since __add has defined semantics per Parrot, I think it's important for Parrot to generate errors (or at least warnings!) when somebody makes this kind of quite understandable mistake. -- Chip Salzenberg <[EMAIL PROTECTED]>
[perl #36256] [TODO] Parrot Release 0.2.2
# New Ticket Created by Will Coleda # Please include the string: [perl #36256] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36256 > This ticket is a placeholder for the 0.2.2 Release of Parrot. Please mark any RT issues that must be completed for this release as children of this ticket.
[perl #36257] [TODO] Parrot release 0.2.3
# New Ticket Created by Will Coleda # Please include the string: [perl #36257] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36257 > This ticket is a placeholder for the 0.2.3 Release of Parrot. Please mark any RT issues that must be completed for this release as children of this ticket.
RT, parrot releases
I've: - opened tickets for 0.2.2 and 0.2.3, - moved any child tickets that are children of the tickets for 0.1.3, 0.1.4, 0.2.0 tickets to the 0.2.2 release (nine altogether). - resolved the old release tickets. Chip - Check out https://rt.perl.org/rt3/Ticket/Display.html?id=36256 and obviously feel free to delete any child tickets that you don't think belong on the 0.2.2 release, or add any that you think are a priority. I'm not trying to set policy, just document it. Will "Recording Secretary" Coleda
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
Chip Salzenberg <[EMAIL PROTECTED]> writes:
> On Wed, Jun 08, 2005 at 10:26:59PM +0100, The Perl 6 Summarizer wrote:
>> Loop Improvements
>> Oh no! It's the register allocator problems again. One of these days I
>> swear I'm going to swot up on this stuff properly, work out whether it's
>> really the case that full continuations break any conceivable register
>> allocator and summarize all the issues for everyone in a nice white
>> paper/summary.
>
> "It's not really that complicated. It just takes a long time to explain."
>-- Dr. Howland Owll, on SubGenius doctrine
>
> Consider this code:
>
> sub example1 {
>my $a = foo();
>print $a;
>my $b = bar();
>print $b;
> }
>
> It's obvious that $a and $b can be allocated the same register because
> once $b has been set, $a is never used again.
>
> (Please ignore that $a and $b are variables that can't be stored
> purely in registers. The real world case that I'm illustrating deals
> with temporaries and other values that lack user-visible names. But
> the issue is best illustrated this way.)
>
> Now consider this:
>
> sub example2 {
>my $a = foo();
>do {
>print $a;
>$b = bar();
>print $b;
>} while ($b);
> }
>
> You can see that it's now *not* OK to allocate $a and $b to the same
> register, because the flow of control can jump back to the print $a
> even after $b is assigned.
>
> Look at the first function again, and consider what happens if &foo
> captures its return continuation _and_&bar_invokes_it_. It would
> effectively amount to the same issue as example2:
>
> sub foo {
>$a = 1;
>foo();
> _implicit_label_for_return_continuation:
>print $a;
>$b = bar();
>print $b;
> }
>
> bar() {
>if rand() < 0.5 { goto _implicit_label_for_return_continuation }
>return "lucky";
> }
>
> Therefore, register allocation must allow for implicit flow of control
> from *every* function call to *every* function return ... or, more
> precisely, to where *every* continuation is taken, including function
> return continuations.
Buf if you fallow the calling conventions that looks like:
sub foo {
$a = 1.
$c = 10;
print $c
save_dollar_a_and_only_dollar_a_because_im_going_to_use_it_after_this_function_call
foo()
_implicit_label_for_return_continuation:
restore_dollar_a
_ooh_i_dont_have_to_save_anything
$b = bar()
_nor_do_i_have_to_restore_anything
print $b
}
That's what caller saves means. You only have to save everything that you're
going to care about after the function returns. You don't have to save the
world, because if it was important it's already been saved further up the call
chain.
This means, of course, that the continuation needs to save the state of the
restore stack, but I thought we already knew that.
Of course, if you're going to actually use GOTO to get to some label that you
should only get to via a continuation (as you do in the code example) then you
deserve to get everything you've got coming to you. A continuation must contain
everything needed to restore the user registers to the correct state no matter
how many times they were taken.
I really don't see how this affects register allocation; the call to bar
doesn't need to save $a because it's not referred to (lexically) after the call
returns. So what if the call to bar might take a continuation. Taking that
continuation should be exactly equivalent to returning from the call to
foo. You really have to stop thinking of continuations as gotos.
[perl #36258] [RFE] parrotbug should include the SVN revision.
# New Ticket Created by Will Coleda # Please include the string: [perl #36258] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36258 > > BTW: a nice to have: include SVN revision of local copy in bug report. >leo
[perl #34912] Badly balanced at classes/pmc2c2.pl
Jens - is this still an issue? > [leo - Tue Apr 12 02:44:09 2005]: > > Jrieks @ Wmit00 . It . Math . Uni-Wuppertal . De [EMAIL PROTECTED]> wrote: > > > wmit01 ~ > perl -v > > > This is perl, v5.6.0 built for i586-linux > > As it seems to be a perl issue, please check the relevant part of the > PMC compiler. IIRC there was a patch regarding C not > too long ago. > > leo > > >
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
On Sun, Jun 12, 2005 at 03:15:22PM +0100, Piers Cawley wrote:
> But if you fallow the calling conventions that looks like:
>
>sub foo {
> $a = 1.
> $c = 10;
> print $c
>
> save_dollar_a_and_only_dollar_a_because_im_going_to_use_it_after_this_function_call
> foo()
> _implicit_label_for_return_continuation:
> restore_dollar_a
> _ooh_i_dont_have_to_save_anything
> $b = bar()
> _nor_do_i_have_to_restore_anything
> print $b
>}
You have greatly misunderstood. We're talking about how &foo manages
its callee-saves registers. The registers involved, the ones that I'm
calling $a and $b, are P16-P31.
> Of course, if you're going to actually use GOTO to get to some label
> that you should only get to via a continuation ...
For purposes of allocating the callee-saves registers, a continuation
may as well _be_ a goto.
Don't feel bad, though. I thought the same thing the first time *I*
heard about this problem.
--
Chip Salzenberg <[EMAIL PROTECTED]>
[perl #36259] [TODO] Ignore generated files in 'svn st'
# New Ticket Created by Will Coleda # Please include the string: [perl #36259] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36259 > The generated files/dirs: src/asmfun.s chartypes should be ignored by 'svn st'
m4 build failure on OS X.
With a fairly recent parrot (8308) oolong:~/research/parrot/languages/m4 coke$ make cc -g -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe -fno-common -Wno-long-double -I../../include -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization -falign-functions=16 -Wno-shadow -c src/eval.c c++ -dynamiclib -L/usr/local/lib -flat_namespace -o ../../runtime/parrot/dynext/m4_eval_compiler.dylib eval.o ld: Undefined symbols: _PackFile_Segment_new_seg _Parrot_compreg _Parrot_switch_to_cs _const_string _mem_sys_allocate _pmc_new _string_from_cstring /usr/bin/libtool: internal link edit command failed make: *** [../../runtime/parrot/dynext/m4_eval_compiler.dylib] Error 1
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
Chip Salzenberg <[EMAIL PROTECTED]> writes:
> On Sun, Jun 12, 2005 at 03:15:22PM +0100, Piers Cawley wrote:
>> But if you fallow the calling conventions that looks like:
>>
>>sub foo {
>> $a = 1.
>> $c = 10;
>> print $c
>>
>> save_dollar_a_and_only_dollar_a_because_im_going_to_use_it_after_this_function_call
>> foo()
>> _implicit_label_for_return_continuation:
>> restore_dollar_a
>> _ooh_i_dont_have_to_save_anything
>> $b = bar()
>> _nor_do_i_have_to_restore_anything
>> print $b
>>}
>
> You have greatly misunderstood. We're talking about how &foo manages
> its callee-saves registers. The registers involved, the ones that I'm
> calling $a and $b, are P16-P31.
>
>> Of course, if you're going to actually use GOTO to get to some label
>> that you should only get to via a continuation ...
>
> For purposes of allocating the callee-saves registers, a continuation
> may as well _be_ a goto.
No it's not. A continuation should carry all the information required to
restore the registers to the correct state when it is taken. A goto
doesn't. For the purposes of allocating the registers in foo you can allocate
$a to P16, and $b to p16, because when the call to bar takes the continuation
back to bar, the 'restore' phase should grab $a from the continuation and bung
it back on P16. The continuation doesn't even need to know where to restore $a
to, because the 'caller restores' code should take care of that.
> Don't feel bad, though. I thought the same thing the first time *I*
> heard about this problem.
I think you should have held that thought.
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
I'd like like to note for other readers and the p6i archives that Piers has failed to grasp the problem, so the solution seems pointless to him. I'm sorry that's the case, but I've already explained enough. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: m4 build failure on OS X.
Verified, still borked in r8328 William Coleda wrote: With a fairly recent parrot (8308) oolong:~/research/parrot/languages/m4 coke$ make cc -g -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe -fno-common -Wno-long-double -I../../include -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization -falign-functions=16 -Wno-shadow -c src/eval.c c++ -dynamiclib -L/usr/local/lib -flat_namespace -o ../../runtime/parrot/dynext/m4_eval_compiler.dylib eval.o ld: Undefined symbols: _PackFile_Segment_new_seg _Parrot_compreg _Parrot_switch_to_cs _const_string _mem_sys_allocate _pmc_new _string_from_cstring /usr/bin/libtool: internal link edit command failed make: *** [../../runtime/parrot/dynext/m4_eval_compiler.dylib] Error 1
[perl #36261] [TODO] HLL exception handling
# New Ticket Created by Will Coleda # Please include the string: [perl #36261] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36261 > Document how HLL languages can implement their own exception hierarchy, and perhaps define how they can have parrot reformat their exception output for them.
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
At 07:15 AM 6/12/2005, Chip Salzenberg wrote: Therefore, register allocation must allow for implicit flow of control from *every* function call to *every* function return ... or, more precisely, to where *every* continuation is taken, including function return continuations. Yes. But for casual readers, you might want to qualify that with: "For a given basic block..." Just a couple of thoughts to add: 1) As far as variable lifetime, the brute-force method would assume lifetime windows (du-chains) from the first definition of each variable to the last function call in a basic block. Horrible for optimization. 2) For languages without eval() it is possible simply to do compile time analysis of routines and associate an AST attribute with whether the routine captures or invokes a continuation, and for languages with Continuation Passing Style calls, you can analyze whether the function does anything but use Return Continuations. This would give the register allocator enough information to properly break down the basic blocks into correct DU-chains and allocate with confidence. However, given Parrot's intended target languages, I feel that (2) is going to be rarely applicable. -Melvin
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
At 01:16 PM 6/12/2005, MrJoltCola wrote: At 07:15 AM 6/12/2005, Chip Salzenberg wrote: 1) As far as variable lifetime, the brute-force method would assume lifetime windows (du-chains) from the first definition of each variable to the last function call in a basic block. Horrible for optimization. I said that wrong. If a standard du-chain intersects the window between first function call and last function call in a basic block, you probably have to extend the du-chain to the last call in the block. -Melvin
[perl #36262] [TODO] Match floats with a perl6 rule
# New Ticket Created by Will Coleda # Please include the string: [perl #36262] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36262 > Anyone looking for some perl6 to do, I need a rule that matches floating-point numbers specified in any of the ways accepted by an ANSI-compliant C compiler. Bonus points if you write it in PIR calling PGE instead of P6. (Needed for the rewrite of tcl's [expr])
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
Chip~ On 6/12/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote: > I'd like like to note for other readers and the p6i archives that > Piers has failed to grasp the problem, so the solution seems pointless > to him. I'm sorry that's the case, but I've already explained enough. This response worries me firstly because of its rudeness and second because of the problem itself. As I see it there are four possibilities a: 1) Chip is right, Piers is wrong. This is a complex problem and refusing to explain it means that others will doubtless also misunderstand it, which you have a chance to preempt here. 2) Chip is wrong, Piers is right. This is a complex problem and refusing discussion on it would be a costly mistake. 3) Chip is right, Piers is right. The two of you have are working from a different base set of definitions/axioms or misunderstood each other in some other way. 4) Chip is wrong, Piers is wrong. Shutting down open conversation so forcefully and caustically will prevent discussion in the future and this problem will continue to haunt parrot as no viable solution has been seen. Regardless of which of these possibilities is true. I see a need for more discussion of this issue. Preferably a discussion that does not degrade into backhanded insults. I have my own ideas about this problem, but I will save that for another response. Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
Matt Fowles <[EMAIL PROTECTED]> writes: > Chip~ > > On 6/12/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote: >> I'd like like to note for other readers and the p6i archives that >> Piers has failed to grasp the problem, so the solution seems pointless >> to him. I'm sorry that's the case, but I've already explained enough. > > This response worries me firstly because of its rudeness and second > because of the problem itself. As I see it there are four > possibilities a: > > 1) Chip is right, Piers is wrong. This is a complex problem and > refusing to explain it means that others will doubtless also > misunderstand it, which you have a chance to preempt here. > > 2) Chip is wrong, Piers is right. This is a complex problem and > refusing discussion on it would be a costly mistake. > > 3) Chip is right, Piers is right. The two of you have are working from > a different base set of definitions/axioms or misunderstood each other > in some other way. > > 4) Chip is wrong, Piers is wrong. Shutting down open conversation so > forcefully and caustically will prevent discussion in the future and > this problem will continue to haunt parrot as no viable solution has > been seen. > > Regardless of which of these possibilities is true. I see a need for > more discussion of this issue. Preferably a discussion that does not > degrade into backhanded insults. I have my own ideas about this > problem, but I will save that for another response. Don't worry Matt, we're still talking. It takes more than sarcasm to stop me.
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
On 6/12/05, Piers Cawley <[EMAIL PROTECTED]> wrote:
> Chip Salzenberg <[EMAIL PROTECTED]> writes:
>
> > On Sun, Jun 12, 2005 at 03:15:22PM +0100, Piers Cawley wrote:
> >> But if you fallow the calling conventions that looks like:
> >>
> >>sub foo {
> >> $a = 1.
> >> $c = 10;
> >> print $c
> >>
> >> save_dollar_a_and_only_dollar_a_because_im_going_to_use_it_after_this_function_call
> >> foo()
> >> _implicit_label_for_return_continuation:
> >> restore_dollar_a
> >> _ooh_i_dont_have_to_save_anything
> >> $b = bar()
> >> _nor_do_i_have_to_restore_anything
> >> print $b
> >>}
> >
> > You have greatly misunderstood. We're talking about how &foo manages
> > its callee-saves registers. The registers involved, the ones that I'm
> > calling $a and $b, are P16-P31.
> >
> >> Of course, if you're going to actually use GOTO to get to some label
> >> that you should only get to via a continuation ...
> >
> > For purposes of allocating the callee-saves registers, a continuation
> > may as well _be_ a goto.
>
> No it's not. A continuation should carry all the information required to
> restore the registers to the correct state when it is taken. A goto
> doesn't. For the purposes of allocating the registers in foo you can allocate
> $a to P16, and $b to p16, because when the call to bar takes the continuation
> back to bar, the 'restore' phase should grab $a from the continuation and bung
> it back on P16. The continuation doesn't even need to know where to restore $a
> to, because the 'caller restores' code should take care of that.
>
> > Don't feel bad, though. I thought the same thing the first time *I*
> > heard about this problem.
>
> I think you should have held that thought.
>
I also do not see the wisdom of reducing continuations to just a GOTO.
Continuations should have all the abilities of a function, with the
additional abilities of returning its state, in the form of its
activation record, and being reinvoked with said activation record.
The activation record stores all info about the state of the function
(saved registers, calling function, PC, etc). Maybe think of it as a
snapshot of the function's state.
So, in the example, bar() reinvokes the continuation, but this all
takes place in a new call to foo(), using the returned activation
record. The registers and PC return to the continuation's previous
state. So, just like a recursive function, you are running the same
function in a different context, and the registers do not overlap.
Callee-save registers must be saved after the function gains control,
and restored before it passes off control. So anywhere a function
returns a continuation, it must restore the callee-save registers
before and save them after.
It might also be helpful to take a look at other systems that also
implement continuations:
-Stackless Python (http://www.stackless.com/spcpaper.htm)
-Standard ML (http://www.smlnj.org/doc/features.html)
-Formalizing Implementation Strategies
(http://citeseer.ist.psu.edu/danvy00formalizing.html)
-Others (http://c2.com/cgi/wiki?ContinuationImplementation)
-Curtis Rawls
Re: PGE, namespace'd rules.
On Sun, Jun 12, 2005 at 12:57:56PM +0200, Chip Salzenberg wrote: > On Fri, Jun 10, 2005 at 05:18:19PM -0400, William Coleda wrote: > > Looking through the PGE test examples, it *looks* like subrules are just > > globals. > > I'm sure that's not how it'll behave when it's done, though I don't > know PGE well enough yet to suggest how it will work exactly. In the > meantime, I guess you'll need to use the standard mangling tricks > (e.g. prepending "__pge_" to rule names). At the present, PGE rules are just globals because I've still been working out the details about where rules belong in a namespace. See the thread on perl6-language starting at http://www.nntp.perl.org/group/perl.perl6.language/21692 . It's looking more and more as though named rules (subrules) are actually methods of class "Rule" or one of its grammar subclasses, and that "PGE::Match" objects (the things being returned from a match) are actually Rule objects. At the moment the only way I know to create a method in a PIR class is to use the .namespace directive and a "method" subpragma at the time the PIR code is compiled -- i.e., I haven't seen a way to take an existing subroutine PMC and install it as a method in an existing class. This isn't a big issue in itself, it just means that one has to supply the name and grammar of the rule at the time the rule is being compiled (rather than compiling a rule and storing the resulting subroutine/method in a symbol table afterwards). Of course, I may be overlooking the right way to do this, but that's where things stand at the moment. Pm
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
On Sun, Jun 12, 2005 at 03:40:55PM -0600, Curtis Rawls wrote: > I also do not see the wisdom of reducing continuations to just a GOTO. It really isn't just a goto, at least, not a hardware-CPU-style goto. By virtue of Parrot's registers living in memory attached to the activiation record, switching control to a saved activation record automatically restores all the registers. Automagically, even. I've talked this over extensively with Piers (on IRC), Autrijus, and Leo, and I'm now convinced that switching to a saved activation record, along with the register contents still in it, is enough. Granted, the register allocator[*] will still need to learn that it can't use any given register for incompatible purposes across subroutine call boundaries (or across labels). But given the new larger cheeze-its^Wregister frame, that's no problem. > Continuations should have all the abilities of a function, with the > additional abilities of returning its state, in the form of its > activation record, and being reinvoked with said activation record. > The activation record stores all info about the state of the function > (saved registers, calling function, PC, etc). Maybe think of it as a > snapshot of the function's state. Quite. My "glorified goto" description neglected a key difference between the Parrot VM and a real CPU: a goto in a real CPU does not restore registers, while switching activation records in Parrot does. [*] the PIR register allocator, that is, which may under certain circumstances realize that $P30 and $P35 have disjoint lifetimes and are never used across a function call, and therefore can be assigned to the same actual P register (e.g. P20) -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: [perl #36258] [RFE] parrotbug should include the SVN revision.
On Sun, 2005-06-12 at 07:27 -0700, Will Coleda wrote: > > BTW: a nice to have: include SVN revision of local copy in bug report. It looks like it's already in the contents of myconfig at the end of the bug report; is there more to do here? -- c
Re: PGE, s/ub/st/
On Sun, Jun 12, 2005 at 12:05:10AM -0400, William Coleda wrote: > Is it possible to do substitutions with PGE yet? If so, how? Single (first occurrence) substitutions are possible; simply perform the match, the match object returns the start/end location of the item that matched, and then do a substr operation based on that information. Performing multiple substitutions doesn't exist yet in pure PGE; eventually we'll have the ":globally" option available, in this case the match object will have a .matches method that will return the array of items that matched, and one can perform the substitutions on that (presumably in reverse sequence so as to not interfere with offsets too much). Pm
Re: [perl #36258] [RFE] parrotbug should include the SVN revision.
Probably not. I was merely trying to save an RFE I saw in one of leo's mails. If it looks like it's there, feel free to close the ticket. chromatic wrote: On Sun, 2005-06-12 at 07:27 -0700, Will Coleda wrote: BTW: a nice to have: include SVN revision of local copy in bug report. It looks like it's already in the contents of myconfig at the end of the bug report; is there more to do here? -- c
new list for pirate [python on parrot]
I just set up a new list for pirate, a python compiler for parrot. Quite a bit of work has been done on pirate since I last updated the website back in 2003, mostly by Sam Ruby of http://intertwingly.net/ Sam is giving a python-on-parrot presentation at OSCON on August 4, so I'd like to get a few things cleaned up before then - for example, updating the site, creating a development roadmap, an fixing the code to work with the latest version of parrot, etc. If you're interested in helping out with any of these things, or just want to talk about pirate, then feel free to hop on board. The signup page is here: http://cornerhost.com/mailman/listinfo/pirate Thanks! - Michal http://withoutane.com/
Re: Attack of the fifty foot register allocator vs. the undead continuation monster
On 6/12/05, Curtis Rawls <[EMAIL PROTECTED]> wrote: > > [snip] > It might also be helpful to take a look at other systems that also > implement continuations: > -Stackless Python (http://www.stackless.com/spcpaper.htm) > -Standard ML (http://www.smlnj.org/doc/features.html) > -Formalizing Implementation Strategies > (http://citeseer.ist.psu.edu/danvy00formalizing.html) > -Others (http://c2.com/cgi/wiki?ContinuationImplementation) > > -Curtis Rawls > I found this link helpful when trying to understand continuations. The code they use is not secure. It is basically using buffer overflow attacks as a programming technique? Well, you'll have to read to understand what I mean. http://homepage.mac.com/sigfpe/Computing/continuations.html The part that I understand about continuations, is that they wreak havoc in the control flow graph, as Chip initially said: > Therefore, register allocation must allow for implicit flow of control > from *every* function call to *every* function return ... or, more > precisely, to where *every* continuation is taken, including function > return continuations. Although I think that is actually sugar coating it a bit. Continuations can be taken from within any sub, and possibly even when appending to a list, if you're using lazy list eval. This, I found out when my changes to reg_alloc.c broke the continuations tests. The changes were not the problem, as Leo confirmed, it was the way the allocator and the continuations interacted. There are also some issue about changing variables through continuations, like you can only change PMC integers, which point to some fixed location, containing the int, i.e. you can only use references. These parts make less sense to me, but the issue is basically, some registers are restored, and some are kept safe? Well, that issue hasn't been quite resolved either. If I thought the register allocator had a chance of working, I would probably find the time to start working on it again. But probably there are plenty of people who would be happy to do so, if this issue could be resolved. -- -Bill Coffman
