From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45207 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhNqn-0000EV-8e for qemu-devel@nongnu.org; Mon, 24 Jan 2011 09:57:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhNqm-00082t-0z for qemu-devel@nongnu.org; Mon, 24 Jan 2011 09:57:01 -0500 Received: from mail-ww0-f53.google.com ([74.125.82.53]:53596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhNql-00082f-Rb for qemu-devel@nongnu.org; Mon, 24 Jan 2011 09:56:59 -0500 Received: by wwi18 with SMTP id 18so4074284wwi.10 for ; Mon, 24 Jan 2011 06:56:59 -0800 (PST) Message-ID: <4D3D9334.6050801@gmail.com> Date: Mon, 24 Jan 2011 15:56:52 +0100 From: Stefano Bonifazi MIME-Version: 1.0 Subject: Re: [Qemu-devel] TCG flow vs dyngen References: <000001cbb58c$221f5a00$011aa8c0@side35ya3cah0n> <4D330D01.9060801@gmail.com> <4D3CA28C.5080907@landley.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: =?UTF-8?B?UmFwaGHDq2wgTGVmw6h2cmU=?= , qemu-devel@nongnu.org On 01/24/2011 03:32 PM, Peter Maydell wrote: > > Being a JIT doesn't prohibit counting target instructions executed. > It just means that counting them generally requires generating > code to do the counting at runtime, so it's a more complicated > change to make than it would be in a non-JIT emulator. > What do you mean? Should I change the code of qemu-user for counting the instructions, or should I add code into the target binaries? > The major reason for not counting cycles is that for an emulation > of a modern CPU this is pretty nearly impossible: the number > of cycles an instruction takes can depend on whether it causes > a cache miss, which CPU internal pipeline it uses, whether it > needs to stall waiting for a result from an earlier insn, whether > the CPU correctly predicted the branch leading up to it or not, > and on and on. You would need to precisely model all the > internals of each variant of each CPU, which would be a > mammoth undertaking requiring probably unpublished internal > data, and if you ever managed to finish it then it would run > incredibly slowly and would probably contain enough bugs you > couldn't trust the data it gave you anyway. > Yup, I think it was just a silly mistake of mine when in the first post I wrote cycles.. that was because for me anything that can estimate how long it takes to do the work would be fine.. I can't simply check the time because that is host machine dependent... Number of executed instructions would be fine.. >> This means that QEMU can >> no longer run on a type of host it can't execute target code for > This isn't correct; for instance there's hppa support in TCG for hppa > hosts but no hppa target support, and there's sh4 target support > but no TCG backend for it. The two ends are cleanly separated in > qemu and don't generally depend on each other. > Well I experienced a strange behavior some time ago that initially made me think mr Rob was right on that though I knew host support and target support were separated in qemu: I tried to make directly qemu-ppc on a x86_64 machine from inside ppc-linux-user folder (i can do fine onto x86 machine) and it failed because there was no tgc/x86_64/tcg_target.h, whereas doing the make from within the main folder worked. So I do not understand very well.. is there some required headers fix when using the main make file? Best regards! Stefano B.