Re: string.c questions
Benjamin Goldberg <[EMAIL PROTECTED]> wrote: > To what does 'bufused' refer? The number of bytes from where to where? Number of bytes from strstart to "strend". > I *thought* that it was from bufstart to the end of the string... no? No, bufstart is the physical buffer start used for reallocating/freeing. > And where is all this documented? docs/string.pod has a summary of all string variables. leo
Re: pdd03_calling_conventions.pod questions
Vladimir Lipskiy <[EMAIL PROTECTED]> wrote: > Q1: Suppose I have the following call into a sub named "foo": First of all, are you targeting PASM or PIR? For the latter, its done automatically. > foo($var1, $var2, $var3); > foo($var1, @arr2, %hash3); > Is it still 3, since these aren't gonna be flattened? Both have 3 params. If these are PMCs, they go in P5..P7, so *I2* would be 3. > Q2: I'm calling without prototyping > foo($var1, $var2, $var3, ... , $var23); > Here, what should I place in I2? Is it 11 (as we have P5-P15) or > 23 (considering the P3 register)? I would expect I2=11, I1=12 leo
Re: pdd03_calling_conventions.pod questions
> First of all, are you targeting PASM or PIR? For the latter, its done > automatically. I mean PASM > > Q2: I'm calling without prototyping > > > foo($var1, $var2, $var3, ... , $var23); > > > Here, what should I place in I2? Is it 11 (as we have P5-P15) or > > 23 (considering the P3 register)? > > I would expect I2=11, I1=12 D'oh, I suspected it should be I2=11, I1=23. It seems to me that I finally got what was considered to be the parameter list. So, when you say PARAMETER LIST, you have in mind all the I5-I15, N5-N15, S5-S15, P3, P5-P15 registers, don't you? That is, I should place in I1 the number of these registers I filled.
Re: Ultra bootstrapping :)
Benjamin Goldberg <[EMAIL PROTECTED]> writes: > Considering that parrot is now emitting an executable (on some > platforms)... and IIRC, C will be one of the languages we plan to have > parrot support for... will parrot be able to compile itself? :) Not yet ;-) There are some problems: The emitted executable needs a libparrot. If parrot can compile itself, it must produce a library which replaces libparrot. There need to be the opposite of the current NCI: the possibility of creating a C-function which can call a parrot-sub (But this needs to be done for callbacks). And there must be a way to get around parrots memory system because libparrot wants to implement this memory system (otherwise a native call to malloc should be possible). I have an even more evil idea: Port parrot to VHDL or Verilog and burn this into a FPGA. A native parrot chip would be ultracool. I need to dig out my VHDL-book :-) boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Infant mortality
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> I was recently reading the following:
>
>http://www.parrotcode.org/docs/dev/infant.dev.html
>
> It's missing some things. One of which is the (currently used?) way of
> preventing infant mortality: anchor right away, or else turn off DoD
> until the new object isn't needed.
This is Solution 3: Explicit root set augmentation
Its not explained in so much details than the other solutions.
> This document doesn't mention another technique, which was mentioned
> recently:
>
>http://groups.google.com/groups?
> selm=m2k7asg87i.fsf%40helium.physik.uni-kl.de
>
> , at the "use a linked list of frames" part.
In principle this is a variant of the explicit root set
augmentation. The linked list of frames is part of the root set. The
big advantages of this list is that return and longjmp automatically
drop the now unused objects, because each partial list is stored in
the C-stack-frames.
> Another similar idea (one which I thought of myself, so feel free to
> shoot it down!) is to use a generational system, with the "current
> generation" as a value on the C stack, passed as an argument after the
> interpreter. That is, something like:
>
> foo(struct ParrotInterp *interpreter, int generation, ...)
> {
> PMC * temp = bar(interpreter, generation);
> baz(interpreter, generation+1);
> }
>
> Because inside baz(), generation is a higher value than it was when temp
> was created, a DOD run inside of baz() won't kill foo.
This is a solution similar to Solution 2 / Variant 4: Generation
count.
> During a DOD run, any PMC with a generation less than or equal to the
> current generation is considered live.
You can even use mark the current generation as free. If a function
wants to keep data it uses Parrot_do_DOD(interp, generation + 1). If
it does not have any data to keep it calls Parrot_do_DOD(interp,
generation).
> Any PMC with a generation
> greater than the current generation gets it's generation set to 0.
You mean is marked as free. An anchored object should be set to 0.
> Like the linked list scheme, this works through longjmps and recursive
> run_cores, and it's much simpler for the user, too: just add one to the
> generation to prevent all temporaries in scope from being freed.
>
> It similarly has the drawback of altering the signature of every parrot
> function.
If this will lead to exact and fast DOD we might bite the bullet.
> There's another drawback I can think of... consider:
>
> foo(struct ParrotInterp *interpreter, int generation, ...)
> {
> PMC * temp = bar(interpreter, generation);
> baz(interpreter, generation+1);
> qux(interpreter, generation+1);
> }
>
> If baz creates a temporary object and returns, then qux performs a DOD,
> baz's (dead) object won't get cleaned up.
When asume the current generation as free (less than instead of less
equal) this is not problem. Only if qux calls another function with an
increased generation count without a prior call to Parrot_do_DOD the
temporaries of baz will survive. But this can be solved by:
foo(struct ParrotInterp *interpreter, int generation, ...)
{
PMC * temp = bar(interpreter, generation);
baz(interpreter, generation+1);
Parrot_do_DOD(interpreter, generation+1); /* free the temporaries baz */
qux(interpreter, generation+1);
}
> This could be solved by keeping a stack of newly created objects, and
> providing some sort of generational_dod_helper() function, which would
> do something like:
>while( neonates && neonates->top->generation > current_generation ) {
> neonates->top->generation = 0;
> neonates = neonates->next;
>}
> , and calling that in foo between baz and qux. (And maybe sometimes at
> toplevel, between opcodes... at times when the generation count in a
> "normal" generation count scheme (with a global counter) would be
> incremented) You lost a bit of simplicity, by having to call this
> function occcasionally, but it can save a bit of memory.
In principle your generational_dod_helper is the sweep-function of the
garbage-collector (or in parrot its called free_unused_objects). If
you are sure that no objects have been anchored since the last mark no
further mark is necessary (Parrot_do_DOD). But I'm not sure if you can
guarantee that.
I have the feeling that extending the signature of all
Parrot-functions will remove the need of walking the C-Stack
entirely. If this will be the linked list of frames or the generation
count is more or less a matter of taste: The generation count forces
some intermediate DOD-runs, whereas the linked list of stack
frames makes the creation of temporaries a little bit more
complicated.
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Infant mortality
At 3:28 PM +0200 8/4/03, Juergen Boemmels wrote: I have the feeling that extending the signature of all Parrot-functions will remove the need of walking the C-Stack entirely. If this will be the linked list of frames or the generation count is more or less a matter of taste: The generation count forces some intermediate DOD-runs, whereas the linked list of stack frames makes the creation of temporaries a little bit more complicated. I'm still not convinced that any of the non-stackwalking alternatives are really worth it. Stackwalking as a higher per-run cost (as stack elements are more expensive to evaluate) and potential portability issues (as we can't guarantee stacks on a platform, and may have fun getting register contents) but has the advantage of having no per-allocation anchoring expense and reducing the number of places in the source that have to be specially designed to not die too soon. We have a solution, and it works. The garbage collector certainly has things that can be done to it, but at this point we'd be better served by work on a generational collector, or teaching the dead sweep to build a tree of dead objects for ordered destruction. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: pdd03_calling_conventions.pod questions
At 4:23 AM +0300 8/4/03, Vladimir Lipskiy wrote: Q1: Suppose I have the following call into a sub named "foo": foo($var1, $var2, $var3); What should I set in I1? Is it 3? Nope. I2 should be 3, and I1 0. (Assuming you put those three parameters in the first three PMC registers, which is what you should do even in the unprototyped case) And here: foo($var1, @arr2, %hash3); Is it still 3, since these aren't gonna be flattened? I2 is still 3 and I1 0. Q2: I'm calling without prototyping foo($var1, $var2, $var3, ... , $var23); Here, what should I place in I2? Is it 11 (as we have P5-P15) or 23 (considering the P3 register)? I2 should be 11, and I1 should be 12. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String value semantics?
At 10:00 AM -0600 8/3/03, Luke Palmer wrote: Is this supposed to happen? % parrot - .sub _main $S0 = "Hello\n" $S1 = $S0 substr $S1, 2, 2, "" print $S0 print $S1 end .end (EOF) Heo Heo Aren't strings supposed to follow value semantics? Don't think so, no. = in IMCC, unless things have changed, is equivalent to the set operation in parrot assembly, and that just copies the contents of the register. Since string registers are just pointers, you'll get this sort of aliasing behaviour. For true copies you need either the assign op (to reuse the destination) or the clone op (to make a clone of the original) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Set vs. Assign..?
At 11:45 AM -0700 8/1/03, T.O.G. of Spookware wrote: Hi, all. I've been following Parrot development and been playing with Parrot for a...bout a year and a half, now. First time posting to the list, though, so forgive me if this has already been covered or is stupid in some way :-) Anyway, while playing around with IMCC, this kind of bugged me: P3 = 32 # tells the PMC referenced by P3 to set its value to 32 P3 = P5 # copies reference in P5 to P3 What I don't like about this is that it's not immediately obvious from looking at the code whether you're telling P3 to change its value or simply replace the PMC reference stored in P3 with another. This is a reasonable thing to worry about, because we have three separate semantics, set, assign, and clone. For I and N registers, all three are identical, since integers and floats are value types at this level. For S and P registers, things get odd. set just copies the contents of one register to another. Since P and S registers are pointers, it means you have two registers that point to the same string or PMC structure. Assign takes the contents of the structure that the S or P source register points to and puts those contents into the structure the destination register points to. A new structure is not created, and if the destination is supposed to do something when a value is put into it, then the destination does that. (If, for example, the destination variable overloads assignment or is tied, depending on the language you come from) Cloning makes a copy of the source, complete with new structure, and puts a pointer to the new structure into the destination register, throwing away whatever pointer was in there to begin with. It's a bit funky, but you need all three semantics to make things work out right. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Sorry 'bout the backwards replies
I'm digging out from under near two-weeks of p6i mail, and taking it from back to front. If there are pending issues I've not gotten to in the next few days (as it's a lunch and evening project) then pop them back to the list and we'll get them addressed. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Packfile stuff
Here's some stuff we need to add to the packfile format and the sub header to get things ready for more language work. Packfiles need to have a symbol table. A series of name/type/location tuples so we can have global names that map to values in the bytecode, either variables or subroutines. When the bytecode is loaded, we need to put those symbols in the symbol table and construct the backing PMCs. Subs need to have some metadata attached to them so we can properly instantiate them. Each sub PMC needs to have attached to it a start & end bytecode address (I know we have start, we need end too) and a pointer to the packfile that it came from (even if we construct it on the fly), and a set of security credentials (which we'll leave empty for now). Possibly other things too, I'm not sure. When we invoke a sub (or closure, or continuation, or whatever) we need to put that packfile pointer and bytecode start/end pointer in place, so constant lookups will find the right tables, line number/filename mappings can work, metadata lookups actually look up, and suchlike things. There's a bit more, but this is a good start. If people want to bat this around some, we can put together a list in the repository and start getting it implemented. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Set vs. Assign..?
--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 11:45 AM -0700 8/1/03, TOGoS wrote: > > ...blah, blah, blah... > > > > What I don't like about this is > > that it's not immediately obvious > > from looking at the code whether > > you're telling P3 to change its > > value or simply replace the PMC > > reference stored in P3 with another. > > This is a reasonable thing to worry > about, because we have three separate > semantics, set, assign, and clone. Well, yes. I understand what set, assign, and clone do. :-) What I was whining about was that 'set' doesn't consistantly copy pointers. If you say set PMC, PMC it copies a pointer, but if you say set PMC, Int it behaves like 'assign'. I just thought it might be better if you had to be explicit about what you were doing. If you want assign semantics, you should have to say "assign". So set PMC, Int would be illegal, since you can't copy an integer to a PMC pointer. You would be forced to say what you really meant, which is assign PMC, Int And likewise for strings. (At the moment, I am forced to use 'set' for strings, because assign S0, 23 throws a 'can't find assign_s_ic' error.) I just thought that it might save people from a few headaches if "set" always meant the same thing :-) __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: pdd03_calling_conventions.pod questions
Vladimir Lipskiy <[EMAIL PROTECTED]> wrote: >> > foo($var1, $var2, $var3, ... , $var23); >> >> I would expect I2=11, I1=12 > D'oh, I suspected it should be I2=11, I1=23. No. You have the first 11 parameters in P5..P15 (I2=11). Then you have 12 more, which go into the overflow array P3 (I1=12) > ... It seems to me that > I finally got what was considered to be the parameter list. So, when > you say PARAMETER LIST, you have in mind all the I5-I15, N5-N15, > S5-S15, P3, P5-P15 registers, don't you? The parameter list are all the function parameters. When you have an unprototyped sub, I5.., S5,.. N5... are unused. > ... That is, I should place in I1 > the number of these registers I filled. I1 ... Number of items in the overflow/parameter array P3. leo
Re: Set vs. Assign..?
> --- Dan Sugalski <[EMAIL PROTECTED]> wrote: > > At 11:45 AM -0700 8/1/03, TOGoS wrote: > > > ...blah, blah, blah... > > > > > > What I don't like about this is > > > that it's not immediately obvious > > > from looking at the code whether > > > you're telling P3 to change its > > > value or simply replace the PMC > > > reference stored in P3 with another. > > > > This is a reasonable thing to worry > > about, because we have three separate > > semantics, set, assign, and clone. > > Well, yes. I understand what set, assign, > and clone do. :-) What I was whining about > was that 'set' doesn't consistantly copy > pointers. > > If you say > set PMC, PMC > it copies a pointer, but if you say > set PMC, Int > it behaves like 'assign'. Yeah, I agree with this. > I just thought it might be better if > you had to be explicit about what you > were doing. If you want assign semantics, > you should have to say "assign". So > set PMC, Int > would be illegal, since you can't copy > an integer to a PMC pointer. You would > be forced to say what you really meant, > which is > assign PMC, Int And ghod forbid, for arrays: elements PMC, int (an elements op would be really nice, because then infinite lists could return infinite elements:) elements PMC, PMC It might be confusing to have both "set elements" and "get elements" by the same name. But those are just details. > And likewise for strings. (At the moment, > I am forced to use 'set' for strings, because > assign S0, 23 > throws a 'can't find assign_s_ic' error.) But the set_s_ic op doesn't do an assign. S0 = "Hello" S1 = S0 S1 = 23 print S0 Prints "Hello". So basically, I'm for getting rid of some of the C variants in favor of more explicit ops... usually C. > I just thought that it might save > people from a few headaches if "set" > always meant the same thing :-) Luke > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com
[perl #23218] [PATCH] Description of more variants in docs/dev/infant.dev
# New Ticket Created by Jürgen Bömmels # Please include the string: [perl #23218] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=23218 > Recent mailing list discussions added some new variants to the infant mortality problem. These variants shouldn't get lost, so i tried to summarize them and add them to infant.dev No, I don't want to start a new discussion, I just don't want to loose these new variants. -- attachment 1 -- url: http://rt.perl.org/rt2/attach/62214/45848/bf4fea/infant_dev.diff Index: docs/dev/infant.dev === RCS file: /cvs/public/parrot/docs/dev/infant.dev,v retrieving revision 1.1 diff -u -r1.1 infant.dev --- docs/dev/infant.dev 10 Jan 2003 15:35:51 - 1.1 +++ docs/dev/infant.dev 4 Aug 2003 18:18:54 - @@ -44,6 +44,10 @@ is insufficient -- you must also scan through all processor registers, and for some processors there may be a separate backing store for those registers (eg the Sparc's register windows). +Uninitialized data on the stack and high alignment requirements for +stackframes can fool the DOD with left over pointers from previous +calls. This is especially a problem for objects which need early +destruction. + No slowdown in the common case of no DOD + Convenient: the programmer does not need to code differently to @@ -172,9 +176,30 @@ - Can temporarily use more memory (dead objects accumulate during all current generations) +=head2 Variant 6: Generation based on stack depth + +Another similar idea is to use a generational system, with the +"current generation" as a value on the C stack, passed as an extra +argument after the interpreter. If a function creates a temporary +objects it calls other functions with an increased generational count. +During a DOD run, any PMC with a generation less than the +current generation is considered live. Any PMC with a generation +greater than the current generation is considered free. This works +through longjmps and recursive run_cores. + + + Simple + + No stack-walking + + Works through longjmps and recursive run_cores + + No explicit setting and clearing of flags + - Needs to change to change the signature of every Parrot-function + - Nested temporaries can survive if no DOD-run between two function + calls with increased generation count + =head1 Solution 3: Explicit root set augmentation -A final possible solution is to provide a mechanism to temporarily +=head2 Variant 1: Temporarily anchor objects + +Provide a mechanism to temporarily anchor an otherwise unanchored object to the root set. (eg, have an array of objects associated with the interpreter that are all considered to be part of the root set.) This has pretty much the same @@ -194,6 +219,38 @@ automatically removed from the temporary anchoring at generation boundaries, etc. +=head2 Variant 2: Anchor early, anchor often + +Place new PMC first in the root set (e.g. a register) then initialise +it. If that's to cumbersome, disable DOD, if that's suboptimal, use +active anchoring to some root set linked list for temp PMCs. + + + Simple + + Fast DOD (No stack-walking) + - DOD might be turned of for a long time (Maybe a recursive run_core + is called) + - Easy to forget to reenable DOD + - longjmp() can bypass reenabling of DOD (this might be hidden in the + wrapper functions as only one value needs to be restored) + +=head2 Variant 3: Use a linked list of frames + +The signature of every parrot function is extended with an extra +parameter which is a parameter to a frame structure. All temporary +PMCs needs to put into such a frame structure. The first parameter of +this frame structure is a link to the previously used frame +structure. If a function that can do a DOD run is called a pointer to +the current frame is applied. The linked list of frames represents +always an exact list of the active temporaries on the C-stack. + + + Fast DOD-runs (only the known PMC-pointers are walked) + + Exact + + works through recursive run_cores and longjmp() + - signature of every Parrot function changes + - Creation of temporaries is complicated (Need to create a frame + first) + + =head1 REFERENCES =over 4 @@ -228,6 +285,8 @@ http://groups.google.com/groups?th=66fe6f12e11a5f8d +This thread also includes Benjamin Goldberg Variant 6 + =item Dan thinks the stackwalk is unavoidable http://groups.google.com/groups?th=f7e270609ef93161 @@ -252,8 +311,15 @@ Early discussion that has some stuff I didn't go over here. Mostly involves generational schemes. +=item Problems with stack-walking + +http://groups.google.com/groups?th=f9fc9c6d28eae2b5 + +This thread also includes Juergen Boemmels Variant 3 of Solution 3 + =back =head1 CHANGES 2002-Dec-30: Initial Version by Steve Fink +2003-Aug-04: Some extra variants added by Juergen Boemmels
Re: [perl #23218] [PATCH] Description of more variants in docs/dev/infant.dev
Thanks, applied (with a few typographical tweaks by me). Simon
Re: double checking: in vs on?
At 12:03 AM -0400 8/4/03, Michal Wallace wrote: nd in the PMC vtable, it maps this way: in = get_*_keyed, set_*_keyed, delete_keyed_* on = getprop / setprop / delprop Is that right? For Python, yep. the _keyed stuff is for access to container things--hashes and arrays, generally, though anything that can be accessed via a key of some sort is fair game here. (Since keys can be integers, strings, or PMCs) The get/set/delprop is for properties on PMCs, which pretty much correspond to Python's attributes. (Or slots, depending on how you think about them) ( Any reason it's not del_*_keyed? :) ) We were shooting for completeness consistency rather than length consistency. :) We apparently were shooting for a different sort of consistency with the property stuff... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Infant mortality
Juergen Boemmels wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> writes:
>
> > I was recently reading the following:
> >
> >http://www.parrotcode.org/docs/dev/infant.dev.html
> >
> > It's missing some things. One of which is the (currently used?) way
> > of preventing infant mortality: anchor right away, or else turn off
> > DoD until the new object isn't needed.
>
> This is Solution 3: Explicit root set augmentation
>
> Its not explained in so much details than the other solutions.
>
> > This document doesn't mention another technique, which was mentioned
> > recently:
> >
> >http://groups.google.com/groups?
> > selm=m2k7asg87i.fsf%40helium.physik.uni-kl.de
> >
> > , at the "use a linked list of frames" part.
>
> In principle this is a variant of the explicit root set
> augmentation. The linked list of frames is part of the root set. The
> big advantages of this list is that return and longjmp automatically
> drop the now unused objects, because each partial list is stored in
> the C-stack-frames.
>
> > Another similar idea (one which I thought of myself, so feel free to
> > shoot it down!) is to use a generational system, with the "current
> > generation" as a value on the C stack, passed as an argument after the
> > interpreter. That is, something like:
> >
> > foo(struct ParrotInterp *interpreter, int generation, ...)
> > {
> > PMC * temp = bar(interpreter, generation);
> > baz(interpreter, generation+1);
> > }
> >
> > Because inside baz(), generation is a higher value than it was when
> > temp was created, a DOD run inside of baz() won't kill foo.
>
> This is a solution similar to Solution 2 / Variant 4: Generation
> count.
>
> > During a DOD run, any PMC with a generation less than or equal to the
> > current generation is considered live.
>
> You can even use mark the current generation as free. If a function
> wants to keep data it uses Parrot_do_DOD(interp, generation + 1). If
> it does not have any data to keep it calls Parrot_do_DOD(interp,
> generation).
>
> > Any PMC with a generation
> > greater than the current generation gets it's generation set to 0.
>
> You mean is marked as free. An anchored object should be set to 0.
Actually, I meant generation set to MAX_INT, not 0.
Marking pmcs as free happens at the end of DOD. Marking pmcs as live or
dead happens earlier. I was thinking of something like:
foreach(pmc in all_pmcs) {
if( pmc->generation <= current_generation )
mark pmc as live
if( pmc is an aggregate )
add pmc to list of pmcs to be traced
/* don't alter it's generation */
else
mark pmc as dead
/* and if it becomes alive again, then */
/* on the next DOD, it shouldn't be considered */
/* alive due to being neonate/on the stack */
pmc->generation = MAX_INT;
}
foreach(pmc in root set) {
if( pmc is marked as live ) next;
mark pmc as live
if( pmc is an aggregate )
add pmc to list of pmcs to be traced
}
trace the pmcs in the list of pmcs to be traced
foreach(pmc in all_pmcs) {
if( pmc isn't live )
add pmc to the free list
}
> > Like the linked list scheme, this works through longjmps and recursive
> > run_cores, and it's much simpler for the user, too: just add one to
> > the generation to prevent all temporaries in scope from being freed.
> >
> > It similarly has the drawback of altering the signature of every
> > parrot function.
>
> If this will lead to exact and fast DOD we might bite the bullet.
Actually, I just thought of a seriously cool idea. If the C stack
always grows up, or always grows down, then we can use the address of
the local variable holding the interpreter, as the generation number.
Thus, we can avoid changing the prototype of all our functions. Sortof
like how one write an alloca() library function.
> > There's another drawback I can think of... consider:
> >
> > foo(struct ParrotInterp *interpreter, int generation, ...)
> > {
> > PMC * temp = bar(interpreter, generation);
> > baz(interpreter, generation+1);
> > qux(interpreter, generation+1);
> > }
> >
> > If baz creates a temporary object and returns, then qux performs a
> > DOD, baz's (dead) object won't get cleaned up.
>
> When asume the current generation as free (less than instead of less
> equal) this is not problem. Only if qux calls another function with an
> increased generation count without a prior call to Parrot_do_DOD the
> temporaries of baz will survive. But this can be solved by:
>
> foo(struct ParrotInterp *interpreter, int generation, ...)
> {
> PMC * temp = bar(interpreter, generation);
> baz(interpreter, generation+1);
> Parrot_do_DOD(interpreter, generation+1);
> /* free the temporaries baz */
> qux(interpreter, generation+1);
> }
>
> > This could be solved by keeping a stack of newly created objects, and
> > providing some sort of generational_dod
Re: Infant mortality
Having applied a bit more thought, having the generation field as part
of the PMC isn't all that great -- it makes PMCs larger, but it's really
only needed for new/neonate pmcs.
Instead of attatching the generation directly to the pmc, have a global
(per-interpreter) stack of neonate pmcs. Each stack entry contains both
the generation it was added, and the pointer to the pmc.
When a pmc is created, it does something like:
while( size(neonate_stack) && top(neonate_stack).gen > cur_gen )
pop(neonate_stack);
push(neonate_stack, { self, cur_gen });
During DOD, we do:
foreach(pmc in all_pmcs)
mark pmc as dead
while( size(neonate_stack) && top(neonate_stack).gen > cur_gen )
pop(neonate_stack)
foreach( pmc in root_set and on the neonate_stack ) {
if( pmc is alive ) next;
mark pmc as live
if( pmc is an aggregate )
add pmc to the list of pmcs to be traced
}
foreach( pmc in all_pmcs )
if( pmc is dead )
add pmc to free list;
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Re: pdd03_calling_conventions.pod questions
I don't think I was reading pdd03_calling_conventions.pod in a slipshod manner and I swear that this place in the pod >=item I1 > >The number of items pushed onto the parameter list. is the personification of confusion. > I1 ... Number of items in the overflow/parameter array P3. Hell yeah. That's what should be there instead of PARAMETER LIST, IMHO. Thanks Leo, Dan for commenting on this thread. (~:
Re: pdd03_calling_conventions.pod questions
At 11:05 PM +0300 8/4/03, Vladimir Lipskiy wrote: I don't think I was reading pdd03_calling_conventions.pod in a slipshod manner and I swear that this place in the pod =item I1 The number of items pushed onto the parameter list. is the personification of confusion. Then I'll go clarify that. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
parrot, win32, stand-alone distribution, separate Parrot maillist
Hi All, are there any info on getting ready-to-try Parrot for win32 as stand-alone distribution? If win32 is not met yet, what are the milestones then? What about separate Parrot maillist? (I am really sorry, I am not interested in Perl, but in Parrot) thanks a lot. -- Valery
Re: parrot, win32, stand-alone distribution, separate Parrot maillist
At 8:48 PM +0200 8/4/03, Valery A.Khamenya wrote: Hi All, are there any info on getting ready-to-try Parrot for win32 as stand-alone distribution? Not that I know of. If someone's got a working build and can put together a tarball or zip file, we can get it up for download. What about separate Parrot maillist? (I am really sorry, I am not interested in Perl, but in Parrot) This is the parrot mailing list--perl doesn't really get any more talk than any other language targetting parrot. (Though I should get the list namechange taken care of and out of the way) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: parrot, win32, stand-alone distribution, separate Parrot maillist
Valery A.Khamenya: > are there any info on getting ready-to-try > Parrot for win32 as stand-alone distribution? If you mean precompiled binaries, not yet. Parrot is still under development, so we aren't shipping binaries. > What about separate Parrot maillist? > (I am really sorry, I am not interested in Perl, > but in Parrot) The list is named "perl6-internals" mostly for historical reasons--the discussion on it is almost exclusively Parrot. Dan has said that it will eventually become something like "parrot-dev", but not yet. --Brent Dax <[EMAIL PROTECTED]> Perl and Parrot hacker
Re: parrot, win32, stand-alone distribution, separate Parrot maillist
- Original Message - From: "Dan Sugalski" <[EMAIL PROTECTED]> To: "Valery A.Khamenya" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, August 04, 2003 10:44 PM Subject: Re: parrot, win32, stand-alone distribution, separate Parrot maillist > At 8:48 PM +0200 8/4/03, Valery A.Khamenya wrote: > >Hi All, > > > > are there any info on getting ready-to-try > > Parrot for win32 as stand-alone distribution? > > Not that I know of. If someone's got a working build and can put > together a tarball or zip file, we can get it up for download. I can most probably do this; I've got the latest CVS checkout compiled here. What needs to go into the ZIP? My guesses are:- - parrot executable - imcc executable - The docs directory - The examples directory - The languages directory If you want regular (weekly? bi-weekly?) builds on Win32 zipping up and FTPing somewhere, I can do that for you. FYI, current test status on Win32:- Failed Test Status Wstat Total Fail Failed List of Failed t/op/gc.t 1 256 81 12.50% 2 t/pmc/io.t 3 768183 16.67% 3-5 t/src/manifest.t 1 256 41 25.00% 4 24 subtests skipped. Failed 3/53 test scripts, 94.34% okay. 5/841 subtests failed, 99.41% okay. Don't know if this is supposed to happen (I don't recall seeing it before), but I'm seeing this many times during the nmake proccess:- Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd classes && NMAKE && cd .. I see it maybe 10-20 times in a row when I run both nmake and nmake test, and always for that classes folder. nmake test also seems to do an implicit nmake, even though I've just done that. I'm guessing that shouldn't happen? I'm running Configure.pl with the options "--jitcapable=0 --execcapable=0", 'cus it won't build otherwise. Later, Jonathan
Re[2]: parrot, win32, stand-alone distribution, separate Parrot maillist
Hello Dan and ALL, Monday, August 4, 2003, 11:44:11 PM, you wrote: DS> Not that I know of. If someone's got a working build and can put DS> together a tarball or zip file, we can get it up for download. nice. ... but sounds, strange for me as for newbie :-) win32 is a platform and there should be some specific, platform dependent code. How could it be "by chance"? it is not kinda C:\tmp\>perl Configure.pl C:\tmp\>make and go. Or? :) BTW, under cygwin "perl Configure.pl" fails. DS> This is the parrot mailing list--perl doesn't really get any more DS> talk than any other language targetting parrot. (Though I should get DS> the list namechange taken care of and out of the way) I was a bit confused looking for a Parrot's list. Some better hints in top web entries would be good really for parrot-newbies like me. P.S. guys, it is cool what you do. Lispers had 50 years in order to do the same and never created something like that. Come'on, don't die please! -- Best regards, Valerymailto:[EMAIL PROTECTED]
Re[2]: parrot, win32, stand-alone distribution, separate Parrot maillist
Hello Brent and others, BD> If you mean precompiled binaries, not yet. Parrot is still under BD> development, so we aren't shipping binaries. OK, clear. well, what about win32 milestones? BD> The list is named "perl6-internals" mostly for historical reasons--the BD> discussion on it is almost exclusively Parrot. Dan has said that it will BD> eventually become something like "parrot-dev", but not yet. it would be good. -- Best regards, Valerymailto:[EMAIL PROTECTED]
Re[2]: parrot, win32, stand-alone distribution, separate Parrot maillist
Hello Jonathan, Tuesday, August 5, 2003, 12:28:16 AM, you wrote: JW> I can most probably do this; I've got the latest CVS checkout compiled here. JW> What needs to go into the ZIP? My guesses are:- JW> - parrot executable JW> - imcc executable JW> - The docs directory JW> - The examples directory JW> - The languages directory JW> If you want regular (weekly? bi-weekly?) builds on Win32 zipping up and JW> FTPing somewhere, I can do that for you. well, I am not sure, what the due content should be, but it would be really good, and not just for me! Guys, sitting at Perl you do a great work for all dynamic languages. If you could make your first pages on web more comprehensive for other non-PERLers then you could obtain some help from outside I guess. JW> FYI, current test status on Win32:- ?! under cygwin? JW> Don't know if this is supposed to happen (I don't recall seeing it before), JW> but I'm seeing this many times during the nmake proccess:- JW> Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 JW> Copyright (C) Microsoft Corp 1988-1998. All rights reserved. JW> cd classes && NMAKE && cd .. or using cl.exe/MSVC ? "nmake" sounds quite strange with ultimate goal of portability, but anyway. -- Best regards, Valerymailto:[EMAIL PROTECTED]
Re: Re[2]: parrot, win32, stand-alone distribution, separate Parrot maillist
Hi, > Tuesday, August 5, 2003, 12:28:16 AM, you wrote: > > JW> What needs to go into the ZIP? My guesses are:- > JW> - parrot executable > JW> - imcc executable > JW> - The docs directory > JW> - The examples directory > JW> - The languages directory > JW> If you want regular (weekly? bi-weekly?) builds on Win32 zipping up and > JW> FTPing somewhere, I can do that for you. > > well, I am not sure, what the due content should be, but it would be > really good, and not just for me! If others agree and let me know what should go in there, I'll do my best to work something out. :-) However, Brent said "If you mean precompiled binaries, not yet. Parrot is still under development, so we aren't shipping binaries.", so I'm guessing maybe I shouldn't do a ZIP with the executables in? But in that case I guess there's no point me doing anything like that at all, as people can just get the latest CVS snapshot and Configure, n?make, etc. > Guys, sitting at Perl you do a great > work for all dynamic languages. If you could make your first pages on > web more comprehensive for other non-PERLers then you could obtain > some help from outside I guess. I think I heard something a while back to the effect that the parrot site was being updated sometime soon, but I'm not sure. > JW> FYI, current test status on Win32:- > > ?! > > under cygwin? > > JW> Don't know if this is supposed to happen (I don't recall seeing it before), > JW> but I'm seeing this many times during the nmake proccess:- > JW> Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > JW> Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > JW> cd classes && NMAKE && cd .. > > or using cl.exe/MSVC ? Using nmake/cl, etc. Not cygwin, I haven't tried it in that, though I *think* someone mentioned having parrot running successfully under cygwin on the list at some point. > "nmake" sounds quite strange with ultimate goal of portability, but > anyway. AFAIK, the makefiles that are generated from Configure can (theoretically) work with nmake or whatever make program you have on the target platform, so I don't see a portability problem. I may be completely wrong though! Jonathan
Re: parrot, win32, stand-alone distribution, separate Parrot maillist
"Jonathan Worthington" <[EMAIL PROTECTED]> writes: > work something out. :-) However, Brent said "If you mean > precompiled binaries, not yet. Parrot is still under development, > so we aren't shipping binaries.", This doesn't make sense to me. People who don't like hacking C can still use a precompiled binary to hack in PASM or IMC. Heck, most of the languages in languages/* are written in Perl -- no whatsoever to configure and compile. /s
Re: Re[2]: parrot, win32, stand-alone distribution, separate Parrot maillist
At 11:37 PM 8/4/2003 -0400, Brent Dax wrote: Jonathan Worthington: > work something out. :-) However, Brent said "If you mean precompiled > binaries, not yet. Parrot is still under development, so we aren't shipping > binaries.", so I'm guessing maybe I shouldn't do a ZIP with the executables > in? But in that case I guess there's no point me doing anything like that I wasn't saying "we shouldn't do it", I was saying that "at this point in the development cycle we aren't doing it." I have neither the authority nor the knowledge to set that kind of policy. Translation: if Dan doesn't say otherwise, go ahead--it's not my call anyway. :^) Dan is usually very happy when people volunteer to do things. I would expect everyone would be happy if someone built a Win32 distro. All that would be required of it is to pass the same set of tests as the reference compile, if there is one. It doesn't have to be the "official blessed by the Parrot team build" since it is free software you can build it an call it anything you want as long as you follow the copyright, just like ActiveState. -Melvin
Re: Re[2]: parrot, win32, stand-alone distribution, separate Parrot maillist
Jonathan Worthington: > work something out. :-) However, Brent said "If you mean precompiled > binaries, not yet. Parrot is still under development, so we aren't shipping > binaries.", so I'm guessing maybe I shouldn't do a ZIP with the executables > in? But in that case I guess there's no point me doing anything like that I wasn't saying "we shouldn't do it", I was saying that "at this point in the development cycle we aren't doing it." I have neither the authority nor the knowledge to set that kind of policy. Translation: if Dan doesn't say otherwise, go ahead--it's not my call anyway. :^) (BTW, such a thing would actually help me now, while I'm away from my toolkit...) --Brent Dax <[EMAIL PROTECTED]> Perl and Parrot hacker
