++ed by:
ABRAXXA ADAMJS ALEXBIO ANDREFS ARJONES

117 PAUSE user(s)
93 non-PAUSE user(s).

Ricardo SIGNES

Pad Data Structures

CV's can have CvPADLIST(cv) set to point to a PADLIST. This is the CV's scratchpad, which stores lexical variables and opcode temporary and per-thread values.

For these purposes "formats" are a kind-of CV; eval""s are too (except they're not callable at will and are always thrown away after the eval"" is done executing). Require'd files are simply evals without any outer lexical scope.

XSUBs don't have CvPADLIST set - dXSTARG fetches values from PL_curpad, but that is really the callers pad (a slot of which is allocated by every entersub).

The PADLIST has a C array where pads are stored.

The 0th entry of the PADLIST is a PADNAMELIST (which is actually just an AV, but that may change) which represents the "names" or rather the "static type information" for lexicals. The individual elements of a PADNAMELIST are PADNAMEs (just SVs; but, again, that may change). Future refactorings might stop the PADNAMELIST from being stored in the PADLIST's array, so don't rely on it. See "PadlistNAMES".

The CvDEPTH'th entry of a PADLIST is a PAD (an AV) which is the stack frame at that depth of recursion into the CV. The 0th slot of a frame AV is an AV which is @_. Other entries are storage for variables and op targets.

Iterating over the PADNAMELIST iterates over all possible pad items. Pad slots that are SVs_PADTMP (targets/GVs/constants) end up having &PL_sv_undef "names" (see pad_alloc()).

Only my/our variable (SvPADMY/PADNAME_isOUR) slots get valid names. The rest are op targets/GVs/constants which are statically allocated or resolved at compile time. These don't have names by which they can be looked up from Perl code at run time through eval"" the way my/our variables can be. Since they can't be looked up by "name" but only by their index allocated at compile time (which is usually in PL_op->op_targ), wasting a name SV for them doesn't make sense.

The SVs in the names AV have their PV being the name of the variable. xlow+1..xhigh inclusive in the NV union is a range of cop_seq numbers for which the name is valid (accessed through the macros COP_SEQ_RANGE_LOW and _HIGH). During compilation, these fields may hold the special value PERL_PADSEQ_INTRO to indicate various stages:

   COP_SEQ_RANGE_LOW        _HIGH
   -----------------        -----
   PERL_PADSEQ_INTRO            0   variable not yet introduced:   { my ($x
   valid-seq#   PERL_PADSEQ_INTRO   variable in scope:             { my ($x)
   valid-seq#          valid-seq#   compilation of scope complete: { my ($x) }

For typed lexicals name SV is SVt_PVMG and SvSTASH points at the type. For our lexicals, the type is also SVt_PVMG, with the SvOURSTASH slot pointing at the stash of the associated global (so that duplicate our declarations in the same package can be detected). SvUVX is sometimes hijacked to store the generation number during compilation.

If PADNAME_OUTER (SvFAKE) is set on the name SV, then that slot in the frame AV is a REFCNT'ed reference to a lexical from "outside". In this case, the name SV does not use xlow and xhigh to store a cop_seq range, since it is in scope throughout. Instead xhigh stores some flags containing info about the real lexical (is it declared in an anon, and is it capable of being instantiated multiple times?), and for fake ANONs, xlow contains the index within the parent's pad where the lexical's value is stored, to make cloning quicker.

If the 'name' is '&' the corresponding entry in the PAD is a CV representing a possible closure. (PADNAME_OUTER and name of '&' is not a meaningful combination currently but could become so if my sub foo {} is implemented.)

Note that formats are treated as anon subs, and are cloned each time write is called (if necessary).

The flag SVs_PADSTALE is cleared on lexicals each time the my() is executed, and set on scope exit. This allows the 'Variable $x is not available' warning to be generated in evals, such as

    { my $x = 1; sub f { eval '$x'} } f();

For state vars, SVs_PADSTALE is overloaded to mean 'not yet initialised'.

During compilation, this points to the array containing the names part of the pad for the currently-compiling code.

During compilation, this points to the array containing the values part of the pad for the currently-compiling code. (At runtime a CV may have many such value arrays; at compile time just one is constructed.) At runtime, this points to the array containing the currently-relevant values for the pad for the currently-executing code.

Points directly to the body of the "PL_comppad" array. (I.e., this is PAD_ARRAY(PL_comppad).)

When PERL_MAD is enabled, this is a small no-op function that gets called at the start of each pad-related function. It can be breakpointed to track all pad operations. The parameter is a string indicating the type of pad operation being performed.

Create a new padlist, updating the global variables for the currently-compiling padlist to point to the new padlist. The following flags can be OR'ed together:

    padnew_CLONE        this pad is for a cloned CV
    padnew_SAVE         save old globals on the save stack
    padnew_SAVESUB      also save extra stuff for start of sub

Embedding Functions

Clear out all the active components of a CV. This can happen either by an explicit undef &foo, or by the reference count going to zero. In the former case, we keep the CvOUTSIDE pointer, so that any anonymous children can still follow the full lexical scope chain.

When a CV has a reference count on its slab (CvSLABBED), it is responsible for making sure it is freed. (Hence, no two CVs should ever have a reference count on the same slab.) The CV only needs to reference the slab during compilation. Once it is compiled and CvROOT attached, it has finished its job, so it can forget the slab.

Allocates a place in the currently-compiling pad (via "pad_alloc" in perlapi) and then stores a name for that entry. namesv is adopted and becomes the name entry; it must already contain the name string and be sufficiently upgraded. typestash and ourstash and the padadd_STATE flag get added to namesv. None of the other processing of "pad_add_name_pvn" in perlapi is done. Returns the offset of the allocated pad slot.

Allocates a place in the currently-compiling pad for a named lexical variable. Stores the name and other metadata in the name part of the pad, and makes preparations to manage the variable's lexical scoping. Returns the offset of the allocated pad slot.

namepv/namelen specify the variable's name, including leading sigil. If typestash is non-null, the name is for a typed lexical, and this identifies the type. If ourstash is non-null, it's a lexical reference to a package variable, and this identifies the package. The following flags can be OR'ed together:

    padadd_OUR          redundantly specifies if it's a package var
    padadd_STATE        variable will retain value persistently
    padadd_NO_DUP_CHECK skip check for lexical shadowing

Exactly like "pad_add_name_pvn", but takes a nul-terminated string instead of a string/length pair.

Exactly like "pad_add_name_pvn", but takes the name string in the form of an SV instead of a string/length pair.

Allocates a place in the currently-compiling pad, returning the offset of the allocated pad slot. No name is initially attached to the pad slot. tmptype is a set of flags indicating the kind of pad entry required, which will be set in the value SV for the allocated pad entry:

    SVs_PADMY    named lexical variable ("my", "our", "state")
    SVs_PADTMP   unnamed temporary store

optype should be an opcode indicating the type of operation that the pad entry is to support. This doesn't affect operational semantics, but is used for debugging.

Allocates a place in the currently-compiling pad (via "pad_alloc") for an anonymous function that is lexically scoped inside the currently-compiling function. The function func is linked into the pad, and its CvOUTSIDE link to the outer scope is weakened to avoid a reference loop.

One reference count is stolen, so you may need to do SvREFCNT_inc(func).

optype should be an opcode indicating the type of operation that the pad entry is to support. This doesn't affect operational semantics, but is used for debugging.

Check for duplicate declarations: report any of:

     * a my in the current scope with the same name;
     * an our (anywhere in the pad) with the same name and the
       same stash as C<ourstash>

is_our indicates that the name to check is an 'our' declaration.

Given the name of a lexical variable, find its position in the currently-compiling pad. namepv/namelen specify the variable's name, including leading sigil. flags is reserved and must be zero. If it is not in the current pad but appears in the pad of any lexically enclosing scope, then a pseudo-entry for it is added in the current pad. Returns the offset in the current pad, or NOT_IN_PAD if no such lexical is in scope.

Exactly like "pad_findmy_pvn", but takes a nul-terminated string instead of a string/length pair.

Exactly like "pad_findmy_pvn", but takes the name string in the form of an SV instead of a string/length pair.

Find the position of the lexical $_ in the pad of the currently-executing function. Returns the offset in the current pad, or NOT_IN_PAD if there is no lexical $_ in scope (in which case the global one should be used instead). "find_rundefsv" is likely to be more convenient.

Find and return the variable that is named $_ in the lexical scope of the currently-executing function. This may be a lexical $_, or will otherwise be the global one.

Find a named lexical anywhere in a chain of nested pads. Add fake entries in the inner pads if it's found in an outer one.

Returns the offset in the bottom pad of the lex or the fake lex. cv is the CV in which to start the search, and seq is the current cop_seq to match against. If warn is true, print appropriate warnings. The out_* vars return values, and so are pointers to where the returned values should be stored. out_capture, if non-null, requests that the innermost instance of the lexical is captured; out_name_sv is set to the innermost matched namesv or fake namesv; out_flags returns the flags normally associated with the IVX field of a fake namesv.

Note that pad_findlex() is recursive; it recurses up the chain of CVs, then comes back down, adding fake entries as it goes. It has to be this way because fake namesvs in anon protoypes have to store in xlow the index into the parent pad.

Get the value at offset po in the current (compiling or executing) pad. Use macro PAD_SV instead of calling this function directly.

Set the value at offset po in the current (compiling or executing) pad. Use the macro PAD_SETSV() rather than calling this function directly.

Update the pad compilation state variables on entry to a new block.

"Introduce" my variables to visible status. This is called during parsing at the end of each statement to make lexical variables visible to subsequent statements.

Cleanup at end of scope during compilation: set the max seq number for lexicals in this scope and warn of any lexicals that never got introduced.

Abandon the tmp in the current pad at offset po and replace with a new one.

Mark all the current temporaries for reuse

Tidy up a pad at the end of compilation of the code to which it belongs. Jobs performed here are: remove most stuff from the pads of anonsub prototypes; give it a @_; mark temporaries as such. type indicates the kind of subroutine:

    padtidy_SUB        ordinary subroutine
    padtidy_SUBCLONE   prototype for lexical closure
    padtidy_FORMAT     format

Free the SV at offset po in the current pad.

Dump the contents of a padlist

dump the contents of a CV

Clone a CV, making a lexical closure. proto supplies the prototype of the function: its code, pad structure, and other attributes. The prototype is combined with a capture of outer lexicals to which the code refers, which are taken from the currently-executing instance of the immediately surrounding code.

For any anon CVs in the pad, change CvOUTSIDE of that CV from old_cv to new_cv if necessary. Needed when a newly-compiled CV has to be moved to a pre-existing CV struct.

Push a new pad frame onto the padlist, unless there's already a pad at this depth, in which case don't bother creating a new one. Then give the new pad an @_ in slot zero.

Looks up the type of the lexical variable at position po in the currently-compiling pad. If the variable is typed, the stash of the class to which it is typed is returned. If not, NULL is returned.

Duplicates a pad.




Hosting generously
sponsored by Bytemark