Re: Looking for a book with emphasis on interpreters

eac@iexist.att.com writes:
>What I am wondering about is why there has been so little written of late
>on the topic of interpreters. Do people feel that we have learned all that
>can be learned/invented on this topic? If so, then I would have thought
>that we would have seen someone's attempt at the definitive book on
>interpreter technologies published by now.
>
>Is it just that other technology areas are sexier or more interesting
>(e.g., things such as portable backends to compilers, squeezing the last
>cycle out of processor pipelines, and ways to speed up object oriented,
>method dispatch)? Are interpreters just too pedestrian to bother writing
>about?


People are still working on 'interpreters', but may not be calling
them by that name. The instruction fetch/execute mechanism of every
CPU is an interpreter, and there are lots of interesting applications
of SW ideas to HW implementations going on.


There has been a lot of work in the _automatic_ conversion of an interpreter
into a compiler. The Russians starting with Ershov have long been interested
in this idea.


Due to Apple's conversion on the road to Damascus (Yorktown?), there has been
a lot of interest in interpreting/compiling 68XXX code on RISC architectures.


The whole area of 'reflective' systems, which can access and change the
operation of their own interpreter, has been an active research area.


Every 2X-5X speedup in CPU allows another level of interpretation,
while keeping the same user level of performance, so we can achieve a
new level of complexity every Presidential election (or Olympics, if
you prefer). A cursory glance at any large-scale SW system shows a
substantial number of levels -- e.g., writing an object to a file
requires the interpretation of the file access protocol over a network
to a generic I/O system to a generic I/O device driver to a specific
embedded controller, etc.


Interpretation is the Parkinson's Law of Software -- the number of levels
of interpretation expands to absorb every increase in HW speed and memory
space. System 7.5 and Chicago apparently obey this law to the hilt.
--

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