Dan Sugalski:
# At 12:39 AM 11/9/2001 -0500, Ken Fox wrote:
# >There are a number of decisions to make about lexicals
# >and the current PDD is pretty slim. So, IMHO, the place
# >to start is with the PDD. Anybody have any more thoughts
# >on the interface? Dan? Is this stone tablet stuff yet?
#
# Nope, not stone tablet at all. More a sketch than anything
# else, since I'm
# not sure yet of all the things Larry's got in store.
#
# How we're handling MY variables is the big iffy thing. I'm
# not sure at the
# moment whether we're going to need some sort of wacky
# trampoline scheme or not.
#
# >The big five questions on my list are:
# >
# >1. The find_lex/fetch_lex ops push a lot of work into the
# > run-time when the compiler can figure out what frame a
# > lexical appears in.
# >
# > Should there be an alternative, faster interface to
# > lexicals that eliminates string lookups?
#
# You'll be able to fetch things out of hashes by index number, and the
# lexical fetcher will handle this. So you only need to figure
# out the index
# number once (potentially at compile time) and then fetch by
# number after that.
#
# >The symbolic
# > interface is required to support %MY and debugging, so
# > it stays regardless of whether other interfaces exist.
# >
# >2. Perl 5 doesn't support nested subs, but I haven't read
# > anything about Perl 6 and I don't know if other
# > targets for Parrot support them either.
# >
# > Do we want to support nested subs? Efficiently?
#
# When you say nested subs, do you mean lexical subs? If so,
# then yes. (If
# not, then probably anyway. :)
#
# >3. We've adopted a register machine architecture to
# > reduce push/pop stack traffic. Register save/load
# > traffic is similar, but not nearly as bad.
# >
# > Do we want to further reduce memory moves by allowing
# > ops to work directly on lexicals?
#
# No, I don't think so--that's what the registers are for.
# Fetch out the PMC
# pointer into a PMC register and just go from there. Any
# changes made via
# the pointer will, of course, be reflected in the lexical, since we're
# working on the real thing.
Here's a thought--do we want to have variants on every PMC op to support
a key? IIRC, assembly.pod proposes something like:
fetchlex P1, "%foo"
add P3, P1, "key", 1
Why not just have:
fetchlex P1, "%foo" #or whatever
fetchhash P2, P1, "key"
add P3, P2, 1
and save ourselves a few opcode numbers?
# >4. There has been discussion about how useful non-PMC
# > registers will be to the Perl compiler. If there are
# > questions there, surely non-PMC lexicals would be even
# > less useful to Perl.
# >
# > Do we want non-PMC lexical support?
#
# Nope, I wasn't going to bother. All variables are PMCs. The
# int/string/num
# things are for internal speed hacks.
You may want to bounce that off the -language people--they seem to be
expecting that 'my int $foo' will only take up a pad entry and an
int-sized chunk of memory.
# >5. Perl 5 uses pads and scratchpads for holding lexicals.
# >
# > Do we want to consider other implementations such as
# > traditional stack frames with a display or static
# > link?
#
# Well, I don't think we can go with traditional stack frames
# as such, since
# the individual frames (and their children) may need to stick
# around for
# ages, courtesy of closures and suchlike things. (We almost
# end up with a
# linked list of stacks when you factor recursion in)
With closures, don't we just clone the PMC pointer and pad entry, thus
avoiding having to keep stack frames around until the end of time? Or
am I missing something?
# How it gets handled depends to some extent on the
# requirements that Larry
# puts on lexicals.
#
# >If there aren't any obvious answers, I propose that we
# >implement a couple different approaches and objectively
# >compare them.
#
# Works for me.
#
# >Lexical implementation is as critical to
# >Perl's performance as the dispatcher is, so we should
# >take some time to get it right.
#
# I'm not sure it's as performance critical, but it's
# definitely important.
# Fast is, of course, good. :)
Of course. Random question only very tangentially related to this: is
INTVAL (and thus the I registers) supposed to be big enough to hold a
pointer?
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take action, I'm not going to fire a $2 million missile at a $10
empty tent and hit a camel in the butt.
--Dubya
