From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MKF3Z-0001Zl-42
	for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:17:45 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MKF3Y-0001ZP-Jp
	for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:17:44 -0400
Received: from [199.232.76.173] (port=58017 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MKF3Y-0001ZL-H0
	for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:17:44 -0400
Received: from fg-out-1718.google.com ([72.14.220.153]:33986)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1MKF3Y-0000Di-7A
	for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:17:44 -0400
Received: by fg-out-1718.google.com with SMTP id d23so553536fga.8
	for <qemu-devel@nongnu.org>; Fri, 26 Jun 2009 10:17:42 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <200906261849.43746.uli@suse.de>
References: <200906261849.43746.uli@suse.de>
Date: Fri, 26 Jun 2009 20:17:42 +0300
Message-ID: <f43fc5580906261017o1eace71dn8b6483fa354e693d@mail.gmail.com>
Subject: Re: [Qemu-devel] [RFC PATCH] s390x-linux-user
From: Blue Swirl <blauwirbel@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Ulrich Hecht <uli@suse.de>
Cc: qemu-devel@nongnu.org

On 6/26/09, Ulrich Hecht <uli@suse.de> 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.