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

List:       bochs-dev
Subject:    RE: [Bochs-developers] Dynamic Translation
From:       "fidonet.org.il" <stl () fidonet ! org ! il>
Date:       2005-09-10 18:07:28
Message-ID: E1EE9kg-0002yA-J6 () mail ! sourceforge ! net
[Download RAW message or body]

Hello,

> I have read about dynamic translation and I heard that
you want to use it.

I have read your mail and I not convinced you understand what is dynamic
translation and how it could be implemented ...
It is very easy to say what you need "to check the opcodes, copy the
instructions needed into memory, jump there and return
from there" but doing it this specific way most likely will not work.
May be you understand the main concepts of the dynamic translation but 
let's talk about details too ...

> The problem is, the source code has to be rewritten
for every processor architecture or function addon.

The code first of all should be written ;)
We already have some platform specific optimizations (for example host
specific asm optimizations in cpu or devices working only on linux host) so
it will be ok if we made DT for most command x86 arch only and only when
extend it to other architectures.
But here the most complexity is an interface. The dynamic translation (DT)
module should be totally plugin'able, i.e. the interface of translator
should be the same for every platform. Bochs core should provide to
translator all sufficient information about instructions to translate and
receive translated code back through one common interface. This interface
still need to be designed but may be we will need to start writing the
translator to understand its requirements from the interface. Might be
h.johansson who already wrote translator code for Bochs could help with the
definition ...

> I don't know if there is a faster or better way to do that but we
definitly have to use assembler for that and I don't know how to write
assembler in GNU as (the instruction format is different from the one AMD
and Intel use).

First of all GNU don't use different instruction format from Intel's or
AMD's assembler. It just uses different syntax of assembly language for its
internal assembler, this syntax called AT&T style and you could find tons of
documentation about how to write code in gcc internal asm.
But if you look into the problem you'll see that writing assembler language
is not required. I even not think it will speedup the emulation and
definitely will increase the complexity of DT code. What is actually
required is knowledge in compiler techniques of code optimization and code
generation for various platforms.

I will try to split the problem to smaller parts:

The main flow of the simulator going to be changed. The translator should
receive instructions for translation from data structure called instruction
trace. The trace has to be collected by Bochs before translation so the main
cpu loop will became more complex. 

The CPU loop will became state machine with three basic states - collecting
new trace (trace cache miss), executing trace from trace cache, executing
fast (translated) trace. The translator itself called when some trace was
executed from the cache more than N times, for example N=1000. Of course we
need to handle appropriately interrupts, async events and exceptions in the
middle of trace execution. This is relatively easy to do (complexity easy).

We have to decide the format for the trace cache in both pre-translated and
post translated case. Here we have two key requirements: 
1) the memory for translated code should have OS execute permissions
2) malloc and mmap is very costly operations, we have to avoid them when it
is possible.
The solution I see for both these two requirements is to allocate/mmap block
of execution enabled memory of fixed size in the beginning of emulation and
having some memory pool manager which will allocate traces from this
statically allocated memory we have. The complexity of this issue is
moderate.

Might be we will need to extend Bochs decoder to prepare some additional
information for translator about traced instructions and their dependencies.
May be even Bochs should prepare have intermediate language to simplify
trace reading and decoding by translators. This is not really required but I
seen that h.johansson using it in his code ...

Now going to the translator itself. Here we have to write module which
receives instructions trace as input (in some format, may be even in
intermediate language) and generates actual code to be executed. Even for
x86 architecture we could not just copy instructions from Bochs memory,
transfer the control and execute. If we have memory access inside the code
we have to find where the data hosted in Bochs emulated memory and read it
correctly. So every load/store operation in emulated code should be
converted from virtual address space to host address space and only when
translated to instruction with new addresses. So we became to real compiler
problem - code generation for specific processor, we may use all known
compiler techniques, allocate registers and even make optimizations for the
executed code. For example one of the most promising optimizations is store
forwarding. There is a big chance that some load instruction reading data
written by some store instruction early in the same trace. Every such case
could be optimized by eliminating unnecessary memory access for load and
taking data from the store directly. Translator code could figure out in
code generation step what some store is forwarding and keep its data for
load.

All this require experience in compiler technologies and algorithms, at
least I am not an expert in this area and unfortunately I have no enough
time to learn it now ;(((

So after reading all above you could choose where you could help in this
project. When you decide, please post your opinion here.

Thanks,
Stanislav


-----Original Message-----
From: bochs-developers-admin@lists.sourceforge.net
[mailto:bochs-developers-admin@lists.sourceforge.net] On Behalf Of tobitosso
- tobthea
Sent: Saturday, September 10, 2005 4:10 PM
To: bochs-developers@lists.sourceforge.net
Subject: [Bochs-developers] Dynamic Translation

I have read about dynamic translation and I heard that
you want to use it.
The problem is, the source code has to be rewritten
for every processor architecture or function addon.
Bochs has to check what CPU features are present and
then execute a dll(the way I prefer on windows) with
the specific code for that CPU features.
I have imagined to check the opcodes, copy the
instructions needed into memory, jump there and return
from there. I don't know if there is a faster or
better way to do that but we definitly have to use
assembler for that and I don't know how to write
assembler in GNU as (the instruction format is
different from the one AMD and Intel use).

I could help you if you want

tobitosso - tobthea


	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
bochs-developers mailing list
bochs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bochs-developers






-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
bochs-developers mailing list
bochs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bochs-developers
[prev in list] [next in list] [prev in thread] [next in thread]