From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1IhSg0-0001Hp-SB
	for qemu-devel@nongnu.org; Mon, 15 Oct 2007 12:20:20 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1IhSfz-0001HH-Hn
	for qemu-devel@nongnu.org; Mon, 15 Oct 2007 12:20:19 -0400
Received: from mx1.polytechnique.org ([129.104.30.34])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <fabrice@bellard.org>) id 1IhSfz-0006Nq-3S
	for qemu-devel@nongnu.org; Mon, 15 Oct 2007 12:20:19 -0400
Received: from [172.17.17.9] (gw.netgem.com [195.68.2.34])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by ssl.polytechnique.org (Postfix) with ESMTP id 5CAF933193
	for <qemu-devel@nongnu.org>; Mon, 15 Oct 2007 18:19:14 +0200 (CEST)
Message-ID: <47139301.3010201@bellard.org>
Date: Mon, 15 Oct 2007 18:19:13 +0200
From: Fabrice Bellard <fabrice@bellard.org>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] RFC: Code fetch optimisation
References: <1192362267.9976.383.camel@rapid>	<200710150330.55998.paul@codesourcery.com>	<1192450140.9976.411.camel@rapid>
	<200710151701.17822.paul@codesourcery.com>
In-Reply-To: <200710151701.17822.paul@codesourcery.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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

Paul Brook wrote:
 > [...]
>>>The code itself looks ok, though I'd be surprised if it made a
>>>significant difference. We're always going to hit the fast-path TLB
>>>lookup case anyway.
>>
>>It seems that the generated code for the code fetch is much more
>>efficient than the one generated when we get when using the softmmu
>>routines. But it's true we do not get any significant performance boost.
>>As it was previously mentioned, the idea of the patch is more a 'don't
>>do unneeded things during code translation' than a great performance
>>improvment.
> 
> 
> OTOH it does make the the code more complicated. I'm agnostic about whether 
> this patch should be applied.

If it does not correct the existing x86 issues (no code segment limit 
tests and no explicit handling of code fetch exceptions in the 
translation phase in VLE case) I see no advantage in commiting it in its 
current form.

Regards,

Fabrice.