in reply to Perl is a compiler cum interpreter?

Perl source code is compiled into things called optrees. This is a linked list of things to execute and you can see some parts of this if you use the B::Concise module. Here's an example:

C:\Documents and Settings\Josh>perl -MO=Concise -e "print @ARGV"
7  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -e:1) v ->3
6     <@> print vK ->7
3        <0> pushmark s ->4
5        <1> rv2av[t2] lK/1 ->6
4           <#> gv[*ARGV] s ->5
-e syntax OK

[download]

This is actually just a bunch of C structs and perl is just walking them in order using this ultra simple runloop:

int
Perl_runops_standard(pTHX)
{
    dVAR;
    while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
        PERL_ASYNC_CHECK();
    }

    TAINT_NOT;
    return 0;
}

[download]

Since perl code is compiled into a kind of data, it's actually pretty lispy by this point. You can inspect and modify this data directly.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Replies are listed 'Best First'.
Re^2: Perl is a compiler cum interpreter?
by jimt (Chaplain) on Feb 15, 2007 at 16:24 UTC

    I'd always thought it was compiled into a bytecode state, similar to java. Was I off in this?

    One thing I've never understood is exactly why spitting out something in that intermediate step is apparently such a nuisance. If perl could plunk out the intermediate "compiled" bytecode (or optree or whatever it is), and then pick that up later, I think it'd be keen.

    First off, it would skip re-building the blasted tree every time. Yes, yes, I know that it's fast, but if we don't need to do it, we should skip it. But mainly, it'd clarify that yes, perl does compile, and stop the people that claim it's just glorified shell scripting. I'd say perl is as much a compiled language as java is.

    But, apparently, that's rather difficult to do, I guess. Can anybody explain why?

[reply]

      As I said above, the compiled form is a bunch of C structs in memory with pointers to each other. You could just dump this directly to disk but then it'd only be meaningful on a perl compiled exactly the same way. To get something you could run on someone else's perl you'd need to normalize it too. People tried doing that with the B::Bytecode module but it turned out that it was faster to go from source to optrees than "bytecode" to optrees.

      So it's true that we could substitute parsing source for reconstituting optrees but parsing source is already so fast that there it isn't a win to "skip" it. If you want to try this out on your perl, write the results of perl -MO=Bytecode your-file.pl to disk and then check out the byteloader program. This has been removed in the latest dev versions of perl mostly because in addition to never actually being faster, it also never really worked.

      ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]
[d/l]
      First off, it would skip re-building the blasted tree every time.

      There's still the deserialization overhead, which is not cheap.

      Moving away from a tree representation to formal bytecode would help with that, but it would require such a change to the Perl 5 core that no one who knows how is likely to do it ever.

[reply]

In Section Seekers of Perl Wisdom