qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefano Bonifazi <stefboombastic@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Raphaël Lefèvre" <taylor.lefevre@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] TCG flow vs dyngen
Date: Mon, 24 Jan 2011 15:56:52 +0100	[thread overview]
Message-ID: <4D3D9334.6050801@gmail.com> (raw)
In-Reply-To: <AANLkTink8XAihqscqOgCt6_L3pKahzV3A5PF8=hE9Njj@mail.gmail.com>

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.

  reply	other threads:[~2011-01-24 14:57 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-16 14:46 [Qemu-devel] TCG flow vs dyngen Raphael Lefevre
2011-01-16 15:21 ` Stefano Bonifazi
2011-01-16 16:01   ` Raphaël Lefèvre
2011-01-16 16:43     ` Stefano Bonifazi
2011-01-16 18:29       ` Peter Maydell
2011-01-16 19:02         ` Stefano Bonifazi
2011-01-16 19:24           ` Peter Maydell
2011-01-24 13:20             ` [Qemu-devel] " Stefano Bonifazi
2011-01-16 20:50           ` [Qemu-devel] " Stefano Bonifazi
2011-01-16 21:08             ` Raphaël Lefèvre
2011-01-24 12:35               ` [Qemu-devel] " Stefano Bonifazi
2011-01-17 11:59             ` [Qemu-devel] " Lluís
2011-01-24 12:31               ` [Qemu-devel] " Stefano Bonifazi
2011-01-24 13:36                 ` Lluís
2011-01-24 14:00                   ` Stefano Bonifazi
2011-01-24 15:06                     ` Lluís
2011-01-24 17:23                       ` Stefano Bonifazi
2011-01-24 18:12                         ` Lluís
2011-01-16 19:16       ` [Qemu-devel] " Raphaël Lefèvre
2011-01-23 21:50     ` Rob Landley
2011-01-23 22:25       ` Stefano Bonifazi
2011-01-23 23:40         ` Rob Landley
2011-01-24 10:17           ` Stefano Bonifazi
2011-01-24 18:20             ` Rob Landley
2011-01-24 21:16               ` Stefano Bonifazi
2011-01-25  1:19                 ` Rob Landley
2011-01-25  8:53                   ` Stefano Bonifazi
2011-01-24 14:32       ` Peter Maydell
2011-01-24 14:56         ` Stefano Bonifazi [this message]
2011-01-24 15:15           ` Lluís
2011-01-24 18:02           ` Dushyant Bansal
2011-01-24 19:38             ` Stefano Bonifazi
2011-01-25  7:56               ` Dushyant Bansal
2011-01-25  9:04                 ` Stefano Bonifazi
2011-01-25  9:05                   ` Edgar E. Iglesias
2011-01-25  9:28                     ` Stefano Bonifazi
  -- strict thread matches above, loose matches on Subject: below --
2010-12-10 21:26 Stefano Bonifazi
2010-12-11 11:02 ` Blue Swirl
2010-12-11 12:29   ` Stefano Bonifazi
2010-12-11 13:11     ` Blue Swirl
2010-12-11 14:32       ` Stefano Bonifazi
2010-12-11 14:44         ` Blue Swirl
2010-12-14 20:17           ` Stefano Bonifazi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D3D9334.6050801@gmail.com \
    --to=stefboombastic@gmail.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=taylor.lefevre@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).