From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gf26s-00057C-Mv for qemu-devel@nongnu.org; Tue, 31 Oct 2006 17:29:30 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gf26p-000516-2v for qemu-devel@nongnu.org; Tue, 31 Oct 2006 17:29:30 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gf26o-00050w-Pp for qemu-devel@nongnu.org; Tue, 31 Oct 2006 17:29:26 -0500 Received: from [193.252.22.31] (helo=smtp-msa-out20.orange.fr) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gf26o-00053g-Mp for qemu-devel@nongnu.org; Tue, 31 Oct 2006 17:29:26 -0500 Received: from [192.168.0.2] (ANice-251-1-3-65.w86-200.abo.wanadoo.fr [86.200.10.65]) by mwinf2023.orange.fr (SMTP Server) with ESMTP id B84B51C00098 for ; Tue, 31 Oct 2006 23:29:24 +0100 (CET) Message-ID: <4547CEA8.9040903@wanadoo.fr> Date: Tue, 31 Oct 2006 23:31:04 +0100 From: Laurent Desnogues MIME-Version: 1.0 Subject: Re: [Qemu-devel] qemu vs gcc4 References: <45391B22.1050608@palmsource.com> <200610311902.21898.paul@codesourcery.com> <200610311541.44532.rob@landley.net> <200610312208.20278.paul@codesourcery.com> In-Reply-To: <200610312208.20278.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Paul Brook a =E9crit : > Replacing the pregenerated blocks with hand written assembly isn't feas= ible.=20 > Each target has its own set of ops, and each host would need its own as= sembly=20 > implementation of those ops. Multiply 11 targets by 11 hosts and you ge= t a=20 > unmaintainable mess :-) Shouldn't you have 11+11 and not 11*11, given your intermediate representation? And of these 11+11, 11 have to be written anyway (target). Or did I miss something? > On RISC targets like ARM most instructions don't set the condition code= s, so=20 > we don't bother doing this. Except for ARM Thumb ISA which always sets flags. ARM is a bad RISC example :) I was wondering if you did some profiling to know how much time is spent in disas_arm_insn. Of course the profiling results would be very different for a Linux boot or a synthetic benchmark (which makes me think that you don't support MMU, do you?). There is a very nice trick to speed up decoding of ARM instructions: pick up bits 20-27 and 4-7 and you (almost) get one instruction per case entry; of course this means using a generator to write the 4096 entries, but the result was good for my interpreted ISS, reaching 44 M i/s on an Opteron @2.4GHz without any compiler dependent trick (such as gcc jump to labels). Laurent