How does one find what PL_stack_sp is?

Discussion in 'Perl Misc' started by kj, Jul 30, 2005.

  1. kj

    kj Guest

    I'm *astonished* anyone other than the authors can understand the
    Perl source. How can *anyone* navigate this maze? It's insane.
    (And how can the Perl community defend itself against the common
    charge of Perl's unreadability, when all a critic needs to do is
    point to the Perl source itself for an unparalleled example of
    illegibility? Granted, the Perl source is not written in Perl,
    but it is obviously written by people who don't give a fig about
    the readability of the code. All the piousness in the umpteen Perl
    style guides begins to ring hollow after one takes a look at the
    Perl source.)

    I've spent a couple of hours (and 100% of my patience) trying to
    find what PL_stack_sp is. This is just *one* identifier out of
    thousands in the Perl source. At this rate it will take me many
    months of solid work to have a sense of where things are *defined*,
    let alone figuring out what they do or how they're used.

    And yes, I grepped "stack_sp" in perlxstut, perlxs, perlapi, and
    perlguts, and pored over Extending and Embedding Perl by Jenness
    and Cozens.

    The best I was able to find (and purely by random accident, BTW)
    is that it is a macro defined in perlapi.h as

    (*Perl_Tstack_sp_ptr(aTHX))

    Great. More wild goose chases ahead. I have not been able to find
    where aTHX is defined. I looked in perlapi.h, and in all the files
    #include'd in it, and all the files included by those, etc. Plus
    a huge list of other files (configuration files, make files, etc.),
    too long to fully enumerate. aTHX is not even mentioned in any of
    these.

    Doing a recursive grep for Perl_Tstack_sp_ptr in the Perl source
    turns up *nothing*, other than the occurrences of this identifier
    in the RHS of some definitions (such as PL_stack_sp) in perlapi.h.

    So, after hours of searching all I know is that PL_stack_sp is
    defined in terms of things I cannot find definitions for.

    OK, so what's the trick? How does one navigate this insanity?

    Thanks!

    kj

    --
    NOTE: In my address everything before the first period is backwards;
    and the last period, and everything after it, should be discarded.
     
    kj, Jul 30, 2005
    #1
    1. Advertising

  2. Also sprach kj:

    > I'm *astonished* anyone other than the authors can understand the
    > Perl source. How can *anyone* navigate this maze? It's insane.
    > (And how can the Perl community defend itself against the common
    > charge of Perl's unreadability, when all a critic needs to do is
    > point to the Perl source itself for an unparalleled example of
    > illegibility? Granted, the Perl source is not written in Perl,
    > but it is obviously written by people who don't give a fig about
    > the readability of the code. All the piousness in the umpteen Perl
    > style guides begins to ring hollow after one takes a look at the
    > Perl source.)


    What you forgot to mention is that perl is also one of the most portable
    pieces of software ever written. This doesn't come for free. The maze of
    preprocessor directives is the price you have to pay for it. It's beyond
    words how much I hated that at the beginning as I couldn't find
    anything. However, as time progressed...

    > I've spent a couple of hours (and 100% of my patience) trying to
    > find what PL_stack_sp is. This is just *one* identifier out of
    > thousands in the Perl source. At this rate it will take me many
    > months of solid work to have a sense of where things are *defined*,
    > let alone figuring out what they do or how they're used.
    >
    > And yes, I grepped "stack_sp" in perlxstut, perlxs, perlapi, and
    > perlguts, and pored over Extending and Embedding Perl by Jenness
    > and Cozens.


    You wont find it there because it's not part of the public API.
    PL_* are variables global to the perl interpreter. They are usually
    wrapped in some other macros in case they are useful to extension
    writers. In case of PL_stack_sp the macros in question are 'SP' and
    'ST(x)' to access a single scalar in this stack. And those are
    mentioned in perlapi.pod.

    > The best I was able to find (and purely by random accident, BTW)
    > is that it is a macro defined in perlapi.h as
    >
    > (*Perl_Tstack_sp_ptr(aTHX))


    That's how all global variables look before the preprocessor is done
    with them. In thrdvar.h you find:

    PERLVAR(Tstack_sp, SV **)

    which is furhter mangled until it becomes

    EXTERN_C SV*** Perl_Tstack_ptr(pTHX);

    > Great. More wild goose chases ahead. I have not been able to find
    > where aTHX is defined. I looked in perlapi.h, and in all the files
    > #include'd in it, and all the files included by those, etc. Plus
    > a huge list of other files (configuration files, make files, etc.),
    > too long to fully enumerate. aTHX is not even mentioned in any of
    > these.


    (p|a)THX_? are important macros to ensure that XS modules work both on
    threaded and unthreaded perls. pTHX is used in function declarations:

    int function (pTHX_ int a, int b);

    /* for parameterless functions use version without underscore */

    int function (pTHX);

    If your perl is threaded then these are expanded to

    register PerlInterpreter *my_perl

    Functions thus declared are supposed to be called with the corresponding
    aTHX macros:

    function(aTHX_ 1, 2);

    In a threaded environment aTHX is replaced with the variable pointing to
    the Perl interpreter of the currently executing thread. Thus it is
    ensured that the interpreter can be accessed by macros and functions of
    the Perl API.

    > Doing a recursive grep for Perl_Tstack_sp_ptr in the Perl source
    > turns up *nothing*, other than the occurrences of this identifier
    > in the RHS of some definitions (such as PL_stack_sp) in perlapi.h.


    Have a closer look at what PERLVAR does. Note that it is overridden in
    some headers so you have to be sure to look at the right one. In your
    case:

    #define PERLVAR(v,t) EXTERN_C t* Perl_##v##_ptr(pTHX);

    > So, after hours of searching all I know is that PL_stack_sp is
    > defined in terms of things I cannot find definitions for.
    >
    > OK, so what's the trick? How does one navigate this insanity?


    By practice and intuition. ;-)

    There is a certain, albeit not always consistent, system of naming
    conventions and preprocessor chains involved. PL_ are global variables
    and they are usually mapped to something that is defined in thrdvar.h or
    intrpvar.h using one of the various PERLVAR... macros. These two header
    files are actually just the body of a C-structure declaration which you
    can see in perl.h:

    struct interpreter {
    # include "thrdvar.h"
    # include "intrpvar.h"
    /*
    * The following is a buffer where new variables must
    * be defined to maintain binary compatibility with previous versions
    */
    PERLVARA(object_compatibility,30, char)
    };

    So these two huge header files combined define all the fields of 'struct
    interpreter'. When you see something like PL_dirty and are curious
    what it is, you do a grep for 'Tdirty' in these two headers, and it
    yields:

    PERLVARI(Tdirty, bool, FALSE) /* in the middle of tearing things down? */

    So it's a boolean with initial value FALSE.

    Tassilo
    --
    use bigint;
    $n=71423350343770280161397026330337371139054411854220053437565440;
    $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
     
    Tassilo v. Parseval, Jul 30, 2005
    #2
    1. Advertising

  3. kj

    kj Guest

    Tassilo, thank you for your detailed explanation. I'll study it
    carefully.

    kj

    --
    NOTE: In my address everything before the first period is backwards;
    and the last period, and everything after it, should be discarded.
     
    kj, Jul 30, 2005
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Cyb
    Replies:
    12
    Views:
    676
    Eric Bohlman
    Dec 2, 2003
  2. news.frontiernet.net
    Replies:
    6
    Views:
    1,153
    news.frontiernet.net
    Apr 16, 2004
  3. Wybo Dekker
    Replies:
    1
    Views:
    388
    Yukihiro Matsumoto
    Nov 15, 2005
  4. vdvorkin
    Replies:
    0
    Views:
    433
    vdvorkin
    Feb 10, 2011
  5. vdvorkin
    Replies:
    3
    Views:
    846
    vdvorkin
    Feb 14, 2011
Loading...

Share This Page