At 12:53 PM +0200 6/9/02, Jerome Vouillon wrote:
>On Sat, Jun 08, 2002 at 03:54:06PM -0400, Melvin Smith wrote:
>The Java bytecode interpreter is clearly not optimized for speed.
>David Gregg, Anton Ertl and Andreas Krall have experimented with an
>improved Java bytecode interpreter. One of the
At 11:00 AM +0200 6/9/02, Jerome Vouillon wrote:
>On Sat, Jun 08, 2002 at 02:39:33PM -0400, Dan Sugalski wrote:
>> >Instead of using some space on the stack, co-routines can store all
>> >their local variables into their closure. Then, there is no need to
>> >swap in any context.
>>
>> You st
At 03:49 PM 6/9/2002 +0200, Jerome Vouillon wrote:
Thanks for the links and references, Jerome. I'll have a go
at digesting these. As soon as the new neural pathways
have formed I'll try to comment on where I can see us
improving our implementation. :)
-Melvin
On Sat, Jun 08, 2002 at 02:29:53PM -0400, Dan Sugalski wrote:
> There's more than just exception handlers going on the control stack.
> Anything that needs rolling back or undoing (like localized variables
> or scope entry) will have an undo marker put on the control stack
> that gets called wh
On Sat, Jun 08, 2002 at 03:54:06PM -0400, Melvin Smith wrote:
> At 02:36 PM 6/8/2002 -0400, Dan Sugalski wrote:
> >At 8:15 PM +0200 6/8/02, Jerome Vouillon wrote:
> >>On Sat, Jun 08, 2002 at 12:30:36PM -0400, Melvin Smith wrote:
> >>> The Java VM does this by popping values off of the local stack,
On Sat, Jun 08, 2002 at 02:39:33PM -0400, Dan Sugalski wrote:
> >Instead of using some space on the stack, co-routines can store all
> >their local variables into their closure. Then, there is no need to
> >swap in any context.
>
> You still need to store the stack frames created since the start
On Sat, Jun 08, 2002 at 03:35:39PM -0400, Melvin Smith wrote:
> At 08:30 PM 6/8/2002 +0200, Jerome Vouillon wrote:
> >Instead of using some space on the stack, co-routines can store all
> >their local variables into their closure. Then, there is no need to
> >swap in any context.
>
> We have to
At 08:30 PM 6/8/2002 +0200, Jerome Vouillon wrote:
>On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
> > The support isn't complete, for example, co-routines, etc. need to
> > swap in their own context, which right now they don't do.
>
>Instead of using some space on the stack, co-rou
At 02:36 PM 6/8/2002 -0400, Dan Sugalski wrote:
>At 8:15 PM +0200 6/8/02, Jerome Vouillon wrote:
>>On Sat, Jun 08, 2002 at 12:30:36PM -0400, Melvin Smith wrote:
>>> The Java VM does this by popping values off of the local stack, and
>>> onto the callee's stack upon return.
>>
>>I think this is a
At 03:48 PM 6/8/2002 -0400, Dan Sugalski wrote:
>At 3:35 PM -0400 6/8/02, Melvin Smith wrote:
>At more risk of admitting more of my ignorance...
>>
>>We have to store the closure's variables somewhere, if not on a stack, where?
>
>In scratchpads. The way perl 5 does it is that every subroutine has
At 3:35 PM -0400 6/8/02, Melvin Smith wrote:
>At 08:30 PM 6/8/2002 +0200, Jerome Vouillon wrote:
>>On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
>>> The support isn't complete, for example, co-routines, etc. need to
>>> swap in their own context, which right now they don't do.
>>
At 08:30 PM 6/8/2002 +0200, Jerome Vouillon wrote:
>On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
> > The support isn't complete, for example, co-routines, etc. need to
> > swap in their own context, which right now they don't do.
>
>Instead of using some space on the stack, co-rou
At 08:27 PM 6/8/2002 +0200, Jerome Vouillon wrote:
>On Sat, Jun 08, 2002 at 12:20:55PM -0400, Melvin Smith wrote:
> > What would that accomplish?
> >
> > If yield is to suspend the current coroutine and return back to the
> > controlling context, you don't need an argument to yield, unless you
> >
At 08:15 PM 6/8/2002 +0200, Jerome Vouillon wrote:
>I think this is a design mistake of the Java VM. It would have been
>more efficient to keep the local variables on the stack.
Define efficient. I assume they made their choices for more than one
reason, and I'd hesitate to call it a design mist
At 8:30 PM +0200 6/8/02, Jerome Vouillon wrote:
>On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
>> The support isn't complete, for example, co-routines, etc. need to
>> swap in their own context, which right now they don't do.
>
>Instead of using some space on the stack, co-routin
At 8:15 PM +0200 6/8/02, Jerome Vouillon wrote:
>On Sat, Jun 08, 2002 at 12:30:36PM -0400, Melvin Smith wrote:
>> Right now all it [ret] does is pop the return address from the global
>> interpreter control stack, but continuations, etc. will have their own
>> control stack, so they must restor
At 9:50 AM +0200 6/8/02, Jerome Vouillon wrote:
>On Sat, Jun 08, 2002 at 01:15:48AM -0400, Dan Sugalski wrote:
>> First, we need to beef up ret, but that's a problem of definition. It
>> should walk the control stack until it hits something it can return,
>> so we can undo exception handler pus
On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
> The support isn't complete, for example, co-routines, etc. need to
> swap in their own context, which right now they don't do.
Instead of using some space on the stack, co-routines can store all
their local variables into their closu
On Sat, Jun 08, 2002 at 12:20:55PM -0400, Melvin Smith wrote:
> At 09:50 AM 6/8/2002 +0200, Jerome Vouillon wrote:
> >Alternatively, I think you can just replace the definition of yield
> >by:
> >
> >inline op yield (in INT) {
> > struct Parrot_Sub * sub =
> >(struct Parrot_Sub*)i
On Sat, Jun 08, 2002 at 12:30:36PM -0400, Melvin Smith wrote:
> Right now all it [ret] does is pop the return address from the global
> interpreter control stack, but continuations, etc. will have their own
> control stack, so they must restore the caller's before returning.
Continuations never r
At 09:50 AM 6/8/2002 +0200, Jerome Vouillon wrote:
>On Sat, Jun 08, 2002 at 01:15:48AM -0400, Dan Sugalski wrote:
> > First, we need to beef up ret, but that's a problem of definition. It
>
>Why does ret need to be so smart? We can have an opcode that pop
>exception handlers (we need it anyway) a
At 09:50 AM 6/8/2002 +0200, Jerome Vouillon wrote:
>Alternatively, I think you can just replace the definition of yield
>by:
>
> inline op yield (in INT) {
> struct Parrot_Sub * sub =
> (struct Parrot_Sub*)interpreter->pmc_reg.registers[0]->data;
> sub->init = OFFSET($1);
>
On Sat, Jun 08, 2002 at 01:15:48AM -0400, Dan Sugalski wrote:
> First, we need to beef up ret, but that's a problem of definition. It
> should walk the control stack until it hits something it can return,
> so we can undo exception handler pushes, scope change, and suchlike
> things. (My proble
At 7:40 PM -0400 6/7/02, Melvin Smith wrote:
>I just did a bunch of commits, people might need a fresh checkout.
>
>Its a start for subroutines and co-routines. The keyword is 'start',
>not final product. The ops are call/callco, but these will become
>vtable entries for the 4 aforementioned sub t
At 07:40 PM 6/7/2002 -0400, Melvin Smith wrote:
># Sample sub-routines in Parrot
>#
># Create 2 subroutines
>#
>set_addr I0, SUB
>new P0, .ParrotSub, I0
>save P0
>new P0, .ParrotSub, I0
># Calling convention says P0 will contain the sub
>call
>restore P0
># Call second one
>call
>end
>
># A subrou
I just did a bunch of commits, people might need a fresh checkout.
Its a start for subroutines and co-routines. The keyword is 'start',
not final product. The ops are call/callco, but these will become
vtable entries for the 4 aforementioned sub types by Dan.
David has some pending patches for PM
26 matches
Mail list logo
