Re: [Lightning] JIT binary translation using lightning possible?

[Kaz Nishimura]

Your guess is mostly correct.  I am trying to make an application-level emulator on a specific m68k-based machine.  The system services will be implemented in native code in C++.  I had wrote a direct interpreting emulator in the past but it was done when real CPU clocks were about 100 MHz, so I am trying to rewrite it in a more object-oriented way.

Since host CPUs have been more than 10 times faster now, even direct interpretation will be fast enough IMO.  So I think JIT translation as an additional performance boost and want to keep the binary translator as simple as possible because the largest performance bottleneck will be peripheral device emulation.  The key factors in the binary translator are simplicity in using the JIT code generator and portability on my plan.  That is why I waver between several JIT implementations.

On Wed, Oct 21, 2015 at 9:43 AM Paulo César Pereira de Andrade <address@hidden> wrote:

2015-10-20 20:31 GMT-02:00 Kaz Nishimura <address@hidden>:

  Hi,

> Of course, I will try to read ahead but not every instruction changes the
> condition code and the CPU is CISC so reading ahead up to any branch
> instruction may require not so simple two-pass decoding that I want to
> avoid.  In addition, the "guest" architecture has 16 hardware registers and
> I cannot map statically them to lightning registers.  I also want to avoid
> managing register reallocation if possible.

  Do you want to do a full computer system binary translation? If yes, it
is still possible with lightning, but you may have more luck, and possibly
even already done in qemu, e.g. see:
http://git.qemu.org/?p=qemu.git;a=tree;f=tcg
and unless I am mistaken, based on your email, it should be m68k :), see
git.qemu.org/?p=qemu.git;a=tree;f=target-m68k

  If only "user level" applications, lightning is a good option. I
would at first
suggest making simple tests, like just generating some code and
disassembling it. And forget about optimization in early stages. Just
translating to jit should provide a huge performance boost over an interpreter.

  This at least would give you a better idea of what lightning can do. I
suggest just taking a sample of code you want to translate, and generate
a simple parser, that just disassembles the jit, and does not execute it.

  For small amounts of code, you can write a simple script in the format
used by lightning tests. You would need to make a checkout of the source,
build it, and then write manually a simple translation. see the *.tst files
under http://git.savannah.gnu.org/cgit/lightning.git/tree/check/
If the script starts with ".disasm" it will just generate jit and
disassemble it.
The file http://git.savannah.gnu.org/cgit/lightning.git/tree/check/all.tst
is an example. It generates jit for almost all lightning interfaces, and
just disassembles it (useful in early stages of a new port).

Thanks,
Paulo