From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1FqUoW-00013H-8g
	for qemu-devel@nongnu.org; Wed, 14 Jun 2006 08:49:40 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1FqUoV-00012K-HP
	for qemu-devel@nongnu.org; Wed, 14 Jun 2006 08:49:39 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1FqUoV-00011z-8E
	for qemu-devel@nongnu.org; Wed, 14 Jun 2006 08:49:39 -0400
Received: from [84.96.92.61] (helo=sMtp.neuf.fr)
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1FqUxf-0004GB-Ry
	for qemu-devel@nongnu.org; Wed, 14 Jun 2006 08:59:08 -0400
Received: from [84.102.211.151] by sp604002mt.gpm.neuf.ld
	(Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006))
	with ESMTP id <0J0U00DYZNQN3CS0@sp604002mt.gpm.neuf.ld> for
	qemu-devel@nongnu.org; Wed, 14 Jun 2006 14:23:11 +0200 (CEST)
Date: Wed, 14 Jun 2006 14:22:53 +0200
From: Fabrice Bellard <fabrice@bellard.org>
Subject: Re: [Qemu-devel] Switch to OpenBIOS for Sparc32/64?
In-reply-to: <BAY104-F39D02E1E519B79828479E4FF8B0@phx.gbl>
Message-id: <448FFF9D.8080807@bellard.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <BAY104-F39D02E1E519B79828479E4FF8B0@phx.gbl>
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: qemu-devel@nongnu.org

Blue Swirl wrote:

> I included other fixes currently needed for correct operation (clock 
> year fix, FPU fix by Joerg Platte, MMU no-fault fix).

Note: the FPU "fix" should be revisited because it is really not 
optimal. Here are some ideas to implement it better:

1) Include the bit 'psref' in the static translation state (in 
tb->flags). Then psref can be tested at translation time and there is no 
run time cost. This approach is used on the x86 target. The downside is 
that two TBs may be generated for a given block of code depending on the 
psref value. Ideally if no FPU operations are used in the TB, psref 
should be ignored (not done yet on x86).

2) Keep psref dynamic, but test it only once per TB using FPU 
operations. In case of exception, rebuilt the CPU state as with MMU 
exceptions so that save_state() is not needed.

I tend to prefer the solution (1).

Fabrice.