From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKG4C-0005pO-G2 for qemu-devel@nongnu.org; Fri, 26 Jun 2009 14:22:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKG4C-0005ov-3k for qemu-devel@nongnu.org; Fri, 26 Jun 2009 14:22:28 -0400 Received: from [199.232.76.173] (port=51808 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKG4B-0005ob-Lk for qemu-devel@nongnu.org; Fri, 26 Jun 2009 14:22:27 -0400 Received: from fg-out-1718.google.com ([72.14.220.154]:64568) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKG4A-0000AD-Nz for qemu-devel@nongnu.org; Fri, 26 Jun 2009 14:22:26 -0400 Received: by fg-out-1718.google.com with SMTP id d23so563398fga.8 for ; Fri, 26 Jun 2009 11:22:25 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <200906261859.03172.paul@codesourcery.com> References: <200906261849.43746.uli@suse.de> <200906261840.10828.paul@codesourcery.com> <200906261859.03172.paul@codesourcery.com> Date: Fri, 26 Jun 2009 21:22:25 +0300 Message-ID: Subject: Re: [Qemu-devel] [RFC PATCH] s390x-linux-user From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On 6/26/09, Paul Brook wrote: > On Friday 26 June 2009, Blue Swirl wrote: > > On 6/26/09, Paul Brook wrote: > > > On Friday 26 June 2009, Blue Swirl wrote: > > > > On 6/26/09, Ulrich Hecht wrote: > > > > > There is a very peculiar S/390 instruction called "EXECUTE". What > > > > > it does is to take another instruction stored somewhere in memory, > > > > > logical-OR the second byte of the instruction with the LSB of R0 and > > > > > then execute the result, without changing the instruction in memory > > > > > or the program counter. Any idea how to implement this in QEMU? > > > > > Currently, I'm interpreting the couple of instructions that GCC uses > > > > > EXECUTE with, but in the long run that would amount to implementing > > > > > a second emulator... > > > > > > > > Maybe something like this: Make a special TB of the EXECUTE > > > > instruction and add LSB of R0 to TB flags for these TBs. Then you can > > > > examine R0, OR and generate code at translation time. The TBs linking > > > > to EXECUTE TB may need to be special too in order to track for R0. > > > > > > That's not sufficient. The results also depend on the referenced > > > instruction. > > > > Then add the second byte of the referenced instruction to TB flags? Or > > maybe just the result of the OR operation for compactness? > > > No. You need the whole instruction. Which is fetched from memory, so is not > easily available when you're checking TB flags. > To do it this way, I think you'd need to split the instruction in two. The > first part would load the whole instruciton from memory, or with r0, then > store the result in an internal CPU pseudo-register to the whole instruction, > and cuse annother TB lookup. The second would generate code that cleared the > pseudo-register then executed the code that was stored in it. > You'd have to include the whole of the pseudo-register in TB_FLAGS, and I > doubt you've got enough bits for that. How about cs_base then? > OTOH, tweaking the TCG interface so that it works as an interpreter shouldn't > be all that hard. It's something I've been considering to do for a while, and > would mean that you can build both interpreter and translator from the same > source. Like by adding an interpreter TCG target? If it were in C only, it could also serve as a portable (low performance) translator runtime.