Front page | perl.perl6.internals |
Postings from August 2001
RE: Opcode Dispatch
Thread Next
From:
Garrett Goebel
Date:
August 10, 2001 15:25
Subject:
RE: Opcode Dispatch
Message ID:
71BEC0D4E1DED3118F7A009027B12028010BDFCC@EXCH_MISSION
From: Uri Guttman [mailto:uri@sysarch.com]
> >>>>> "GG" == Garrett Goebel <garrett@scriptpro.com> writes:
>
> GG> Are we going to compile to bytecode every time, or might:
>
> GG> perl foo.pm
>
> GG> create foo.pmc
>
> GG> So that the next time foo.pm is called for the bytecode could be
> GG> reused instead of recompiling foo.pm. Assuming a checksum in
> GG> foo.pmc says foo.pm hasn't changed.
[...]
>
> if a module changes, do you force a rebuild?
yes.
> is it rebuilt automatically?
yes.
> do you use timestamps and/or checksums to see if
> a module changes?
checksums.
And we might want the local perl compiler to recognize/certify the bytecode
it produces. Someone could always copy foreign bytecode produced by a
different compiler which is incompatible, corrupt, or hacked. So we'd need a
means for performing some limited bytecode verification too.
> what tracks the module dependencies for the
> purposes of a rebuild?
I'd assume if someone does a "perl foo", we'd check header info to determine
if foo is an executable, bytecode, or plaintext.
I don't really want to think about executables too much. I don't see the
point in embedding a perl interpreter if you're going to have external
module dependencies. I'd assume executables would in most cases be used in
situations where Perl isn't installed. Though Activestate's PerlApp utility
does allow you to turn a script into an executable which depends on Perl's
being installed.
I'm not sure about the module dependencies. I don't understand bytecode as
well as you do. I was surprised to see that:
perl -MO=Bytecode,-ohello.pc -e "print qq|hello world\n|"
Results in a 200K hello.pc file!
Does everything and the kitchen sink have to go in there? I'm assuming
that'll be smaller in Perl6... or we'll wind up wasting too much disk space.
> do users need a make utility to track that and to force
> rebuilds?
Maybe I'm missing something due to my limited knowledge, but I'm hoping that
if foo.pl uses foo.pm that there'd be a foo.pc and foo.pmc. And that after
changes are made to foo.pl, executing it would overwriting foo.pc, but leave
foo.pmc alone.
If we do need a make could the Perl Power Tools make be made to work?
http://language.perl.com/ppt/src/make/index.html
> are real end users going to build byte stream versions?
We're making the bytecode, why discard it?
As to whether or not the execution of a user's script might result in a core
or site library being recompiled to bytecode... I'd punt that to a site
policy decision. But otherwise definitely yes where they have filesystem
rights.
> how are other byte stream languages dealing with these
> issues? we should do a study before committing to our design.
> this is a good topic for simon's language dev list.
Hmm... Is this time to plug simon's language dev list again?
> emacs has a similar problem with elisp and compiled elisp. but it can
> load/run either format and doesn't need to make them into standalone
> executables.
>
> in general, i see many possible pitfalls here so we should be clear on
> our goals before we do any design.
Thread Next