Dan Sugalski:
# At 01:39 PM 11/9/2001 -0800, Brent Dax wrote:
# >Dan Sugalski:
# ># At 12:39 AM 11/9/2001 -0500, Ken Fox wrote:
# ># >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:
#
# I think we're going to switch over to some sort of key
# creation op, but I'm
# not sure at the moment. Constant keys are easy, of
# course--they can be
# thrown up into the constants section, built at compile-time.
#
# > 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?
#
# Why save the numbers? Also we'll end up needing
# variable-arg-count opcodes
# for proper multidimensional fetching.
This is why:
fetchlex P1, "%foo"
fetchhash P2, P1, "key"
add P3, P2, 1
sub P4, P2, 1
#maybe a few more ops with P2 here...
You get the idea? And as for multidimensional stuff, what's wrong with:
fetchlex P1, "@lol"
fetchary P2, P1, 1
fetchary P3, P2, 2
#...
Yes, I know, some people don't like that multidimensional arrays are
internally arrays of arrays, but that doesn't necessarily need to be
obvious to the outside world, does it? Internally, the nested arrays
could have tweaked vtables to do whatever they ought to do.
# ># >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.
#
# They can think what they like, but it's not going to happen for plain
# scalars. There's not much point, really--the space savings
# comes in with
# array and hash storage. The typical program doesn't have that
# many plain
# scalars.
I do suggest you advise them of this fact.
# ># >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?
#
# Bad explanation. What I meant was we need to keep stacks of
# call frames
# around, or something of the sort. If you've got a recursive
# set of calls
# and create a closure inside them, the closure only captures
# the top-most
# version of all the variables. (Basically the current pads for
# each block)
# You still need to keep all of 'em around and available, in
# case at runtime
# something walks up them with caller and MY.
#
# We're going to keep the full pads around for closures,
# otherwise you set
# yourself up for problems with evals inside them.
Fair enough.
# ># >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?
#
# INTVAL shouldn't ever get a pointer in it. We're not going to
# be casting
# pointers to ints and back anywhere, except possibly in some of the
# deep'n'evil spots (like the memory allocator).
Can we get a PMC designed to hold a pointer to a nebulous Something?
Y'see, I still haven't given up on my idea of hashes of lexicals with
temp()orization (stop groaning--I'd just like to see if it would work
well!), and storing the HE's address into a register would be ideal for
that. Plus, it could help with global fetching:
get_global_index_if_necessary P1, "$foo"
#gets the address of the HE unless P1
# already points to the correct HE
# (determined by checking $1->key)
fetch_global_by_index P2, P1
to make multiple fetches of the same global faster.
--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
