The work of the interpreter has two main stages: compiling the codeinto the internal representation, or bytecode, and then executing it.Compiled code in perlguts explains exactly how the compilation stagehappens.

Here is a short breakdown of perl's operation:

Startup

The action begins in perlmain.c. (or miniperlmain.c for miniperl)This is very high-level code, enough to fit on a single screen, and itresembles the code found in perlembed; most of the real action takesplace in perl.c

perlmain.c is generated by ExtUtils::Miniperl fromminiperlmain.c at make time, so you should make perl to follow thisalong.

First, perlmain.c allocates some memory and constructs a Perlinterpreter, along these lines:

 1 PERL_SYS_INIT3(&argc,&argv,&env);
  2
  3 if (!PL_do_undump) {
  4 my_perl = perl_alloc();
  5 if (!my_perl)
  6 exit(1);
  7 perl_construct(my_perl);
  8 PL_perl_destruct_level = 0;
  9 }

Line 1 is a macro, and its definition is dependent on your operatingsystem. Line 3 references PL_do_undump, a global variable - allglobal variables in Perl start with PL_. This tells you whether thecurrent running program was created with the -u flag to perl andthen undump, which means it's going to be false in any sane context.

Line 4 calls a function in perl.c to allocate memory for a Perlinterpreter. It's quite a simple function, and the guts of it lookslike this:

 my_perl = (PerlInterpreter*)PerlMem_malloc(sizeof(PerlInterpreter));

Here you see an example of Perl's system abstraction, which we'll seelater: PerlMem_malloc is either your system's malloc, or Perl'sown malloc as defined in malloc.c if you selected that option atconfigure time.

Next, in line 7, we construct the interpreter using perl_construct,also in perl.c; this sets up all the special variables that Perlneeds, the stacks, and so on.

Now we pass Perl the command line options, and tell it to go:

 exitstatus = perl_parse(my_perl, xs_init, argc, argv, (char **)NULL);
  if (!exitstatus)
  perl_run(my_perl);
 
  exitstatus = perl_destruct(my_perl);
 
  perl_free(my_perl);

perl_parse is actually a wrapper around S_parse_body, as definedin perl.c, which processes the command line options, sets up anystatically linked XS modules, opens the program and calls yyparse toparse it.

Parsing

The aim of this stage is to take the Perl source, and turn it into anop tree. We'll see what one of those looks like later. Strictlyspeaking, there's three things going on here.

yyparse, the parser, lives in perly.c, although you're better offreading the original YACC input in perly.y. (Yes, Virginia, thereis a YACC grammar for Perl!) The job of the parser is to take yourcode and "understand" it, splitting it into sentences, deciding whichoperands go with which operators and so on.

The parser is nobly assisted by the lexer, which chunks up your inputinto tokens, and decides what type of thing each token is: a variablename, an operator, a bareword, a subroutine, a core function, and soon. The main point of entry to the lexer is yylex, and that and itsassociated routines can be found in toke.c. Perl isn't much likeother computer languages; it's highly context sensitive at times, itcan be tricky to work out what sort of token something is, or where atoken ends. As such, there's a lot of interplay between the tokeniserand the parser, which can get pretty frightening if you're not used toit.

As the parser understands a Perl program, it builds up a tree ofoperations for the interpreter to perform during execution. Theroutines which construct and link together the various operations areto be found in op.c, and will be examined later.

Optimization

Now the parsing stage is complete, and the finished tree represents theoperations that the Perl interpreter needs to perform to execute ourprogram. Next, Perl does a dry run over the tree looking foroptimisations: constant expressions such as 3 + 4 will be computednow, and the optimizer will also see if any multiple operations can bereplaced with a single one. For instance, to fetch the variable$foo, instead of grabbing the glob *foo and looking at the scalarcomponent, the optimizer fiddles the op tree to use a function whichdirectly looks up the scalar in question. The main optimizer is peepin op.c, and many ops have their own optimizing functions.

Running

Now we're finally ready to go: we have compiled Perl byte code, and allthat's left to do is run it. The actual execution is done by therunops_standard function in run.c; more specifically, it's doneby these three innocent looking lines:

 while ((PL_op = PL_op->op_ppaddr(aTHX))) {
  PERL_ASYNC_CHECK();
  }

You may be more comfortable with the Perl version of that:

 PERL_ASYNC_CHECK() while $Perl::op = &{$Perl::op->{function}};

