It is compiled into a tree of "opcodes". B::Concise can show you this tree.

>perl -MO=Concise -e"my $x = 1; $x += 2; print $x"
e  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -e:1) v ->3
5     <2> sassign vKS/2 ->6
3        <$> const[IV 1] s ->4
4        <0> padsv[$x:1,2] sRM*/LVINTRO ->5
6     <;> nextstate(main 2 -e:1) v ->7
9     <2> add[t2] vKS/2 ->a
7        <0> padsv[$x:1,2] sRM ->8
8        <$> const[IV 2] s ->9
a     <;> nextstate(main 2 -e:1) v ->b
d     <@> print vK ->e
b        <0> pushmark s ->c
c        <0> padsv[$x:1,2] l ->d
-e syntax OK
[download]

Being a little fussy, the final data structure used on the execution stage is not a tree but a directed graph that represents the program flow.

The tree is only an intermediate result.

The tree form is the natural representation of perl code. That representation is never lost either. It's only an optimization that the program flow is superimposed on top of the nodes to make another DAG.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Yeah, I suppose it's not really a tree, it's only represented as one. You can even see from the B::Concise output (->##) that it's really a graph.

Perl is compiled to bytecode, but the results of the compilation are not saved to disk.

Update: This is wrong, see below - it's not bytecode but an internal low level representation.

Perl is compiled to bytecode

no, that is false, the Perl program is not compiled to bytecode (unless you use the B::Bytecode backend).

It is parsed into an internal low level representation that is used later, on the execution stage (see ikegami response below), but this internal representation is not bytecode (for most definitions of bytecode :-)

The result of compilation can be saved to disk as bytecode: see B::Bytecode. The bytecode can then be executed with ByteLoader.

The Perl FAQ talks a bit about the compiled/interpreted question in Is it a Perl program or a Perl script? but doesn't get down to brass tacks.

A word spoken in Mind will reach its own level, in the objective world, by its own weight

Would it improve performance if the byte-code could be saved and used instead ?

Cheers
LuCa

A past attempt resulted in slower code, but that could have been implementation-specific.

There's also a lack of volunteers to maintain that part of the code, so it will be removed from 5.10 for being perpetually broken and hopelessly out of date.

IIRC, "old school" interpreters interpret each source statement/line/whatever every time that statement is executed. Almost no serious "interpreted" language does that nowadays, with the possible exception of shells.

Most current "interpreted" languages like perl, are transformed into some kind of intermediate form that is then executed by/via the runtime environment. This form may or may not be anything like Java's bytecode programs - for one thing, IIRC a/the Java runtime doesn't necessarily run the bytecode directly, but (can) also transform the code to more efficient lower-level/machine instructions. I know perl's model is supposedly quite different, but I don't know the details.

If you bundle the runtime environment with the "intermediate form" you may end up with something quite a lot like the threaded code model that is/was used in Forth (which apparently also can mix "compiled" and "interpreted" code, but as far as I know is usually regarded as a compiled language - and it's still used for embedded software due to, at least, the small size of the generated executables).

Well ... C code may be compiled to a machine language understood by the processor, but it's still just as dependent on it's run-time environment as Perl code is. Sometimes the runtime is linked into the program, but most of the time it's an external dynamicaly loaded library.

And of course very few programs, no matter in what langauge, can get by without the help from the OS.

Plus some processors do not really implement their machine language in the wires and transistors, but instead the ops are implemented in another, more low-level language. It's just that it's built into the processor and you are not allowed to use the microinstructions directly.

Jenda


Support Denmark! Defend the free world!

So Perl is like java which is compiled and interpreted and c is compiled-linked and run by the processor.. That makes sense..

So Perl is like java which is compiled and interpreted and c is compiled-linked and run by the processor.. That makes sense..

Usually, when a lot of brute-force processing needs to be done, you want to avoid virtual machines, and get right to the hardware, preferably with a language which can generate very good machine code, e.g., when you need to run a 1,000,000 DOF finite-element model, large-scale n-body simulations, or climate modeling, saving a few nanoseconds per computation can really add up.

Most tasks aren't anywhere near that computationally intensive.

"Interpreted" also sometimes seems to mean "entered into an IDE which continually checks syntax," with "compiled" meaning "completely entered into a file, which is then passed through a 'compiler' or 'interpreter'."

By this, I mean something like this: (> indicates what person enters; < indicates what system returns)

<PIRNT 'Today is Tuesday'
>PIRNT NOT RECOGNIZED
<WRITE 'Today is Tuesday'
>WRITE NOT RECOGNIZED
<PRINT 'Today is Tuesday'
>Today is Tuesday
<QUIT
[download]

ciao

See also Perl is a compiler cum interpreter?