Hello!
The code below is lifted from /languages/imcc/t/clash.t. I'm trying to
understand test writer's intent. Bear with me, please, while I
embarass myself:
> ##
> output_is(<<'CODE', <<'OUT', "defined");
> .sub _test
> $P1 = new PerlHash
> $I0 = def
Flaviu Turean/P6 <[EMAIL PROTECTED]> wrote:
> Hello!
[ t/syn/clash_4.imc ]
> 1. $I0 (PIR) is set to `defined $P1`;
> 2. I0 (parrot) is set to `defined P1`. If there is a bug in lifetime
> analysis, in step 1 above $P1 may mapped to P1. Similarly, $I0 may be
> mapped to I0;
No, $I0 gets mapped to
Jonathan Sillito <[EMAIL PROTECTED]> wrote:
>> We need them. Parrot calling conventions are not the only convention we
>> have. And for parrot calling conventions you have to save registers too.
> I was not suggesting that we not save registers, just that we use a context
> object to do it rather
Dan Sugalski wrote:
>
> We aren't doing refcounting. We are continuing with the current
> scheme as implemented. We're not looking to do anything to change
> that scheme except perhaps implementing a generational or continuous
> garbage collection system.
Last I checked Python used refcounting
From: Graham Barr [mailto:[EMAIL PROTECTED]
>
> I may be missing something here. But within the resources of
> an object may be other PMCs. As those PMCs will not be referenced
> from anywhere else what is to stop the DoD run from freeing those
> before it freed the object ?
Putting my head out o
At 9:56 AM -0500 6/4/03, Garrett Goebel wrote:
Dan Sugalski wrote:
We aren't doing refcounting. We are continuing with the current
scheme as implemented. We're not looking to do anything to change
that scheme except perhaps implementing a generational or continuous
garbage collection system.
La
At 10:01 AM -0500 6/4/03, Garrett Goebel wrote:
From: Graham Barr [mailto:[EMAIL PROTECTED]
I may be missing something here. But within the resources of
an object may be other PMCs. As those PMCs will not be referenced
from anywhere else what is to stop the DoD run from freeing those
before it
Hey, thanks for the comments.
So you suggest leaving as the op as invoke? I don't mind, I just think we
should be consistent in our naming; what about having the following four
ops:
- invoke
- invokecc
- invoke_method
- invokecc_method
You also wondered about the need for the 'cc' varian
Matt Fowles wrote:
>
> Benjamin Goldberg wrote:
> >>For more complex cases timely destruction will not be assured.
> >
> > Which is not-so-good. We'd like timely destruction *always*
> >
> > However, given that your suggestion can be implemented purely
> > through compile time behaviors, there'
Jonathan Sillito wrote:
[snip]
> -inline op invoke(in PMC) {
+inline op call(in PMC) {
>opcode_t *dest;
> - PMC * p = $1;
> -
> - dest = (opcode_t *)p->vtable->invoke(interpreter, p, expr NEXT());
> -
> + PMC * sub = $1;
> + dest = (opcode_t *)p->vtable->invoke(interpreter, sub, expr NEXT()
Jonathan Sillito wrote:
[snip]
> -inline op invoke(in PMC) {
+inline op call(in PMC) {
>opcode_t *dest;
> - PMC * p = $1;
> -
> - dest = (opcode_t *)p->vtable->invoke(interpreter, p, expr NEXT());
> -
> + PMC * sub = $1;
> + dest = (opcode_t *)p->vtable->invoke(interpreter, sub, expr NEXT()
This message was cancelled from within Mozilla.
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> There's no reason why the other scheme (whatever it is) can't be either
> frequent DoD runs or my hybrid refcounting/dod scheme.
Frequent DOD runs are not a problem for an average program (for some
definition of average). But when we come to ~1 milli
Jonathan Sillito <[EMAIL PROTECTED]> wrote:
> this is just the "current continuation". In pasm this could be:
> new P1, .Continuation
> set_addr I3, returnhere
> set P1, I3
> invoke # or invoke_method
> returnhere:
> # etc ...
> With a 'cc' variant the common case is simp
14 matches
Mail list logo
