Perl Internals and Implementation

Irfarino has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Perl Internals and Implementation by davido (Cardinal) on Apr 15, 2012 at 16:47 UTC
Internals: perlintern, perlhack, perlhacktut, perlhacktips, perlsource, perlinterp, perlguts XS extension code, and embedding: perlguts, perlapi, perlcall, perlxstut, perlxs, perlembed There is the Extending and Embedding Perl book (Manning), but I haven't read it, and don't think it covers actually dealing with Perl's source code. And of course there is the Perl source code itself, which comes with every complete installation. There is also the perl5porters@perl.org mailing list where a lurker is sure to learn a lot (see http://lists.perl.org for subscription info). Dave	[reply]
Re^2: Perl Internals and Implementation by eyepopslikeamosquito (Archbishop) on Apr 15, 2012 at 20:49 UTC
Excellent list. Further to that, there have been some useful nodes on perl internals posted here over the years. Two that spring to mind are: Hacking perl by robin Re: Perl closures: internal details.(Updated) by dave_the_m (see also the whole thread) If you are eager to learn about Perl internals, I would pay attention to anything posted here by dave_the_m.	[reply]
Re^2: Perl Internals and Implementation by Irfarino (Initiate) on Apr 15, 2012 at 20:20 UTC
This is great! Thanks Dave, hoping to contribute someday :) Cheers!	[reply]
Re: Perl Internals and Implementation by choroba (Cardinal) on Apr 15, 2012 at 16:44 UTC
See also PerlGuts Illustrated (if it is not too simple for you).	[reply]
Re: Perl Internals and Implementation by bulk88 (Priest) on Apr 16, 2012 at 19:19 UTC
I say the most important thing about learning Perl's insides is using a C compiler to produce post preprocessor output then running that through a code formatter. Perl uses so many macros, and macros made of macros made of macros, that it is impossible to see what is actually done on a C or assembly level using a C debugger on the Perl engine. The perl stack grows up (higher pointers), the x86 stack grows down (lower pointers). YACC (the parser library in Perl, and some other programing languages) is supposedly C code, but its practically a different programing language, that through the magic of the preprocessor becomes C code. Use EXTEND(), not XPUSH* to reduce bloat. Try to never use malloced memory, it will leak when you croak/die, instead make a mortal SV and grow it, you dont need to ever make Pok or expose it in the Perl language or save it in a Perl engine struct. For XS, use memory from SV that came from @_ (Perl stack) or package glob globals. Remember you can access trees of hashes and blessed hash objects in XS as easily as you can in Perl. Good use of the Alias feature can reduce alot of XS bloat. XPrePUSH and PUSHs are less bloated than XS_RETURN*. Use PPCODE: not CODE: in xsubpp processed XS libraries. To look at a SV in C, read my node here Looking at a SV in C.	[reply]