On Tuesday 11 September 2001 12:41 pm, Ken Fox wrote:
> I'm not sure I understand what you mean. Perl 5 allows us to enter
> and leave scopes with goto:
Perl 5 allows you to leave most scopes (sort being the only exception), but
just over half the constructs that introduce scope allow you to ent
At 12:41 PM 9/11/2001 -0400, Ken Fox wrote:
>And of course the keywords last, next and redo are just restricted
>gotos. Those are able to leave one or more scopes.
Leaving scopes is easy. You just walk up the stack and deconstruct things.
(Or, in this case, potentially run the end-of-scope code
"Bryan C. Warnock" wrote:
> On Monday 10 September 2001 09:30 pm, Dan Sugalski wrote:
> > gotos into scopes might not be allowed.
>
> That's how it currently is for most scopes, and it certainly saves a
> whole lot of trouble and inconsistencies.
I'm not sure I understand what you mean. Perl 5 a
On Monday 10 September 2001 09:30 pm, Dan Sugalski wrote:
> >What happens with:
> >
> >goto FOO; { bar { FOO: foo } blah }
> >
> >Is goto responsible for figuring out it has entered bar's
> >scope and setting the VM state so that the exitscopes are
> >properly balanced?
>
> I'm not sure what w
At 09:26 PM 9/10/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> >jump FOO
> >
> > doesn't change scope.
> >
> >newscope scope_template_in_fixup_section
> >
> > does. And
> >
> >exitscope
> >
> > leaves one. :)
>
>Ok. That clears it up a little. The current scope is part of
>the VM i
At 09:01 PM 9/10/2001 -0400, Bryan C. Warnock wrote:
>On Monday 10 September 2001 09:00 pm, Dan Sugalski wrote:
> > >But how does the interpreter know where a lexical scope begins
> > >and ends in the bytecode? For example, a "jump FOO" might change
> > >scopes. How is the scope discovered?
> >
>
Dan Sugalski wrote:
>jump FOO
>
> doesn't change scope.
>
>newscope scope_template_in_fixup_section
>
> does. And
>
>exitscope
>
> leaves one. :)
Ok. That clears it up a little. The current scope is part of
the VM internal state and compilers need to generate state
change instruc
On Monday 10 September 2001 09:00 pm, Dan Sugalski wrote:
> >But how does the interpreter know where a lexical scope begins
> >and ends in the bytecode? For example, a "jump FOO" might change
> >scopes. How is the scope discovered?
>
>jump FOO
>
> doesn't change scope.
Is that a "doesn't" or
At 09:05 PM 9/10/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 05:41 PM 9/10/2001 -0400, Ken Fox wrote:
> > > You're expecting the current lexical scope to be carried implicitly
> > > via the PC?
> >
> > No, it'll be in the interpreter struct.
>
>But how does the interpreter know where a
Dan Sugalski wrote:
> At 05:41 PM 9/10/2001 -0400, Ken Fox wrote:
> > You're expecting the current lexical scope to be carried implicitly
> > via the PC?
>
> No, it'll be in the interpreter struct.
But how does the interpreter know where a lexical scope begins
and ends in the bytecode? For examp
At 05:41 PM 9/10/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > =item if tx, X, Y
>
>What's the purpose of providing Y? Does it make anything easier
>allowing Y != 0?
Hmmm. No, it doesn't, it just bloats out the opcode stream by an IV. I'll
fix that.
> > =item jump tx
>
>I expected a "call
Dan Sugalski wrote:
> =item if tx, X, Y
What's the purpose of providing Y? Does it make anything easier
allowing Y != 0?
> =item jump tx
I expected a "call" op too. Not a named sub call, but just "call
tx" where tx has the same semantics as in "jump".
A "return" op is needed too.
> =item iton
At 10:09 PM 9/9/2001 +0100, Simon Cozens wrote:
>On Fri, Sep 07, 2001 at 04:30:56PM -0400, Dan Sugalski wrote:
> > =item find_method Px, Py, tz
>
>Using what kind of dispatch mechanism? Or is that what the t is for?
That bit needs to change because of some of the stuff I've been digging
into. Ba
On Fri, Sep 07, 2001 at 04:30:56PM -0400, Dan Sugalski wrote:
> =item find_method Px, Py, tz
Using what kind of dispatch mechanism? Or is that what the t is for?
Simon
On Friday 07 September 2001 07:21 pm, Matthew Cline wrote:
> On Friday 07 September 2001 01:30 pm, Dan Sugalski wrote:
> > In all cases, the letters x, y, and z refer to register numbers. The
> > letter t refers to a generic register (P, S, I, or N). A lowercase p,
> > s, i, or n means either a re
On Friday 07 September 2001 01:30 pm, Dan Sugalski wrote:
> In all cases, the letters x, y, and z refer to register numbers. The
> letter t refers to a generic register (P, S, I, or N). A lowercase p,
> s, i, or n means either a register or constant of the appropriate type
> (PMC, string, integer
Here's the assembly PDD. Changes to it to come, of course.
---Cut Here--
=head1 TITLE
Parrot assembly language
=head1 VERSION
=head2 CURRENT
Maintainer: Dan Sugalski
Class: Internals
PDD Number: 6
Version: 1.2
Status: Developin
17 matches
Mail list logo