Well, maybe not. Anyway, each op contains a function pointer, whichstipulates the function which will actually carry out the operation.This function will return the next op in the sequence - this allows forthings like if which choose the next op dynamically at run time. ThePERL_ASYNC_CHECK makes sure that things like signals interruptexecution if required.

The actual functions called are known as PP code, and they're spreadbetween four files: pp_hot.c contains the "hot" code, which is mostoften used and highly optimized, pp_sys.c contains all thesystem-specific functions, pp_ctl.c contains the functions whichimplement control structures (if, while and the like) and pp.ccontains everything else. These are, if you like, the C code for Perl'sbuilt-in functions and operators.

Note that each pp_ function is expected to return a pointer to thenext op. Calls to perl subs (and eval blocks) are handled within thesame runops loop, and do not consume extra space on the C stack. Forexample, pp_entersub and pp_entertry just push a CxSUB orCxEVAL block struct onto the context stack which contain the addressof the op following the sub call or eval. They then return the first opof that sub or eval block, and so execution continues of that sub orblock. Later, a pp_leavesub or pp_leavetry op pops the CxSUBor CxEVAL, retrieves the return op from it, and returns it.

Exception handing

Perl's exception handing (i.e. die etc.) is built on top of thelow-level setjmp()/longjmp() C-library functions. These basicallyprovide a way to capture the current PC and SP registers and laterrestore them; i.e. a longjmp() continues at the point in code wherea previous setjmp() was done, with anything further up on the Cstack being lost. This is why code should always save values usingSAVE_FOO rather than in auto variables.

The perl core wraps setjmp() etc in the macros JMPENV_PUSH andJMPENV_JUMP. The basic rule of perl exceptions is that exit, anddie (in the absence of eval) perform a JMPENV_JUMP(2), whiledie within eval does a JMPENV_JUMP(3).

At entry points to perl, such as perl_parse(), perl_run() andcall_sv(cv, G_EVAL) each does a JMPENV_PUSH, then enter a runopsloop or whatever, and handle possible exception returns. For a 2return, final cleanup is performed, such as popping stacks and callingCHECK or END blocks. Amongst other things, this is how scopecleanup still occurs during an exit.

If a die can find a CxEVAL block on the context stack, then thestack is popped to that level and the return op in that block isassigned to PL_restartop; then a JMPENV_JUMP(3) is performed.This normally passes control back to the guard. In the case ofperl_run and call_sv, a non-null PL_restartop triggersre-entry to the runops loop. The is the normal way that die orcroak is handled within an eval.

Sometimes ops are executed within an inner runops loop, such as tie,sort or overload code. In this case, something like

 sub FETCH { eval { die } }

would cause a longjmp right back to the guard in perl_run, poppingboth runops loops, which is clearly incorrect. One way to avoid this isfor the tie code to do a JMPENV_PUSH before executing FETCH inthe inner runops loop, but for efficiency reasons, perl in fact justsets a flag, using CATCH_SET(TRUE). The pp_require,pp_entereval and pp_entertry ops check this flag, and if true,they call docatch, which does a JMPENV_PUSH and starts a newrunops level to execute the code, rather than doing it on the currentloop.

As a further optimisation, on exit from the eval block in the FETCH,execution of the code following the block is still carried on in theinner loop. When an exception is raised, docatch compares theJMPENV level of the CxEVAL with PL_top_env and if they differ,just re-throws the exception. In this way any inner loops get popped.

Here's an example.

 1: eval { tie @a, 'A' };
  2: sub A::TIEARRAY {
  3: eval { die };
  4: die;
  5: }

To run this code, perl_run is called, which does a JMPENV_PUSHthen enters a runops loop. This loop executes the eval and tie ops online 1, with the eval pushing a CxEVAL onto the context stack.

The pp_tie does a CATCH_SET(TRUE), then starts a second runopsloop to execute the body of TIEARRAY. When it executes the entertryop on line 3, CATCH_GET is true, so pp_entertry calls docatchwhich does a JMPENV_PUSH and starts a third runops loop, which thenexecutes the die op. At this point the C call stack looks like this:

 Perl_pp_die
  Perl_runops  # third loop
  S_docatch_body
  S_docatch
  Perl_pp_entertry
  Perl_runops  # second loop
  S_call_body
  Perl_call_sv
  Perl_pp_tie
  Perl_runops  # first loop
  S_run_body
  perl_run
  main

and the context and data stacks, as shown by -Dstv, look like:

 STACK 0: MAIN
   CX 0: BLOCK  =>
   CX 1: EVAL   => AV()  PV("A"\0)
   retop=leave
  STACK 1: MAGIC
   CX 0: SUB =>
   retop=(null)
   CX 1: EVAL   => *
  retop=nextstate

