From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1FxL4N-0004CY-RO
	for qemu-devel@nongnu.org; Mon, 03 Jul 2006 05:50:19 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1FxL4J-0004Bl-Jr
	for qemu-devel@nongnu.org; Mon, 03 Jul 2006 05:50:19 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1FxL4J-0004Bb-EC
	for qemu-devel@nongnu.org; Mon, 03 Jul 2006 05:50:15 -0400
Received: from [193.7.176.20] (helo=bender.bawue.de)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FxLHj-00083F-Bg
	for qemu-devel@nongnu.org; Mon, 03 Jul 2006 06:04:07 -0400
Date: Mon, 3 Jul 2006 10:50:03 +0100
Subject: Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Message-ID: <20060703095002.GA21507@networkno.de>
References: <449EB5FA.6070405@gmail.com> <449EBC39.3050701@bellard.org>
	<449FFEB2.1070305@gmail.com> <44A040DA.2050108@bellard.org>
	<44A1529D.1070306@gmail.com>
	<Pine.LNX.4.63.0606271748590.12563@mag.sysgo.com>
	<44A19BC3.1030607@bellard.org> <44A7F3F1.5020909@gmail.com>
	<20060702231636.GB18996@networkno.de>
	<44A8D615.9060004@bellard.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44A8D615.9060004@bellard.org>
From: Thiemo Seufer <ths@networkno.de>
Reply-To: qemu-devel@nongnu.org
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: Fabrice Bellard <fabrice@bellard.org>
Cc: qemu-devel@nongnu.org

Fabrice Bellard wrote:
[snip]
> >>>There is no good reason to make 
> >>>the selection at compile time because the translator can efficiently 
> >>>handle any CPU differences at runtime.
> >
> >
> >I'm a bit dubious about this argument, each instruction needs to be
> >checked agains a tuple of values. How much performance loss would be
> >acceptable?
> 
> It slows down the translator a bit, but most of the time is spent in the 
> generated code, not in the translator (otherwise there is no point in 
> doing dynamic translation !).

Well, based on that theory I moved the CP0 register handling to dynamic
translation. The patch was rejected because I had no effective method
to assess the performance gain. So I wonder what the accepted tradeoffs
for the implementation are.


Thiemo