Related articles |
---|
JIT machine code generation SRINIVASANP@phibred.com (Srinivasan, Pattabi) (1997-07-29) |
Re: JIT machine code generation pardo@cs.washington.edu (1997-07-31) |
Re: JIT machine code generation Sergey.Solyanik@bentley.com (Sergey Solyanik) (1997-08-07) |
Re: JIT machine code generation pardo@cs.washington.edu (1997-08-12) |
From: | pardo@cs.washington.edu (David Keppel) |
Newsgroups: | comp.compilers |
Date: | 12 Aug 1997 14:51:47 -0400 |
Organization: | Computer Science & Engineering, U of Washington, Seattle |
References: | 97-07-119 97-07-131 97-08-023 |
Keywords: | interpreter, history |
<Sergey.Solyanik@bentley.com> wrote:
>> For systems that do more fine-grained compilation, a direct jump is
>> more commonly used with some assembly hair to make sure the system
>> is sane when control passes out of the dynamically-compiled code.
>David Keppel wrote:
>I haven't heard of this (outside of adaptive inlining, which does not,
>strictly speaking, "jump"). Do you know of any system that actually
>implement this?
Yes, including Shade. The main loop of Shade does a branch to the
desired translation. Translations end with a jump. There are at
least three possibilties for that jump:
- To another translation; the predecessor translation is said to be
"chained" to the successor translation.
- To an entry point in the main loop which says "the predecessor has
not yet been chanined, find the successor translation, chain the
predecessor to the successor by rewriting the predecessor's jump,
and then jump to the sucecssor."
- To an entry point in the main loop which says "the predecessor may
not be chained because the successor is variable, for example, the
predecessor is an indirect jump; look up the successor and jump to
it but don't chain the predecessor."
The main loop is written in assembly; among other things it has more
than one entry point. The fast case code for "find the successor" is
inlined in the main loop. Harder cases including complex searches and
translation (dynamic compilation from target code to host code) are
handled by saving virtual state from host registers back to RAM and
then calling the general machinery.
The "unit" of dynamic translation is an extended basic block with a
multiple entry points and a single exit; each (dynamically-occuring)
entry point is given a separate translation. Since these units are so
small, the prologue/epilogue code for entry/exit needs to be
moderately fast or else it dominates execution time, except at high
levels of tracing, when the tracing cost overwhelms even slow
simulation.
I believe that Cathy May's "Mimic" system was similar, but it did more
aggressive optmization and had fewer registers and thus had more
complicated assembly to reset the state.
The machinery of Shade, including the main loop and translation
chaining, is described in more detail in the Shade papers. A good
starting point is:
%A Bob Cmelik
%A David Keppel
%T Shade: A Fast Instruction-Set Simulator for Execution Profiling
%J Proceedings of the 1994 ACM SIGMETRICS Conference
on the Measurement and Modeling of Computer Systems
%D May 1994
%P 128-137
see also
http://www.cs.washington.edu/research/compiler/papers.d/shade.html
I'm not sure that the EDSAC debugger counts here but it implemented
most of a dynamic translator in 43 words of memory in 1951 and used
branches to and from assembly :^)
;-D on ( Jumping to and fro ) Pardo
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.