Perlcc goes down to C, and then to an executable, so there is a fair amount of information lost. It's certainly possible, with enough work, to reconstruct the optree from a compiled perl 5 program, but it can be non-trivial.
It's likely that a compiled-to-C parrot program will be even more difficult to reconstruct, not through any particular artifice on our part (code obfuscation is not one of parrot's goals) but more because of the way we generate the C code and from there what an optimizing C compiler's likely to do.
What we do is keep the actual source for each opcode function around and, when we compile a parrot program to C, we emit that source with any needed register substitution. (We basically treat the opcodes as a sort of macro) That gets you real C source which a compiler's optimizer will then chew on rather badly. This, of course, only works on the parts of your program that are fixed at compile time--string eval'd code will still run at normal interpreter speed, and be visible in the program.
Doing it this way gives the C compiler's optimizer more information to work with, which is good--that'll get you faster executables. It does obscure the source, making it about as easy to recreate as, say, turning an executable back to C code.
While on the one hand I don't particularly like the loss of the source, on the other it makes for faster (in some cases much faster) execution, and often makes distribution easier (though the executable can be rather big). And the name of the game here is speed. | [reply] |