The die pops the first CxEVAL off the context stack, setsPL_restartop from it, does a JMPENV_JUMP(3), and control returnsto the top docatch. This then starts another third-level runopslevel, which executes the nextstate, pushmark and die ops on line 4. Atthe point that the second pp_die is called, the C call stack looksexactly like that above, even though we are no longer within an innereval; this is because of the optimization mentioned earlier. However,the context stack now looks like this, ie with the top CxEVAL popped:

 STACK 0: MAIN
   CX 0: BLOCK  =>
   CX 1: EVAL   => AV()  PV("A"\0)
   retop=leave
  STACK 1: MAGIC
   CX 0: SUB =>
   retop=(null)

The die on line 4 pops the context stack back down to the CxEVAL,leaving it as:

 STACK 0: MAIN
   CX 0: BLOCK  =>

As usual, PL_restartop is extracted from the CxEVAL, and aJMPENV_JUMP(3) done, which pops the C stack back to the docatch:

 S_docatch
  Perl_pp_entertry
  Perl_runops  # second loop
  S_call_body
  Perl_call_sv
  Perl_pp_tie
  Perl_runops  # first loop
  S_run_body
  perl_run
  main

In this case, because the JMPENV level recorded in the CxEVALdiffers from the current one, docatch just does a JMPENV_JUMP(3)and the C stack unwinds to:

 perl_run
  main

Because PL_restartop is non-null, run_body starts a new runopsloop and execution continues.

INTERNAL VARIABLE TYPES

You should by now have had a look at perlguts, which tells you aboutPerl's internal variable types: SVs, HVs, AVs and the rest. If not, dothat now.

These variables are used not only to represent Perl-space variables,but also any constants in the code, as well as some structurescompletely internal to Perl. The symbol table, for instance, is anordinary Perl hash. Your code is represented by an SV as it's read intothe parser; any program files you call are opened via ordinary Perlfilehandles, and so on.

The core Devel::Peek module lets us examine SVs from aPerl program. Let's see, for instance, how Perl treats the constant"hello".

  % perl -MDevel::Peek -e 'Dump("hello")'
  1 SV = PV(0xa041450) at 0xa04ecbc
  2   REFCNT = 1
  3   FLAGS = (POK,READONLY,pPOK)
  4   PV = 0xa0484e0 "hello"\0
  5   CUR = 5
  6   LEN = 6

Reading Devel::Peek output takes a bit of practise, so let's gothrough it line by line.

Line 1 tells us we're looking at an SV which lives at 0xa04ecbc inmemory. SVs themselves are very simple structures, but they contain apointer to a more complex structure. In this case, it's a PV, astructure which holds a string value, at location 0xa041450. Line 2is the reference count; there are no other references to this data, soit's 1.

