develooper Front page | perl.perl6.internals | Postings from August 2001

Re: Opcode Dispatch

Thread Previous | Thread Next
Uri Guttman
August 10, 2001 13:16
Re: Opcode Dispatch
Message ID:
>>>>> "GG" == Garrett Goebel <> writes:

  GG> From: Dan Sugalski []
  >> Presumably they'll do something like:
  >> perlcc foo.pc
  >> to compile a module to bytecode.

  GG> Are we going to compile to bytecode every time, or might:

  GG> perl

  GG> create foo.pmc

  GG> So that the next time is called for the bytecode could be
  GG> reused instead of recompiling Assuming a checksum in
  GG> foo.pmc says 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

in general, i see many possible pitfalls here so we should be clear on
our goals before we do any design.


Uri Guttman  ---------  ----------
SYStems ARCHitecture and Stem Development ------
Search or Offer Perl Jobs  --------------------------

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About