Re: Opcode Dispatch

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

Thread Previous | Thread Next

From:

Uri Guttman

Date:

August 10, 2001 15:39

Subject:

Re: Opcode Dispatch

Message ID:

200108102239.SAA02847@home.sysarch.com.

>>>>> "GG" == Garrett Goebel <garrett@scriptpro.com> writes:

  >> if a module changes, do you force a rebuild?

  GG> yes.

dan has stated and i agree that caching of byte code is an option and it
is not on by default. perl will still be a compile and go language. a
separate utility (dan's example was perlcc) or option to perl would
enable compiling to a byte code file. that may also be run at the same
time with the correct options and such.

  >> is it rebuilt automatically?

  GG> yes.

only if requested.

  >> do you use timestamps and/or checksums to see if
  >> a module changes?

  GG> checksums.

that is slow. this should only be allowed if you do a batch mode
compile. use timestamps for on the go checks. it sorta works for make :)

  GG> And we might want the local perl compiler to recognize/certify the
  GG> bytecode it produces. Someone could always copy foreign bytecode
  GG> produced by a different compiler which is incompatible, corrupt,
  GG> or hacked. So we'd need a means for performing some limited
  GG> bytecode verification too.

that is another project. who signs off on the compiler itself? 

  >> what tracks the module dependencies for the 
  >> purposes of a rebuild?

  GG> I'd assume if someone does a "perl foo", we'd check header info to
  GG> determine if foo is an executable, bytecode, or plaintext.

  GG> I don't really want to think about executables too much. I don't
  GG> see the point in embedding a perl interpreter if you're going to
  GG> have external module dependencies. I'd assume executables would in
  GG> most cases be used in situations where Perl isn't
  GG> installed. Though Activestate's PerlApp utility does allow you to
  GG> turn a script into an executable which depends on Perl's being
  GG> installed.

  GG> I'm not sure about the module dependencies. I don't understand bytecode as
  GG> well as you do. I was surprised to see that:

  GG>   perl -MO=Bytecode,-ohello.pc -e "print qq|hello world\n|"

  GG> Results in a 200K hello.pc file!

  GG> Does everything and the kitchen sink have to go in there? I'm
  GG> assuming that'll be smaller in Perl6... or we'll wind up wasting
  GG> too much disk space.

the bytecode version should be very short from what i have seen about
our design so far. it would have only the byte codes for the print op
and the qq op, the string literal, some boilerplate startup and cleanup
op codes, etc. the dispatch table would be just for those called
ops. dunno what default libraries will be loaded (not the O:: stuff
above) which will affect the compiled byte code. so i envision parrot
code to be fairly compact. it doesn't need to carry all of perl in it.

oh, and it will have a copy of the original source which can be
retrieved.

  >> do users need a make utility to track that and to force
  >> rebuilds?

  GG> Maybe I'm missing something due to my limited knowledge, but I'm
  GG> hoping that if foo.pl uses foo.pm that there'd be a foo.pc and
  GG> foo.pmc. And that after changes are made to foo.pl, executing it
  GG> would overwriting foo.pc, but leave foo.pmc alone.

but whare are these files found? what if one is installed in a place
where you don't have write permission. then the code is changed but you
can't create the new compiled to a file version. there are many other
annoyances to doing clean automatic compilation. 

  >> are real end users going to build byte stream versions?

  GG> We're making the bytecode, why discard it?

or why ask them to figure out where to save it to. the mot common uses
will be compile and go. if they want it faster (assuming it IS faster)
they can compile to a file and then run that. then they have to manage
where it and the master source files live.

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