Front page | perl.perl6.internals |
Postings from August 2001
Re: Opcode Dispatch
Thread Previous
|
Thread Next
From:
Uri Guttman
Date:
August 10, 2001 13:16
Subject:
Re: Opcode Dispatch
Message ID:
200108102015.QAA02563@home.sysarch.com.
>>>>> "GG" == Garrett Goebel <garrett@scriptpro.com> writes:
GG> From: Dan Sugalski [mailto:dan@sidhe.org]
>>
>> Presumably they'll do something like:
>>
>> perlcc foo.pm foo.pc
>>
>> to compile a module to bytecode.
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.
the whole issue on that is wide open. can we create a true executable
(or even a #! one) that is a single byte stream file (with some header
stuff)? how will that be differentiated from a #!perl executable? by
name? path? suffix? your point about recompiling is an issue. what about
if a module changes, do you force a rebuild? is it rebuilt
automatically? do you use timestamps and/or checksums to see if a
module changes? what tracks the module dependencies for the purposes of
a rebuild? do users need a make utility to track that and to force
rebuilds? are real end users going to build byte stream versions? 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.
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.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
Thread Previous
|
Thread Next