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
On Fri, Jun 07, 2002 at 01:50:27AM -0400, Dan Sugalski wrote:
> So, in total, we need:
>
> *) Original routine entry point
> *) Current routine entry point
> *) Native/bytecode flag
> *) Opcode table
> *) Global namespace chain
> *) "default" lexical scope
> *) All the register sets
> *) All the
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);
>
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
On Fri, Jun 07, 2002 at 11:23:56PM -0400, Dan Sugalski wrote:
> 2) A revamped stack system so we can support exceptions
What is the intent for stacks ?
--
Jason
At 12:55 AM -0400 6/8/02, Josh Wilmes wrote:
>
>Although I should mention that it's not verifying the presence of these
>headers- it just assumes they are available. It does that because the
>intent is to use this has_header.h for miniparrot, where we won't be doing
>any probing. The assumption
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
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 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
At 10:40 AM +0200 6/8/02, Jerome Vouillon wrote:
>On Fri, Jun 07, 2002 at 01:50:27AM -0400, Dan Sugalski wrote:
>> So, in total, we need:
>>
>> *) Original routine entry point
>> *) Current routine entry point
>> *) Native/bytecode flag
>> *) Opcode table
>> *) Global namespace chain
>> *)
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
At 1:43 PM -0400 6/8/02, Jason Gloudon wrote:
>On Fri, Jun 07, 2002 at 11:23:56PM -0400, Dan Sugalski wrote:
>
>> 2) A revamped stack system so we can support exceptions
>
>What is the intent for stacks ?
They need to be more formally turned to frames (though each sub may
have multiple frames),
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 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 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 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: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 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 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 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
> --- start of forwarded message ---
> Date: 7 Jun 2002 21:36:26 -
> From: Joe Yates (via RT) <[EMAIL PROTECTED]>
> Cc: recipient list not shown: ;
> Subject: Re: [netlabs #590] Ticket Resolved
> Message-Id:
>
> Dear Daniel,
>
> I hope I'm not being a pain. The response to my report
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
On Sat, Jun 08, 2002 at 01:39:56PM -0400, Dan Sugalski wrote:
> At 12:55 AM -0400 6/8/02, Josh Wilmes wrote:
> >
> >Although I should mention that it's not verifying the presence of these
> >headers- it just assumes they are available. It does that because the
> >intent is to use this has_header.
Nicholas Clark:
# On Sat, Jun 08, 2002 at 01:39:56PM -0400, Dan Sugalski wrote:
# > At 12:55 AM -0400 6/8/02, Josh Wilmes wrote:
# > >
# > >Although I should mention that it's not verifying the presence of
# > >these
# > >headers- it just assumes they are available. It does that
# because the
#
Standard MSVC++ 6.0 setup, last known to work: Thursday. Updated with
completely clean tree, built with defaults (as I always do) and here's how
it went:
C:\projects\parrot\parrot>perl Configure.pl
Parrot Version 0.0.6 Configure 2.0
Copyright (C) 2001-2002 Yet Another Society
Hello, I'm Confi
25 matches
Mail list logo
