[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bochs-dev
Subject:    Re: Dymamic Translation question
From:       bochs () world ! std ! com (Kevin P Lawton)
Date:       1999-02-11 21:17:22
[Download RAW message or body]

> How will your translator handle the jump at the end of a
> code block to another block of local code - will you recursively
> translate code blocks and branch out from the original code
> block?

Well, there's a number of possibilities.

At a minimum, you can just translate one code block and return
to the main loop after executing it, having the main loop look up the
next code block in the translated cache.

Though for performance, it's better to have one translated code
block jump to another one directly.  Especially for code which
is part of a loop which gets iterated many times.

One solution would be for the translator to branch out at
each control transfer point (if the target was local) in
a recursive fashion, translating the target code first, and
returning the address of the cache code so the original code
knows where to jump to.  (Like you mention above)
Depending on how nuts you go with this, like using this technique
on conditional jumps, you could spend a lot of time in the
translation engine and wind up translating code which doesn't
get used.

So I don't like that approach much.  My idea is to translate
only 1 code block at a time, spending as little time in the
translator as possible.  At the end of the code block, if
a jump exists, I'll insert a call to some simple patch code,
which will see if the target address is translated.  If so,
it'll patch in the jump to the newly translated address.  If
not, return to the main loop logic.  If patched, the next time around
the patch code will not be called.  This is more of an
on-demand approach.  The resulting code should be very efficient
while wasting the least time in the translation engine.

Of course, if the target code is translated and cached already,
at the time of translating the source code, then you have the
target cache address to work with, and you're done.

-Kevin


-- 
         To unsubscribe: mail bochs-developers-request@redhat.com with 
                       "unsubscribe" as the Subject.

[prev in list] [next in list] [prev in thread] [next in thread]