Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Wed, Jan 16, 2002 at 08:45:26AM +0100, Paul Johnson wrote: > The fundamental problem here is that BEGIN blocks have to run when they > are compiled. This is documented. You can try to work out whether the > BEGIN blocks can be rearranged and run at different times, but as Piers > has pointed out, this is impossible in the general case. So if the > BEGIN blocks are run at compile time, there's no point having them > around at run time. This is the raison d'?tre of INIT blocks. Ok, lemme run this by you. Here's my conception of how perlcc/B::C works. The program is compiled, the opcode tree is scanned and the appropriate C code is written for each op in the program. Just like B::Deparse scans the opcode tree and writes out Perl code. Which is why I'm having so much conceptual trouble with why BEGIN blocks would be a problem. It seems that's wrong. That what perlcc/B::C does is 'freeze' the current state of the interpreter after compilation, including the values of variables, and then spit out appropriate C code for only the post-compile opcode tree. Is this right? In which case, yes, I can see how BEGIN blocks would be troublesome. :( -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Nature is pissed. http://www.unamerican.com/
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switchto make Test::Builder output even if $^C ( for B::C ))
On Wed, 16 Jan 2002, Michael G Schwern wrote: >On Wed, Jan 16, 2002 at 08:45:26AM +0100, Paul Johnson wrote: >> The fundamental problem here is that BEGIN blocks have to run when they >> are compiled. This is documented. You can try to work out whether the >> BEGIN blocks can be rearranged and run at different times, but as Piers >> has pointed out, this is impossible in the general case. So if the >> BEGIN blocks are run at compile time, there's no point having them >> around at run time. This is the raison d'?tre of INIT blocks. > >Ok, lemme run this by you. > >Here's my conception of how perlcc/B::C works. The program is >compiled, the opcode tree is scanned and the appropriate C code is >written for each op in the program. Just like B::Deparse scans the >opcode tree and writes out Perl code. > >Which is why I'm having so much conceptual trouble with why BEGIN >blocks would be a problem. > >It seems that's wrong. That what perlcc/B::C does is 'freeze' the >current state of the interpreter after compilation, including the >values of variables, and then spit out appropriate C code for only >the post-compile opcode tree. Is this right? Yes. That's what makes startup time faster ( but not run time, as you surely know ) >In which case, yes, I can see how BEGIN blocks would be >troublesome. :( Regards Mattia
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Tue, Jan 15, 2002 at 05:30:09PM -0500, [EMAIL PROTECTED] wrote:
> On Tue, Jan 15, 2002 at 08:51:06AM +, Piers Cawley wrote:
> > > I don't understand. Why do we have to deal with them? Just translate
> > > the Perl code in the BEGIN block to C , dump it and make
> > > sure it gets run first. Right?
> > >
> > > I think I'm missing something very vital here.
Yeah, I think so ;-)
[snip]
> Guess? Its a BEGIN block, it gets run once!
Oh good, because you seemed to be suggesting otherwise.
> Ok, there's some really fundemental breakdown of understanding here,
> and I think its me. Let's step back a second. Why is anything
> guessing when and how many times BEGIN blocks are run?
Well, you seemed to be suggesting that some BEGIN blocks would be run at
runtime. Some BEGIN blocks have to run at compile time. If they're
only to be run once then you have to decide when that will be.
My boss recently gave me a fairly tricky problem to solve. The Java
boys weren't making much headway, so he asked if I could do it in PERL.
After (a) little thought I came up with an elegant modular solution.
Since the program contains proprietary intellectual property and also
because it has to run as fast as C, I decided to run perlcc on it.
Here's my program. Please don't break it.
ONE.pm
==
package ONE;
# I might obfuscate this eval statement later in case any of our
# competitors ever see this code.
sub import { eval '$main::ONE--' }
1
one.plx
===
#!/usr/bin/perl
# Copyright Paul Johnson, 2002
# This program is mine. You can't have it.
# Program to print 1
BEGIN { $ONE = 2 } # Initialisation.
use ONE;# Abstracted away main logic.
print $ONE # Output.
__END__
The fundamental problem here is that BEGIN blocks have to run when they
are compiled. This is documented. You can try to work out whether the
BEGIN blocks can be rearranged and run at different times, but as Piers
has pointed out, this is impossible in the general case. So if the
BEGIN blocks are run at compile time, there's no point having them
around at run time. This is the raison d'être of INIT blocks.
This problem cannot be solved. But if you do solve it millions will
rejoice. Well, thousands anyway. Still, I wonder whether you shouldn't
work up to it by perhaps finding a polynomial time solution to the
travelling salesman problem for example.
PS. Parts of this message are moderated by :-) where required by law.
--
Paul Johnson - [EMAIL PROTECTED]
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switch to make Test::Builder output even if $^C ( for B::C ))
On Wed, Jan 16, 2002 at 11:39:05AM +0100, Mattia Barbon wrote: > >It seems that's wrong. That what perlcc/B::C does is 'freeze' the > >current state of the interpreter after compilation, including the > >values of variables, and then spit out appropriate C code for only > >the post-compile opcode tree. Is this right? > > Yes. That's what makes startup time faster ( but not run time, > as you surely know ) I always thought that was recouped because you didn't have to load the interpreter and wait for Perl to compile the program and libraries to bytecode. PS I got a huge number of these warnings from compiling 'use CGI' pccF6qox.c:14873: warning: decimal constant is so large that it is unsigned pccF6qox.c:14875: warning: decimal constant is so large that it is unsigned -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One This is my sig file. Is it not nify? Worship the sig file. http://www.sluggy.com
