Re: moving from interpreted language to hypercube executable

pardo@cs.washington.edu (David Keppel)
Thu, 6 Aug 1992 21:53:36 GMT

          From comp.compilers

Related articles
Efficient generation of LALR(1) look-aheads in Parser Generators andrewd@cs.adelaide.edu.au (1992-07-27)
Question on moving from interpreted language to hypercube executable brannon@stun4r.cs.caltech.edu (1992-08-04)
Re: moving from interpreted language to hypercube executable pardo@cs.washington.edu (1992-08-06)
| List of all articles for this month |

Newsgroups: comp.compilers
From: pardo@cs.washington.edu (David Keppel)
Organization: Computer Science & Engineering, U. of Washington, Seattle
Date: Thu, 6 Aug 1992 21:53:36 GMT
References: 92-07-097 92-08-007
Keywords: interpreter, parallel, bibliography

brannon@stun4r.cs.caltech.edu (Terrence M. Brannon) writes:
>[I am working on making Lisp, Perl, Python, Tcl... as rpc servers.]
>[In Perl, rpc to Python for string manipulation, Perl continues.]


One interoperability problem is that debugging is generally hard. Suppose
I'm debugging the Perl code and I realize I want to look at (debug)
something in the Python code. Systems rarely handle this gracefully.


An interesting paper on these lines is [Callaghan 90]. It was on
`rice.edu', but I don't see it there, so I've put it on
`cs.washington.edu' in `pub/pardo/nefs.doc.ps.Z' (compressed
PostScript(tm)).


>[How do I compile an interpreted language?]


One option is to write a compiler. The typical approach is to produce
back-end code in a portable language with an existing compiler, as has
been discussed lately on `comp.compilers'. In some cases, compiling can
be as easy as syntactic translation.


Another approach is to view the program as being executed by an abstract
machine and write an efficient abstract machine. This is the approach
used by [Deutsch & Schiffman 84] and [Chambers & Ungar 89].


A third approach is to use partial evaluation to make the interpreter in
to a compiler or to compile programs. Some people have been getting good
results for ordinary machines, producing Pascal that runs at about half
the speed of the code compiled with a traditional compiler (I have
forgotten the references; sorry). The PE approach suffers from being
relatively new technology.


In some cases, the interpreted language already executes efficiently
because most of the work is done by compiled primitives. This is the
usual case when PostScript is used for image rendering. Line drawing,
etc., are done by fast machine-code primitives. The cost of dispatching
is very small compared to the total cost of rendering.


3 References:


%A Brent Callaghan
%T Network Extensible File System Protocol Specification
%D 12 February 1990


%A Craig Chambers
%A David Ungar
%T Customization: Obptimizing Compiler Technology for SELF, a
Dynamically-Typed Object-Oriented Programming Language
%J 0-89791-306-X/89/006/0146 (sorry!)
%D 1989
%P 146-160


%A Peter Deutsch
%A Alan M. Schiffman
%T Efficient Implementation of the Smalltalk-80 System
%J 11th Annual Symposium on Principles of Programming Languages (POPL 11)
%D January 1984
%P 297-302




;-D on ( Flawless execution ) Pardo
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.