Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!ncoast!allbery
From: allbery@NCoast.ORG (Brandon S. Allbery KB8JRR)
Newsgroups: comp.lang.perl
Subject: Re: can we ever compile perl?
Message-ID: <1990Dec15.161911.27401@NCoast.ORG>
Date: 15 Dec 90 16:19:11 GMT
References: <110306@convex.convex.com> <1990Dec13.034336.21769@usenet@scion.CS.ORST.EDU> <93725765@bfmny0.BFM.COM>
Reply-To: allbery@ncoast.ORG (Brandon S. Allbery KB8JRR)
Followup-To: comp.lang.perl
Organization: North Coast Public Access *NIX, Cleveland, OH
Lines: 37

As quoted from <93725765@bfmny0.BFM.COM> by tneff@bfmny0.BFM.COM (Tom Neff):
+---------------
|  2. For many of us, it would be enough to be able to make fast-loadable
|     "Perl object files," i.e., write all data structures to disk after
|     compilation & before execution.  The resulting "compiled scripts"
|     would run faster because the parsing pass would be eliminated.
|     Especially wonderful with large scripts!
+---------------

I mentioned this to Larry once; he pointed out that Perl's internal structures
aren't particularly easy to save/restore in a portable way.  Of course, it
might be possible to write(savefd, etext, sbrk(0) - etext), but this is also
nonportable.

+---------------
|  4. If the Perl 'eval' compiler were put into a shared library, compiled
|     scripts could run and have access to a single, reentrant copy of the
|     evaluator if they need it.  Scripts themselves could stay small.
+---------------

..and shared libraries are another nonportable feature.  Not to mention that
I have yet to make any sense out of the SVR3 version.  (Of course, that may
simply be *my* problem, not a problem with the shared library implementation.)

I may look into compiling a *subset* of Perl.  It wouldn't accept everything,
and it might not treat everything the same as the interpreter does (i.e. "do"
would be reated as an include request... although most uses ofthis are now
subsumed by "require"), but the speed increase would probably be worth the
loss in functionality, as you say.  Of course, I need to find time to do this
(grrr!).

++Brandon
-- 
Me: Brandon S. Allbery			    VHF/UHF: KB8JRR on 220, 2m, 440
Internet: allbery@NCoast.ORG		    Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR			    AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY