From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5NmO-0003YA-2i for qemu-devel@nongnu.org; Sun, 18 Sep 2011 16:15:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5NmM-0000md-TJ for qemu-devel@nongnu.org; Sun, 18 Sep 2011 16:15:56 -0400 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:43659) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5NmM-0000mQ-Ol for qemu-devel@nongnu.org; Sun, 18 Sep 2011 16:15:54 -0400 Message-ID: <4E765171.8050108@mail.berlios.de> Date: Sun, 18 Sep 2011 22:15:45 +0200 From: Stefan Weil MIME-Version: 1.0 References: <4E74FC29.1050003@mail.berlios.de> <4E760AB2.50007@mail.berlios.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/8] tcg/interpreter: Add TCG + interpreter for bytecode (virtual machine) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mulyadi Santosa Cc: QEMU Developers Am 18.09.2011 18:39, schrieb Mulyadi Santosa: > Hi Stefan... > > On Sun, Sep 18, 2011 at 22:13, Stefan Weil wrote: >> Its primary purpose was support of new hosts without a native >> TCG. > > Thanks for the explanation, I got better picture now. However, still, > an interpreter must be ready to grab the bytecode and execute it, > right? > > So, that interpreter, should it be build inside Qemu too? Or can we > use/write external one? let's say creating one in python and TCI > passes the generated bytecode via UNIX socket to the listening Python > script, is that doable or one of the goal your design? Do you think of something like http://bellard.org/jslinux/? The current interpreter is built inside QEMU, and I'm afraid that separating code generator and interpreter in different processes might be a lot of work. Maybe running both in separate threads would be possible, so the code generator could prepare new bytecode while the interpreter is still running the previous one.