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.
># >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.
># >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.
># >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).
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
