From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RA74S-0004mz-Tb for qemu-devel@nongnu.org; Sat, 01 Oct 2011 17:26:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RA74R-0000UL-Ta for qemu-devel@nongnu.org; Sat, 01 Oct 2011 17:26:08 -0400 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:50148) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RA74R-0000U7-P1 for qemu-devel@nongnu.org; Sat, 01 Oct 2011 17:26:07 -0400 Message-ID: <4E87853B.20308@mail.berlios.de> Date: Sat, 01 Oct 2011 23:25:15 +0200 From: Stefan Weil MIME-Version: 1.0 References: <4E74FC29.1050003@mail.berlios.de> <1316289634-18786-6-git-send-email-weil@mail.berlios.de> <4E8745DE.5030007@web.de> In-Reply-To: <4E8745DE.5030007@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 6/8] tcg: Add bytecode generator for tcg interpreter List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Andreas_F=E4rber?= Cc: QEMU Developers Am 01.10.2011 18:54, schrieb Andreas F=E4rber: > Am 17.09.2011 22:00, schrieb Stefan Weil: >> Unlike other tcg target code generators, this one does not generate >> machine code for some cpu. It generates machine independent bytecode >> which is interpreted later. >> >> This allows running QEMU on any host. >> >> Interpreted bytecode is slower than direct execution of generated >> machine code. >> >> Signed-off-by: Stefan Weil > [...] >> diff --git a/tcg/bytecode/README b/tcg/bytecode/README >> new file mode 100644 >> index 0000000..6fe9755 >> --- /dev/null >> +++ b/tcg/bytecode/README >> @@ -0,0 +1,129 @@ >> +TCG Interpreter (TCI) - Copyright (c) 2011 Stefan Weil. >> + >> +This file is released under GPL 2 or later. >> + >> +1) Introduction >> + >> +TCG (Tiny Code Generator) is a code generator which translates >> +code fragments ("basic blocks") from target code (any of the >> +targets supported by QEMU) to a code representation which >> +can be run on a host. >> + >> +QEMU can create native code for some hosts (arm, hppa, i386, ia64,=20 >> ppc, ppc64, >> +s390, sparc, x86_64). For others, unofficial host support was written= . >> + >> +By adding a code generator for a virtual machine and using an >> +interpreter for the generated bytecode, it is possible to >> +support (almost) any host. >> + >> +This is what TCI (Tiny Code Interpreter) does. >> + >> +2) Implementation >> + >> +Like each TCG host frontend, TCI implements the code generator in >> +tcg-target.c, tcg-target.h. Both files are in directory tcg/bytecode. >> + >> +The additional file tcg/tci.c adds the interpreter. >> + >> +The bytecode consists of opcodes (same numeric values as those used b= y >> +TCG), command length and arguments of variable size and number. > > While reusing TCG opcode values certainly makes things easy to > implement, have you evaluated using LLVM bitcode as alternative to a > fully custom intermediate code format? > > Andreas I had a look on several bytecode representations - initially I thought of using Java. LLVM was on my list, too, but I cannot say that I really evaluated any of these alternatives. My primary goal was to learn more about TCG and to get something working, and as you said, reusing the TCG opcodes made things easier. LLVM might also be used as a replacement for TCG. It would be really interesting to see how both compare. Stefan