| [reply] |
On the one hand, parrot's opcodes were very much chosen to fit well with perl's way of doing things. On the other hand, decompilation to perl source would still be very tricky, given only PASM. On the gripping hand, the default output format of the compiler will probably include lots of debugging information, so caller() can return correct information, and so death (and moreso carping) will bring perl's usual wonderfuly verbose error messages.
Confession: It does an Immortal Body good.
| [reply] |
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] |
Given that for "better" all we have to do is make it work, I don't think you'll find it a problem. I don't know that you'll find much of a speed win over the JIT, though. | [reply] |
I don't know about that. On slow systems (and specificly, memory-starved ones), not having to compile every time will greatly speed up the overall running process on many scripts. More importantly, perhaps, it will make things like palm perl more doable and more usable.
Confession: It does an Immortal Body good.
| [reply] |
Only for generous values of "work".
| [reply] |
Of course yes!
Only Heretic will dare to claim opposite...
Courage, the Cowardly Dog | [reply] |