Line 3 are the flags for this SV - it's OK to use it as a PV, it's aread-only SV (because it's a constant) and the data is a PV internally.Next we've got the contents of the string, starting at location0xa0484e0.

Line 5 gives us the current length of the string - note that this doesnot include the null terminator. Line 6 is not the length of thestring, but the length of the currently allocated buffer; as the stringgrows, Perl automatically extends the available storage via a routinecalled SvGROW.

You can get at any of these quantities from C very easily; just addSv to the name of the field shown in the snippet, and you've got amacro which will return the value: SvCUR(sv) returns the currentlength of the string, SvREFCOUNT(sv) returns the reference count,SvPV(sv, len) returns the string itself with its length, and so on.More macros to manipulate these properties can be found in perlguts.

Let's take an example of manipulating a PV, from sv_catpvn, insv.c

 1  void
  2  Perl_sv_catpvn(pTHX_ register SV *sv, register const char *ptr, register STRLEN len)
  3  {
  4  STRLEN tlen;
  5  char *junk;
 
  6  junk = SvPV_force(sv, tlen);
  7  SvGROW(sv, tlen + len + 1);
  8  if (ptr == junk)
  9  ptr = SvPVX(sv);
  10  Move(ptr,SvPVX(sv)+tlen,len,char);
  11  SvCUR(sv) += len;
  12  *SvEND(sv) = '\0';
  13  (void)SvPOK_only_UTF8(sv);  /* validate pointer */
  14  SvTAINT(sv);
  15  }

This is a function which adds a string, ptr, of length len ontothe end of the PV stored in sv. The first thing we do in line 6 ismake sure that the SV has a valid PV, by calling the SvPV_forcemacro to force a PV. As a side effect, tlen gets set to the currentvalue of the PV, and the PV itself is returned to junk.

In line 7, we make sure that the SV will have enough room toaccommodate the old string, the new string and the null terminator. IfLEN isn't big enough, SvGROW will reallocate space for us.

Now, if junk is the same as the string we're trying to add, we cangrab the string directly from the SV; SvPVX is the address of the PVin the SV.

Line 10 does the actual catenation: the Move macro moves a chunk ofmemory around: we move the string ptr to the end of the PV - that'sthe start of the PV plus its current length. We're moving len bytesof type char. After doing so, we need to tell Perl we've extendedthe string, by altering CUR to reflect the new length. SvEND is amacro which gives us the end of the string, so that needs to be a"\0".

Line 13 manipulates the flags; since we've changed the PV, any IV or NVvalues will no longer be valid: if we have $a=10; $a.="6"; we don'twant to use the old IV of 10. SvPOK_only_utf8 is a specialUTF-8-aware version of SvPOK_only, a macro which turns off the IOKand NOK flags and turns on POK. The final SvTAINT is a macro whichlaunders tainted data if taint mode is turned on.

AVs and HVs are more complicated, but SVs are by far the most commonvariable type being thrown around. Having seen something of how wemanipulate these, let's go on and look at how the op tree isconstructed.

OP TREES

First, what is the op tree, anyway? The op tree is the parsedrepresentation of your program, as we saw in our section on parsing,and it's the sequence of operations that Perl goes through to executeyour program, as we saw in Running.

An op is a fundamental operation that Perl can perform: all thebuilt-in functions and operators are ops, and there are a series of opswhich deal with concepts the interpreter needs internally - enteringand leaving a block, ending a statement, fetching a variable, and soon.

The op tree is connected in two ways: you can imagine that there aretwo "routes" through it, two orders in which you can traverse the tree.First, parse order reflects how the parser understood the code, andsecondly, execution order tells perl what order to perform theoperations in.

The easiest way to examine the op tree is to stop Perl after it hasfinished parsing, and get it to dump out the tree. This is exactly whatthe compiler backends B::Terse, B::Conciseand B::Debug do.

Let's have a look at how Perl sees $a = $b + $c:

 % perl -MO=Terse -e '$a=$b+$c'
  1  LISTOP (0x8179888) leave
  2  OP (0x81798b0) enter
  3  COP (0x8179850) nextstate
  4  BINOP (0x8179828) sassign
  5  BINOP (0x8179800) add [1]
  6  UNOP (0x81796e0) null [15]
  7  SVOP (0x80fafe0) gvsv  GV (0x80fa4cc) *b
  8  UNOP (0x81797e0) null [15]
  9  SVOP (0x8179700) gvsv  GV (0x80efeb0) *c
  10  UNOP (0x816b4f0) null [15]
  11  SVOP (0x816dcf0) gvsv  GV (0x80fa460) *a

Let's start in the middle, at line 4. This is a BINOP, a binaryoperator, which is at location 0x8179828. The specific operator inquestion is sassign - scalar assignment - and you can find the codewhich implements it in the function pp_sassign in pp_hot.c. As abinary operator, it has two children: the add operator, providing theresult of $b+$c, is uppermost on line 5, and the left hand side ison line 10.

Line 10 is the null op: this does exactly nothing. What is that doingthere? If you see the null op, it's a sign that something has beenoptimized away after parsing. As we mentioned in Optimization, theoptimization stage sometimes converts two operations into one, forexample when fetching a scalar variable. When this happens, instead ofrewriting the op tree and cleaning up the dangling pointers, it'seasier just to replace the redundant operation with the null op.Originally, the tree would have looked like this:

 10  SVOP (0x816b4f0) rv2sv [15]
  11  SVOP (0x816dcf0) gv  GV (0x80fa460) *a

That is, fetch the a entry from the main symbol table, and then lookat the scalar component of it: gvsv (pp_gvsv into pp_hot.c)happens to do both these things.

The right hand side, starting at line 5 is similar to what we've justseen: we have the add op (pp_add also in pp_hot.c) addtogether two gvsvs.

Now, what's this about?

 1  LISTOP (0x8179888) leave
  2  OP (0x81798b0) enter
  3  COP (0x8179850) nextstate

enter and leave are scoping ops, and their job is to perform anyhousekeeping every time you enter and leave a block: lexical variablesare tidied up, unreferenced variables are destroyed, and so on. Everyprogram will have those first three lines: leave is a list, and itschildren are all the statements in the block. Statements are delimitedby nextstate, so a block is a collection of nextstate ops, withthe ops to be performed for each statement being the children ofnextstate. enter is a single op which functions as a marker.

That's how Perl parsed the program, from top to bottom:

 Program
    |
    Statement
    |
    =
   / \
  /   \
  $a   +
  / \
   $b   $c

However, it's impossible to perform the operations in this order:you have to find the values of $b and $c before you add themtogether, for instance. So, the other thread that runs through the optree is the execution order: each op has a field op_next whichpoints to the next op to be run, so following these pointers tells ushow perl executes the code. We can traverse the tree in this orderusing the exec option to B::Terse:

 % perl -MO=Terse,exec -e '$a=$b+$c'
  1  OP (0x8179928) enter
  2  COP (0x81798c8) nextstate
  3  SVOP (0x81796c8) gvsv  GV (0x80fa4d4) *b
  4  SVOP (0x8179798) gvsv  GV (0x80efeb0) *c
  5  BINOP (0x8179878) add [1]
  6  SVOP (0x816dd38) gvsv  GV (0x80fa468) *a
  7  BINOP (0x81798a0) sassign
  8  LISTOP (0x8179900) leave

This probably makes more sense for a human: enter a block, start astatement. Get the values of $b and $c, and add them together.Find $a, and assign one to the other. Then leave.

The way Perl builds up these op trees in the parsing process can beunravelled by examining perly.y, the YACC grammar. Let's take thepiece we need to construct the tree for $a = $b + $c

 1 term :   term ASSIGNOP term
  2 { $$ = newASSIGNOP(OPf_STACKED, $1, $2, $3); }
  3 |   term ADDOP term
  4 { $$ = newBINOP($2, 0, scalar($1), scalar($3)); }

If you're not used to reading BNF grammars, this is how it works:You're fed certain things by the tokeniser, which generally end up inupper case. Here, ADDOP, is provided when the tokeniser sees + inyour code. ASSIGNOP is provided when = is used for assigning.These are "terminal symbols", because you can't get any simpler thanthem.

The grammar, lines one and three of the snippet above, tells you how tobuild up more complex forms. These complex forms, "non-terminalsymbols" are generally placed in lower case. term here is anon-terminal symbol, representing a single expression.

The grammar gives you the following rule: you can make the thing on theleft of the colon if you see all the things on the right in sequence.This is called a "reduction", and the aim of parsing is to completelyreduce the input. There are several different ways you can perform areduction, separated by vertical bars: so, term followed by =followed by term makes a term, and term followed by +followed by term can also make a term.

So, if you see two terms with an = or +, between them, you canturn them into a single expression. When you do this, you execute thecode in the block on the next line: if you see =, you'll do the codein line 2. If you see +, you'll do the code in line 4. It's thiscode which contributes to the op tree.

 |   term ADDOP term
  { $$ = newBINOP($2, 0, scalar($1), scalar($3)); }

What this does is creates a new binary op, and feeds it a number ofvariables. The variables refer to the tokens: $1 is the first tokenin the input, $2 the second, and so on - think regular expressionbackreferences. $$ is the op returned from this reduction. So, wecall newBINOP to create a new binary operator. The first parameterto newBINOP, a function in op.c, is the op type. It's an additionoperator, so we want the type to be ADDOP. We could specify thisdirectly, but it's right there as the second token in the input, so weuse $2. The second parameter is the op's flags: 0 means "nothingspecial". Then the things to add: the left and right hand side of ourexpression, in scalar context.

STACKS

When perl executes something like addop, how does it pass on itsresults to the next op? The answer is, through the use of stacks. Perlhas a number of stacks to store things it's currently working on, andwe'll look at the three most important ones here.

Argument stack

Arguments are passed to PP code and returned from PP code using theargument stack, ST. The typical way to handle arguments is to popthem off the stack, deal with them how you wish, and then push theresult back onto the stack. This is how, for instance, the cosineoperator works:

  NV value;
   value = POPn;
   value = Perl_cos(value);
   XPUSHn(value);

We'll see a more tricky example of this when we consider Perl's macrosbelow. POPn gives you the NV (floating point value) of the top SV onthe stack: the $x in cos($x). Then we compute the cosine, andpush the result back as an NV. The X in XPUSHn means that thestack should be extended if necessary - it can't be necessary here,because we know there's room for one more item on the stack, sincewe've just removed one! The XPUSH* macros at least guarantee safety.

Alternatively, you can fiddle with the stack directly: SP gives youthe first element in your portion of the stack, and TOP* gives youthe top SV/IV/NV/etc. on the stack. So, for instance, to do unarynegation of an integer:

 SETi(-TOPi);

Just set the integer value of the top stack entry to its negation.

Argument stack manipulation in the core is exactly the same as it is inXSUBs - see perlxstut, perlxs and perlguts for a longerdescription of the macros used in stack manipulation.

Mark stack

I say "your portion of the stack" above because PP code doesn'tnecessarily get the whole stack to itself: if your function callsanother function, you'll only want to expose the arguments aimed forthe called function, and not (necessarily) let it get at your own data.The way we do this is to have a "virtual" bottom-of-stack, exposed toeach function. The mark stack keeps bookmarks to locations in theargument stack usable by each function. For instance, when dealing witha tied variable, (internally, something with "P" magic) Perl has tocall methods for accesses to the tied variables. However, we need toseparate the arguments exposed to the method to the argument exposed tothe original function - the store or fetch or whatever it may be.Here's roughly how the tied push is implemented; see av_push inav.c:

 1PUSHMARK(SP);
  2EXTEND(SP,2);
  3PUSHs(SvTIED_obj((SV*)av, mg));
  4PUSHs(val);
  5PUTBACK;
  6ENTER;
  7call_method("PUSH", G_SCALAR|G_DISCARD);
  8LEAVE;

Let's examine the whole implementation, for practice:

 1PUSHMARK(SP);

Push the current state of the stack pointer onto the mark stack. Thisis so that when we've finished adding items to the argument stack, Perlknows how many things we've added recently.

 2EXTEND(SP,2);
  3PUSHs(SvTIED_obj((SV*)av, mg));
  4PUSHs(val);

We're going to add two more items onto the argument stack: when youhave a tied array, the PUSH subroutine receives the object and thevalue to be pushed, and that's exactly what we have here - the tiedobject, retrieved with SvTIED_obj, and the value, the SV val.

 5PUTBACK;

Next we tell Perl to update the global stack pointer from our internalvariable: dSP only gave us a local copy, not a reference to theglobal.

 6ENTER;
  7call_method("PUSH", G_SCALAR|G_DISCARD);
  8LEAVE;

ENTER and LEAVE localise a block of code - they make sure thatall variables are tidied up, everything that has been localised getsits previous value returned, and so on. Think of them as the { and} of a Perl block.

To actually do the magic method call, we have to call a subroutine inPerl space: call_method takes care of that, and it's described inperlcall. We call the PUSH method in scalar context, and we'regoing to discard its return value. The call_method() function removesthe top element of the mark stack, so there is nothing for the callerto clean up.

Save stack

C doesn't have a concept of local scope, so perl provides one. We'veseen that ENTER and LEAVE are used as scoping braces; the savestack implements the C equivalent of, for example:

 {
  local $foo = 42;
  ...
  }

See Localizing changes in perlguts for how to use the save stack.

MILLIONS OF MACROS

One thing you'll notice about the Perl source is that it's full ofmacros. Some have called the pervasive use of macros the hardest thingto understand, others find it adds to clarity. Let's take an example,the code which implements the addition operator:

   1  PP(pp_add)
    2  {
    3  dSP; dATARGET; tryAMAGICbin(add,opASSIGN);
    4  {
    5 dPOPTOPnnrl_ul;
    6 SETn( left + right );
    7 RETURN;
    8  }
    9  }

Every line here (apart from the braces, of course) contains a macro.The first line sets up the function declaration as Perl expects for PPcode; line 3 sets up variable declarations for the argument stack andthe target, the return value of the operation. Finally, it tries to seeif the addition operation is overloaded; if so, the appropriatesubroutine is called.

Line 5 is another variable declaration - all variable declarationsstart with d - which pops from the top of the argument stack two NVs(hence nn) and puts them into the variables right and left,hence the rl. These are the two operands to the addition operator.Next, we call SETn to set the NV of the return value to the resultof adding the two values. This done, we return - the RETURN macromakes sure that our return value is properly handled, and we pass thenext operator to run back to the main run loop.

Most of these macros are explained in perlapi, and some of the moreimportant ones are explained in perlxs as well. Pay specialattention to Background and PERL_IMPLICIT_CONTEXT in perlguts forinformation on the [pad]THX_? macros.

An overview of the Perl interpreter

Daftar Isi

NAME

DESCRIPTION

ELEMENTS OF THE INTERPRETER