Why is there a separate "perl" compiler and "perlcc" frontend for Perl?_问答_开发者

I am trying to make an executable out of my Perl code and then I realized that there is no such option available with the perl compiler. After a bit of searching, I found perlcc, which is a frontend for the Perl compiler and does the job (produces a binary).

Why does Perl have a separate compiler and frontend? Like for example, gcc for C/C++ is a complete tool in itself. Is t开发者_运维知识库his just the way it is, or are there some good reasons behind it?

This answer was written a long time ago and doesn't reflect the current state. I'd rather delete this answer, but I can't since it's accepted. See Reini's answer instead.

It's not typical for people to compile Perl programs to a binary. Plenty of people would like to do that, but that's just not the way it works. What are you trying to accomplish? There might be another way to do what you want to do.

A Perl program really executes in two phases: a compile-time and a run-time. It's a dynamic language too, so you can't tell everything you'll need to compile at the end of the compile phase, and during the compile phase you might have to run some code.

Perl is more like Java or Ruby than C in this manner. When you run a Perl program, the perl interpreter loads all the source code and compiles it into a abstract syntax tree. It's that bytecode that perl executes (or interprets) during the runtime. This is the same sort of thing that Java, Ruby, and Python do.

One of Perl's warts is that it doesn't have a good way to save the result of that compilation, like those other languages can. That means you end up compiling the source every time. There are some ways around that with pperl and domain-specific tools such as mod_perl or fastcgi.

There are some fuzzy bits in there with BEGIN blocks, eval, and so on, but that's mostly the way it works. There are more details in perlmod.

This design wart wouldn't be there if we started all over with everything we know now, and indeed, in Perl 6 it isn't there. :)

I'm sure you are referring to the B::C suite with perlcc which came with perl until 5.8.9. Since then I took over the development of the perl compiler which was not enhanced since 1997, and fixed most of the remaining bugs.

Why does perl have separate compiler and frontend?

First of all (for the others): perl is the only official frontend for perl, the interpreter.

perlcc is the frontend for the compilers B::C, B::Bytecode (-B) and B::CC (-O), the C linker part is in cc_harness also.

Nobody really wants to mess with the various options for the backends. Using perlcc is much easier. Like gcc as driver for all the backends and intermediate steps. gcc has for all intermediate steps also different executables: cc1, cc1plus, collect, as, ld

Do you want to call cc1 by your own? I never saw this.

Does this answer your question sufficiently?

BTW, basically all answers before were complelety wrong and nobody answered Lazer's question directly.

@briandfoy: perlcc is not a dead tool, it is in steady development, and it is used in production code. Startup times are dramatically faster. You can ship single executables. 90% of normal perl works. You could also use .pmc (as python does), but only huge sites do that. I recommend to use the version from CPAN.

perlcc basically creates a dump at CHECK time, and executes the dump then. So there are semantical differences to perl packers (PAR, perl2exe, perlapp), which create dumps and execute them before BEGIN. See perlcompile.pod from B::C on CPAN.

@mkb: perlcc support did not languish. p5p was just not capable enough to fix the remaining bugs. So I did. See http://search.cpan.org/dist/B-C/.

@Chas: Of course does perl5 compile down to some sort of "bytecode", the optree. The B::Bytecode compiler can be used to dump this, and the ByteLoader is used to run it. There also MAD which dumps to XML. And there's -u which dumps to a binary representation. Which can be used to undump to an exe. Just a simple linker-like step is necessary, for which I had no time yet.

@Novikov: Perl compiles to bytecode, and then runs this. As most scripting languages do. Perl has perlcc so you compile it to native executables.

@zigdon: You mixed that up with packagers, like perl2exe and PAR.

Maybe we have that mess because of the still wrong entry of the perl compiler in the FAQ.

Correction: It was a separate front-end. perl is not really a compiler to bytecode. The ultimate form of 'compiled' Perl is a set of abstract syntax trees that are then used by an interpreter. Perlcc support languished because the language changed fast enough that it never kept up. The problems it solved are mostly solvable in other ways that don't require constant maintenance of a separate source tree.

Because Perl 5 doesn't compile down to bytecode. Perl 6, on the other hand, can be compiled down to bytecode that runs on the Parrot virtual machine.

Perl programs aren't compiled as C programs are, they are parsed at runtime. All perlcc does is try to bundle up the perl executable and any libraries your program needs into one binary. At runtime, the script will still be interpreted, not run from the binary data.

Perl is an interpreted language, C/C++ aren't.