On 11/30/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
>
> What you're missing is that without the :outer information, Parrot
> wouldn't be able to decide *which* LexPads *should* be searched,
> either now (find_lex w/o LexEnv) or later (newclosure -> LexEnv).
Right and I see that this is consist
On 11/30/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 30, 2005 at 12:02:08PM -0800, Jonathan Sillito wrote:
> > I have some clarification questions about the new pdd20
>
> > 1. What is expected to be in P0 in:
> >.lex "$a", P0
>
>
I have some clarification questions about the new pdd20 on lexical
variables -- likely stemming from my having been out of it for so
long. Also I am happy to send a patch to pdd20 capturing these
clarifications once I am sure I understand things correctly.
1. What is expected to be in P0 in:
.
On 11/29/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> I've reviewed pdd03 and brought it back from pdds/clip.
Thanks for reviving this document Chip. Way back when I implemented
some of the original lexical and calling code (like the scratchpad --
may it rest in peace). What is the status of t
continuations and coroutines. The
above suggests that we could merge those together and just have the pmc
versions.
--
Jonathan Sillito
context which is saved on construction and restored on invoke. The different
types the context to be saved and restored[1]:
sublite[2]:
none - just address
sub:
pointer to a lex pad
coroutine:
whole Parrot_Context[3] - i.e same as ...
continuation for cps approach:
whole P
> -Original Message-
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
>
> Jonathan Sillito wrote:
>
> >>-Original Message-
> >>From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
> >>
> >>The patch is fine with two exceptions:
&g
> -Original Message-
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
>
> The patch is fine with two exceptions:
> 1) still breaks existing P6C tests WRT exceptions & rules
> 2) performance of CPS sucks
>
> ad 1) I'd like to preserve the old style invoke/ret scheme too. incokecc
> and frie
verything. If a sub uses only one or two
registers it only needs to save those before calling another sub ... right?
--
Jonathan Sillito
truct.
Jonathan Sillito
> -Original Message-
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]
> Sent: June 12, 2003 4:11 PM
> To: Luke Palmer
> Cc: [EMAIL PROTECTED]
> Subject: Re: Context, continuations, and call speed
>
>
> At 5:01 PM -0600 6/12/03, Luke Palmer wro
On Wed, 11 Jun 2003, Leopold Toetsch wrote:
> Jonathan Sillito wrote:
>
> Why not just leave the old behaviour?
> IMHO[1]:
> - Make a new class based on Continuations
> - invokecc and such are based on it
[snip]
> [1] I don't know too much about all the HL stuff. But
> -Original Message-
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
>
> Jonathan Sillito <[EMAIL PROTECTED]> wrote:
>
> > This patch converts parrot to a continuation passing style.
>
> You seem to be changing current tests WRT invoke - does invok
tacks
c. opcode, stacks and half of the registers
d. opcode, stacks and all of the registers
The patch I sent supports two types: type b (in continuation.pmc) and type d
(in completecontext.pmc). Also in this patch is the option to not create a
new continuation --as in a tail call-- which of course makes it very fast.
--
Jonathan Sillito
t
object to do it rather than the stacks. I suppose there would be not much
benefit to this anyway ...
Jonathan Sillito
to comment on my idea for getting rid of
the register stacks etc:
"calling convention and continuation ramblings"
http://xrl.us/iy8
Jonathan Sillito
> -Original Message-
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
>
> Jonathan Sillito <[EMAIL PROTEC
, control and int stacks.
This seems like a nice approach to me as it simplifies the Parrot_Context
struct and the calling and returning from subs and methods.
Comments?
--
Jonathan Sillito
table->invoke(interpreter, method, expr
NEXT());
goto ADDRESS(dest);
}
--
Jonathan Sillito
> -Original Message-
> From: Nicholas Clark [mailto:[EMAIL PROTECTED] Behalf Of Nicholas
> Clark
>
> I'm not sure if I'm asking a stupid question here, but:
>
> On
callccmethod?)
Also, should the current 'invoke' op be changed to 'call'? I don't care
exactly what the names are, but consistency is nice.
Jonathan
> -Original Message-
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]
>
> At 9:20 AM -0700 5/30/03, Jonathan Silli
Dan,
Why is there a callmeth op? Can't we just use a regular invoke as with other
subs? Or does the callmeth op do both a find and invoke as an optimization?
Jonathan Sillito
> -Original Message-
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]
>
> Nope, not objects,
outines and the caller
> + all edges out from both do share the same registers, don't they?
They do, except that each coroutine has its own user stack so saveall and
restoreall can work properly.
-- jonathan sillito
> -Original Message-
> From: Kevin Reid [mailto:[EMAIL PROTECTED]]
>
> 0. PDD 3 says:
>
> P1
>Holds the continuation for the caller, assuming this sub was
> called with callcc. Otherwise NULL.
>
>and implies a similar possible absence for P2. How does one ensure
> that
> -Original Message-
> From: Andy Wardley [mailto:[EMAIL PROTECTED]]On Behalf Of Andy Wardley
>
> Dan Sugalski wrote much sense, including these gems:
> > *) Method: Some sort of action that an object can do. Methods are
> > global and public--only one foo method for an object. Methods ma
Sounds like we want objects *and* classes to support:
static_attribs - which are defined at compile time and
accessed by offset probably stored in an array.
dynamic_attribs - which come and go at run time and are
generally accessed by name and likely stored in a hash.
--
Jonathan Sillito
): A.f() !!!
Which shows that the dispatch (i.e. selecting which method to call) can
happen before the invocation.
--
Jonathan Sillito
> -Original Message-
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> At 8:53 PM -0800 1/14/03, Adriano wrote:
> >On Tue, 14 Ja
these slots? Also
> Can I access
> >slots like:
> >
> > set Px, Py[1]# store the name to offset hash in Px
>
> No the parent's gotten to via the vtable, and yes you can.
Sorry if this is obvious, but which vtable method is used to get the
parents?
Thanks!
--
Jonathan Sillito
ccess
slots like:
set Px, Py[1]# store the name to offset hash in Px
[snip]
So to sum up we need the following pmc's:
pmclass Ref {
data is a pointer to an object
}
pmclass Attr {
data is an array of attributes
}
pmclass Class extends Attr {
}
pmclass Object {
this was not explained, but I guess it at least
has a reference to a Class and field data ???
}
Does that cover it?
--
Jonathan Sillito
uches:
-- classes/scratchpad.pmc
-- sub.c
-- t/pmc/scratchpad.t (adds a test)
--
Jonathan Sillito
> -Original Message-
> From: Jonathan Sillito [mailto:[EMAIL PROTECTED]]
>
> > -Original Message-
> > From: Leopold Toetsch [mailto:[EMAIL PROTECTED]]
> >
> >
aks, because we can't cleanup duplicated lex ptrs.
>
> Can somone better knowing scratchpads comment on this please.
>
I guess there is a related problem with the way the function scratchpad new
works, since it needs to copy lex ptrs from enclosing scopes?
I will look into it more in a bit ...
--
Jonathan Sillito
document docs/parrot_assembly.pod is out of date, and it seems a shame
to keep a simple doc for each op in two places ... so I am not sure about
this doc.
(Would someone like to put the attached file into examples/assembly and
commit it? Also could someone look at the patch in #18419?)
--
Jonathan
CVS
and try again on Darwin/PPC? As much detail as you can send me about any
failures would be appreciated.
Thanks.
--
Jonathan Sillito
Steve,
Thanks! Was there a problem applying the patch? I just checked out a new cvs
images and the file t/op/lexicals.t has not been updated. As a result, a few
tests are failing. Should I resubmit the part of the patch that updates
t/op/lexicals.t?
--
Jonathan Sillito
> -Original Mess
ub would only need
an explicit pop_pad for each local scope created.
However, subs that are not closures could continue using the ret op.
(So Dan, should I submit a patch adding a 'return' op?).
--
Jonathan Sillito
r your question?
> Apart from that: Nice patch.
>
--
Jonathan Sillito
) only touched in sub.c, so it should be easy to change the
approach.
Thanks for the comments, anything else?
--
Jonathan Sillito
ot hacking, could someone point me
> at the rationale for making scratchpads a special case, rather than a
> PMC?
I am sure they will be a PMC. In fact two different patches have been
submitted to make them PMCs, one by me and a better one by Sean O'Rourke.
Sean's has not been committed yet, probably because he is waiting for a
decision on the more flexible ops by Dan.
--
Jonathan Sillito
utine:
print "in sub routine\n"
ret
This seems tedious, but maybe I am missing the point? Anyway if this is what
we want the attached patch modifies sub.pmc to support this, and adds a test
to t/pmc/sub.t. This patch depends on [perl #17811].
--
Jonathan Sillito
sub_init.patch
Description: Binary data
ome things could be left
to _methods_ instead of ops.
--
Jonathan Sillito
>
> The primary goal of the exercise was to be able to distinguish
> between 'set P0, P1' which simply sets the P0 register equal to
> the P1 register, and 'assign P0, P1' which would,
So does that mean, the only set ops will be those that take two registers of
the same type?
set_p_p
set_i_i
set_s_s
set_n_n
--
Jonathan Sillito
(who is willing to help with the migration)
> -Original Message-
> From: Peter Gibbs [mailto:[EMAIL PROTECTED]]
> Sent: October 3, 2
new P0, .SchemeUndef
store_lex 1, "a", P0
# ...
pop_pad
and could (set! a 12) inside of the above define be:
new P0, .SchemeInteger
store_lex "a", P0 # looks back through nested pads
--
Jonathan Sillito
> -Original Message-
> From: Piers Cawley [mailto:[EMAIL PROTECTED]]
> "Jonathan Sillito" <[EMAIL PROTECTED]> writes:
> > get_counter:
> > new_pad 1
>
> Doesn't this violate the 'caller saves' principle, making it hard to
&g
descriptor that could be used to put all
lexicals in place when the pad is first created.
> Is there a possibility to get a pointer to the current pad, to store
> it in the closure? (Im not sure, maybe only the top-pad is needed).
> There need also be a way to reinstate the saved lexica
Sorry if this comment is out of context, I am behind but catching
up. The patch in [perl #16797] adds a scratchpad pmc (among other
things). Hopefully it is not too far out of date to apply. I
believe Melvin is looking into it ...
--
Jonathan Sillito
On Tue, 10 Sep 2002, Piers Cawley wrote
or up in the air still (my
patch in [perl #16797] for example). But I am hoping to somehow get more
involved.
Also, for what it is worth, I personally don't much care what the email
list is called.
--
Jonathan Sillito
at is not a question just some random thought.
4) Parrot_Coroutine's 'init' is not longer used and can go away, I guess
I could remove it in a future patch ... ok so that's not a question
either.
Anyway, thanks for any info!
--
Jonathan Sillito
On Thu, 2002-08-08 at 14:29, Jona
hour ago.
???
---
Jonathan Sillito
On Mon, 2002-08-12 at 01:56, Mike Lambert wrote:
> Hey,
>
> I re-added the GC_DEBUG define today, and weeded out a bunch of issues.
> For those who don't remember, GC_DEBUG (currently in parrot.h) causes
> various limits and settings and lo
On Tue, 2002-08-06 at 20:11, Sean O'Rourke wrote:
> On Tue, 6 Aug 2002, Dan Sugalski wrote:
>
> > At 12:57 PM -0600 8/6/02, Jonathan Sillito wrote:
> > >Can a prototyped sub take a variable number of parameters (ie can it
> > >have 'rest' params?). I
hen to access a
lexical by name involves a sequential search through the (probably not
large) array of names, to get the index, then the index is used to get
the lexical from the other array.
Or would that make access by name too slow?
--
Jonathan Sillito
On Wed, 2002-07-31 at 13:49, Jerome Vouillon wrote:
> On Wed, Jul 31, 2002 at 11:40:39AM -0600, Jonathan Sillito wrote:
> > new_pad # push this on the lexical stack
> > # some constant descriptor should also be passed
> > # to the new_pad op
cope
find_lex P1, "x" # again probably by index not name
# after this P1 holds the int pmc
# print
ret
Does that make sense?
--
Jonathan Sillito
ix it.
Thanks again.
--
Jonathan Sillito
On Tue, 2002-07-30 at 10:47, Melvin Smith wrote:
> See my 2 comments:
>
> > new P0, .PerlInt
> > new P1, .PerlInt
> > new P2, .PerlInt
> > new P3, .PerlInt
> > set P0, 10
> > set P1, 11
> > set P2, 12
>
On Mon, 2002-07-29 at 17:12, Simon Glover wrote:
> I think you forgot to attach the patch...
oops, now the files are attached ...
- patch: lex.patch
- test file: lexicals.t
- example file: lexicals.pasm
On Tue, 2002-07-30 at 02:14, Stephen Rawls wrote:
> --- Jonathan S
:
interpreter->ctx.current_scope = SELF->scope;
What do you think? Is there something I am misunderstanding about how
closures work?
> On this line, we need to discuss the symbol table format for
> the bytecode. I played around a bit but nothing I wish to commit.
I haven't given this any thought yet ...
--
Jonathan Sillito
han this offset, should refer to
a variable in an enclosing scope) */
INTVAL offset;
/* number of pointers in data */
INTVAL size;
} * scratchpad_t;
Thanks, for any help/feedback!
--
Jonathan Sillito
nvoke op.
Next on my list is (next 24 hours or so):
1) remove old call and callco ops (invoke takes care of both) from
core.ops
2) change examples/assembly/sub.pasm and coroutine.pasm to use invoke
instead of call and callco
3) add some tests
After that I will look into adding a C
uld be appreciated.)
--
Jonathan Sillito
Index: examples/assembly/sub.pasm
===
RCS file: /cvs/public/parrot/examples/assembly/sub.pasm,v
retrieving revision 1.2
diff -u -r1.2 sub.pasm
--- examples/assembly/sub.pasm 7 Jun 2002
s the next
op for the interpreter (in core.ops):
goto ADDRESS(sub->init); /* always 0 */
Is there a different pasm syntax I should be using for creating and
calling subs? I seem to remember some discussion about changing how
things are passed to constructors but I am not sure what the conclusion
was.
--
Jonathan Sillito
56 matches
Mail list logo
