                            
                                                     
                                                       
               ۰߰     ܰ۰  
             ۱      ܱ߰    ۰
             ۱          ۱      ۰  
                 ܰ߱    ߰۲    
              Outbreak Magazine Issue #15 - Article 6 of 11
          '~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'


Art of Perl v3.0
================
By: buffer
 

This will be the last article on Perl, It will mostly deal with misc details. Hopefully 
these articles helped a few people on the basics of Perl. It's a pretty dirty language, but it 
has a lot of nice features, and the more you learn, the more you'll realize it. The first section 
I'll talk about Perl and security. 


Security with a language like Perl isn't really a factor, by that I mean, it's not prone to such 
attacks as buffer overflows, and the such. The reason it isn't, is because it does garbage storage. 
In your typical language like C, the data type you specify say a string that contains 5 characters, 
you'd just allocate space for that variable, if you forget to do bounds checking on this variable, 
then you could in theory overflow the buffer, by stuffing too much data into an insufficient amount 
of space. In Perl, it simply it keeps reallocating the space according to the amount of data the 
user/programmer requests. Which has it's pro's and con's, it tends to be less efficient, but in the 
long run it does much more good than bad. Perl actually does quite a lot of optimizations during 
the process of interpreting your code. In this next section we'll discuss the guts of the Perl 
interpreter, And how Perl does optimizations and other various things. 


Although Perl is classified as an interpreted language,  it is in theory a compiler, as I will 
explain. The life cycle of a Perl program can be broken up into four phases, the first and the 
last are the most interesting ones, in fact, the middle two are optional. 

1. The compilation phase:

During this phase, the compiler converts your program into a data structure, called a parse tree.
Along with standard parsing techniques, It uses other various powerful techniques, which use 
BEGIN blocks to guide further compilation. They are handed off to the interpreter to be run as 
soon as they are parsed, which runs them in a FIFO order (First in, First Out). Other blocks, 
are CHECK, INIT, EVAL, and  END, which are scheduled by the compiler for delayed execution. All 
EVAL blocks, constructs, and noninterpolated regular expressions are compiled here, and constant 
expressions are pre-evaluated. The compiler is now done, unless it gets called back into service 
later. If this occurs, the interpreter is then called up to execute any scheduled CHECK blocks 
in LIFO order (Last in First Out). The presence or absence of a CHECK block determines whether 
we go to phase 2 or skip to phase 4. 


2. Code Generation Phase (Optional)


CHECK blocks are installed by code generators, so this optional phase occurs when you explicitly 
use one of the code generators, These convert the compiled but not yet run program into either C 
source code or serialized Perl bytecodes, similar to Java(pos). A sequence of values expressing 
internal Perl instructions. If you choose to generate C source code, it can eventually produce an 
executable image in native machine language. At this point, your program is in a suspended phase, 
if you made an executable image it goes to phase 4, otherwise it reconstructs the freeze-dried 
byte code. Although this seems very confusing, and indeed it is, one day you'll come upon 
something similar, if it's compiler design, or something other, you'll have some sort of an idea. 

3. The Parse Tree Reconstruction Phase (also optional) 

To reanimate the program, its parse tree must be reconstructed. This phase exists only if code 
generation occurred and you  chose to generate bytecode. Perl reconstitutes its parse trees 
from that bytecode sequence before the program can run. If it ran directly from the bytecode it 
would be extremely slow. 


4. Execution Phase. 


Finally. What everyone's been waiting for: running the program. Called the run phase. The 
interpreter takes the parse tree (which it got from either the compiler or indirectly from code 
generation and parse tree reconstruction) and executes it. If you generated an executable image 
file, it can be run as a standalone program since it contains an embedded Perl interpreter.  
Before your main program gets to run, all scheduled INIT blocks are executed in FIFO order. Then 
your main program is run. The interpreter can call back into the compiler as needed upon 
encountering an eval STRING, a do FILE, require statement, or a pattern match with an interpolated 
variable that is found to contain a legal code assertion. When the main program finishes, any 
delayed END blocks are finally executed, in LIFO order. END blocks are skipped only if you 
exec(spawn another process) or your process received an error. Ordinary exceptions are not 
considered dangerous.  Perl is either in one of two modes of operation, either it's compiling 
your program or it's executing it, never both at the same time. Perl typically reads through 
your whole source file before it even begins execution. 


Optimization: 

Many ways that Perl does this. For instance, it rearranges your code to make it more efficient 
at execution time. Which is insulting if I might say :) . It also does what most half intelligent 
compilers do, which is get rid of dead code. Which is code that can never be executed, like an 
if(0) block. 

If you want to mess around with the Code generators, perlcc  converts Perl source into byte-compiled 
Perl programs. ie: 

perlcc -b -o outputscript srcscript 


                                             	      buffer
                                              buffer@uncompiled.com 