mitch@hq.af.mil (Mitch Wright) (11/10/90)
Has anyone ever considered writing a PERL compiler?? Yes, I know PERL compiles it's self (sort of) and you can dump core and then undump it into an executable. I was thinking more of something on the lines of a C-compiler -- maybe as some sort of front end to gcc ?? Just wondering. Even if this message gets alot of BOOs, I still think it would be a nifty project -- maybe for a compiler class. -- ..mitch mitch@hq.af.mil (Mitch Wright) | The Pentagon, 1B1046 | (703) 695-0262 ``A system without PERL is like a hockey game without a fight.'' -- Mitch Wright
merlyn@iwarp.intel.com (Randal Schwartz) (11/11/90)
In article <MITCH.90Nov9124943@hq.af.mil>, mitch@hq (Mitch Wright) writes: | Even if this message gets alot of BOOs, I still think it would be a nifty | project -- maybe for a compiler class. We went through this about six months ago. If you have power of "eval", you have to have an interpreter in the run-time package. And since Larry goes to great pains to compile the code to an efficient pile-o'-bits before running it, you probably wouldn't gain much by turning that data structure inside-out into a bunch of procedure calls. But, hey, if you've got student labor, go for it. :-) | ``A system without PERL is like a hockey game without a fight.'' | -- Mitch Wright Can we put that in The Book? That's a good one! print "Just another Perl [book] hacker," -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Intel put the 'backward' in 'backward compatible'..."=========/
les@chinet.chi.il.us (Leslie Mikesell) (11/11/90)
In article <1990Nov11.004221.11147@iwarp.intel.com> merlyn@iwarp.intel.com (Randal Schwartz) writes: >We went through this about six months ago. If you have power of >"eval", you have to have an interpreter in the run-time package. And >since Larry goes to great pains to compile the code to an efficient >pile-o'-bits before running it, you probably wouldn't gain much by >turning that data structure inside-out into a bunch of procedure >calls. But, hey, if you've got student labor, go for it. :-) A nice compromise would be to split the compiler and run-time code apart and allow saving the compiled script files between runs. Then if your code doesn't use "eval", you never have to bring in the compiler at all and if it does, it can just run it in another process and look at the output file. Even if perl weren't split into two separate programs, systems with demand paged exectuables would get much the same effect just by allowing the compiled script to be saved for re-execution. Les Mikesell les@chinet.chi.il.us
elw@netx.com (Edwin Wiles) (11/12/90)
In article <MITCH.90Nov9124943@hq.af.mil> mitch@hq.af.mil (Mitch Wright) writes: >Has anyone ever considered writing a PERL compiler?? Yes, I know PERL >compiles it's self (sort of) and you can dump core and then undump it >into an executable. I was thinking more of something on the lines of >a C-compiler -- maybe as some sort of front end to gcc ?? Just wondering. I won't "boo" it, but I would ask for something different. With particularly large PERL scripts, the compilation can take some time. I'd like a way to reload the dumped file into PERL for execution, thus avoiding the compilation time. (Assuming that the reload would take less time than the recompilation.) It should also be simplier to implement than either a translation of the dumped file into an executable, or the translation of the PERL code into C code. Enjoy! -- Prefered.: elw@netx.com Edwin Wiles Alternate: ...!grebyn!netex!elw NetExpress Inc., Suite 300, Who? Me?!? Responsible!?! Surely You Jest! Vienna, VA, USA 22182
jsb@cs.brown.edu (John Bazik) (11/13/90)
In article <MITCH.90Nov9124943@hq.af.mil>, mitch@hq.af.mil (Mitch Wright) writes: |> Has anyone ever considered writing a PERL compiler?? Yes, I know PERL |> compiles it's self (sort of) and you can dump core and then undump it Which brings up the question: does anyone have an undump that works on a Sun Sparcstation? The version we have produces an executable that dumps core...alas. John Bazik jsb@cs.brown.edu
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (11/13/90)
In article <56096@brunix.UUCP> jsb@cs.brown.edu (John Bazik) writes:
: Which brings up the question: does anyone have an undump that works on
: a Sun Sparcstation? The version we have produces an executable that
: dumps core...alas.
As of pl40 I've added Tom Christiansen's hooks to use Gnu emacs's unexec().
You might try that.
I'm also considering Dan Bernstein's pmckpt() routine, though the paradigm
is slightly different. If someone wants to hack that in and make it
work, I wouldn't complain...
Larrysahayman@iuvax.cs.indiana.edu (Steve Hayman) (11/13/90)
>| ``A system without PERL is like a hockey game without a fight.'' >Can we put that in The Book? That's a good one! A hockey game with a fight is slow, takes forever to finish, and does not appeal to true hockey fans. I think you might want a better analogy.
jv@mh.nl (Johan Vromans) (11/13/90)
In article <MITCH.90Nov9124943@hq.af.mil> mitch@hq.af.mil (Mitch Wright) writes: > Has anyone ever considered writing a PERL compiler? With regard to the nature of PERL: the generated binary would need to include the whole PERL compiler itself. This eliminates one of the most obvious advantages of compilation: a small binary. However, a means to save the compiled PERL program in a (sort of) executable file, and have PERL execute it, would be very handy. It eliminates the need for parsing, translating and compilation upon every invokation. No, I do not consider undumping a good alternative for this, since it produces huge binaries and it makes it impossible to execute existing binaries with a new interpreter. Somehow it must be possible to save the internal code of a compiled program in a (possibly) system (and PERL?) independent format. And, of course, autoloading... Johan -- Johan Vromans jv@mh.nl via internet backbones Multihouse Automatisering bv uucp: ..!{uunet,hp4nl}!mh.nl!jv Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62911/62500 ------------------------ "Arms are made for hugging" -------------------------
ronald@robobar.co.uk (Ronald S H Khoo) (11/14/90)
Johan Vromans <jv@mh.nl> writes: > No, I do not consider undumping a good alternative > for this, since it produces huge binaries and it makes it impossible > to execute existing binaries with a new interpreter. Also, on machines with slow hard discs like PCs, loading the undumped binary takes so long that it's actually *slower* than recompiling each time (partly because you tend to get all of the CPU to yourself on PCs :-) so the benefit of undump goes real negative :-) (Yes, I tried it :-) No, not on an MS-DOS PC, before you ask. It was Xenix) > Somehow it must be possible to save the internal code of a compiled > program in a (possibly) system (and PERL?) independent format. This would be very nice. Yes please. :-) Then we can rewrite all of /usr/bin and /bin in perl, and save a *lot* of disc space. -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
worley@compass.uucp (Dale Worley) (11/14/90)
However, a means to save the compiled PERL program in a (sort of) executable file, and have PERL execute it, would be very handy. It eliminates the need for parsing, translating and compilation upon every invokation. It seems to me that one solution that would be useful for many other things also is a subsystem than can dump and reload arbitrary data structures. Ideally, you feed it the .h file that describes the data structure, and it can write out and read in such structures. This would allow you to dump out the Perl internal form and reload it later. Dale Worley Compass, Inc. worley@compass.com -- Generally speaking, the Way of the warrior is resolute acceptance of death. -- Miyamoto Musashi, 1645
bhoughto@cmdnfs.intel.com (Blair P. Houghton) (11/15/90)
In article <1990Nov14.105212.11777@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >Johan Vromans <jv@mh.nl> writes: >> Somehow it must be possible to save the internal code of a compiled >> program in a (possibly) system (and PERL?) independent format. > >This would be very nice. Yes please. :-) Then we can rewrite all of >/usr/bin and /bin in perl, and save a *lot* of disc space. Ever thought of layered run-time libraries? I bet perl scripts would cook kittens in compiled form under VAX/VMS. (Of course, this is manifestly the machine-code incarnation of interpreters, but it saves on the context switches. :) --Blair "RTL: The only thing that makes VMS non-valueless."
gamin@ireq-robot.hydro.qc.ca (Martin Boyer) (11/15/90)
In article <1990Nov13.100359.1846@squirrel.mh.nl> Johan Vromans <jv@mh.nl> writes: > >In article <MITCH.90Nov9124943@hq.af.mil> mitch@hq.af.mil (Mitch Wright) writes: >> Has anyone ever considered writing a PERL compiler? > >With regard to the nature of PERL: the generated binary would need to >include the whole PERL compiler itself. Not sure; think for instance about the way Lucid can reduce LISP image sizes with a technique they call "tree shaking". The way I understand it, you start with the top-level function, recursively find all the functions it invokes and disregard the remaining functions. Provided the PERL script (or the LISP program) doesn't call eval (which was mentioned earlier in this thread), you will end up with a smaller binary than the sum of PERL and the original script. Doing this, of course, requires extensive knowledge of PERL internals; who knows what 'print', for instance, calls internally. -- Martin Boyer mboyer@ireq-robot.hydro.qc.ca Institut de recherche d'Hydro-Quebec mboyer@ireq-robot.uucp Varennes, QC, Canada J3X 1S1 +1 514 652-8136
lbr@holos0.uucp (Len Reed) (11/15/90)
In article <1990Nov11.035903.6333@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1990Nov11.004221.11147@iwarp.intel.com> merlyn@iwarp.intel.com (Randal Schwartz) writes: > >>We went through this about six months ago. If you have power of >>"eval", you have to have an interpreter in the run-time package.... >A nice compromise would be to split the compiler and run-time code apart >and allow saving the compiled script files between runs. Then if your >code doesn't use "eval", you never have to bring in the compiler at all >and if it does, it can just run it in another process and look at the >output file.... I was hoping to break the MS-DOS version of perl into overlays along this line. I figured that it would be nice if one overlay could handle the compilation and the other execution. An eval-laden script might thrash, but this could save a lot of memory for most other scripts. Alas, I couldn't come up with a useful partitioning of the .c files. I've used a razor, not a hatchet, on Larry's code. (The big changes were in the msdos subdirectory.) Maybe I'll do this now that the functionality of the MS-DOS port is better. As much as I've worked on this, though, I've stayed on the periperhy of perl; I'm not very clear on most of its internals. BTW, I'll be sending my MSDOS patches to Larry today. -- Len Reed Holos Software, Inc. Voice: (404) 496-1358 UUCP: ...!gatech!holos0!lbr
inc@tc.fluke.COM (Gary Benson) (11/21/90)
In article <71327@iuvax.cs.indiana.edu> sahayman@iuvax.cs.indiana.edu (Steve Hayman) writes: >>| ``A system without PERL is like a hockey game without a fight.'' >>Can we put that in The Book? That's a good one! > > >A hockey game with a fight is slow, takes forever to finish, and does not >appeal to true hockey fans. I think you might want a better analogy. No, it's a great analogy! Fights don't really *belong* in the game, now do they? Yet you must admit they add adventure, some excitement, a sense of danger, even while commentators stand around sidelines clucking their tongues, and saying how terrible it all is! Besides, don't the fights actually get things settled at the level of the *players* so the game can by god proceed??? As a true hockey fan, I have come to expect the players to push the rules and rough it up perhaps a bit more than they're "supposed to". -- Gary Benson -=[ S M I L E R ]=- -_-_-_-inc@fluke.com_-_-_-_-_-_-_-_-_-_- If we make peaceful revolution impossible, we make violent revolution inevitable. -John F. Kennedy