From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKFhg-000325-Ka for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:59:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKFhb-0002zq-Ty for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:59:11 -0400 Received: from [199.232.76.173] (port=35209 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKFhb-0002zg-JL for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:59:07 -0400 Received: from mx20.gnu.org ([199.232.41.8]:2847) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MKFhb-0004eJ-6H for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:59:07 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKFha-0003oG-84 for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:59:06 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [RFC PATCH] s390x-linux-user Date: Fri, 26 Jun 2009 18:59:02 +0100 References: <200906261849.43746.uli@suse.de> <200906261840.10828.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906261859.03172.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org 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. 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. Paul