Re: JIT machine code generation

pardo@cs.washington.edu (David Keppel)
12 Aug 1997 14:51:47 -0400

          From comp.compilers

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)
| List of all articles for this month |

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
--


Post a followup to this message

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