Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re: How can I read assemble code ?

by ady (Deacon)
on Oct 12, 2007 at 06:27 UTC ( #644388=note: print w/replies, xml ) Need Help??

in reply to How can I read assemble code ?

First you'll have to understand, that Perl program execution is a mixture of parsing, interpretation and compilation :
The perl executable you are using has two distinct stages. First comes the frontend, which is certainly a compiler of sorts. It compiles your perl program source into a parse tree. This compiler then performs various optimizations such as one would find in any other compiler, including throwing out unreachable code, reducing constant expressions to their results, and loading in certain library definitions. It is at this point that the use statements get run, since they are semantically equivalent to BEGIN{} blocks wrapping a require and an import() class-method call against the included module.
End of compilation.
Next comes the backend, which is certainly an interpreter of sorts; let's call it a PP interpreter for now, just because. While what it actually executes is a parse tree and not byte code per se, still we would not go wrong in classifying this backend as a byte-code interpreter (like java or python). This is useful in particular when it comes to distinguishing these languages from ``pure'' interpreters, such as most shell and tcl implementations you happen to run. This is where any requires not wrapped in BEGINs occur.. . .br>

From the frontend (the ``source-code to parse-tree'' compiler), you can get at the backend (the PP interpreter) via a BEGIN subroutine. Likewise, to go the other way (get back to the compiler from the interpreter), you can use an eval("string") or a s/foo/bar/ee notation. By the way, despite appearances to the contrary, it turns out that an eval { BLOCK } and s/foo/bar/e are not actually hooks back to the compiler; it already handled them long ago and far away.)

Put another way
When the Perl compiler is fed a Perl program, the first task it performs is lexical analysis: breaking down the program into its basic syntactic elements (often called tokens). If the program is:
print "Hello, world!\n";
the lexical analyzer breaks it down into three tokens: print, "Hello, world!\n", and the final semicolon. The token sequence is then parsed, fixing the relationship between the tokens. In Perl, the boundary between lexical analysis and parsing is blurred more than in other languages. (Other computer languages, that is.
. . .
Once a program has been parsed . . ., it is compiled into a tree of opcodes representing low-level operations, and finally that tree of operations is executed--unless you invoked Perl with the -c ("check syntax") switch, which exits upon completing the compilation phase. . . . As the tree of opcodes constituting a compiled Perl program is executed, Perl values are created, manipulated, and destroyed.

For details, see:
Programming Perl: Internals and Externals
Perl in a nutshell: The Perl Interpreter
Introduction to the Perl Compiler-Translator
Perl has always had a compiler: your source is compiled into an internal form (a parse tree) which is then optimized before being run. Since version 5.005, Perl has shipped with a module capable of inspecting the optimized parse tree (B), and this has been used to write many useful utilities, including a module that lets you turn your Perl into C source code that can be compiled into an native executable.

The B module provides access to the parse tree, and other modules (``back ends'') do things with the tree. Some write it out as bytecode, C source code, or a semi-human-readable text. Another traverses the parse tree to build a cross-reference of which subroutines, formats, and variables are used where. Another checks your code for dubious constructs. Yet another back end dumps the parse tree back out as Perl source, acting as a source code beautifier or deobfuscator. Because its original purpose was to be a way to produce C code corresponding to a Perl program, and in turn a native executable, the B module and its associated back ends are known as ``the compiler'', even though they don't really compile anything. Different parts of the compiler are more accurately a ``translator'', or an ``inspector'', but people want Perl to have a ``compiler option'' not an ``inspector gadget''. What can you do?

Best regards,
Allan Dystrup

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://644388]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2022-08-08 10:34 GMT
Find Nodes?
    Voting Booth?

    No recent polls found