From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZriU-0005zZ-Em for qemu-devel@nongnu.org; Wed, 18 Feb 2009 14:04:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZriS-0005ys-OA for qemu-devel@nongnu.org; Wed, 18 Feb 2009 14:04:17 -0500 Received: from [199.232.76.173] (port=41088 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZriS-0005yn-EU for qemu-devel@nongnu.org; Wed, 18 Feb 2009 14:04:16 -0500 Received: from smtp.mail.umich.edu ([141.211.93.160]:40478 helo=skycaptain.mr.itd.umich.edu) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZriR-0007gG-NR for qemu-devel@nongnu.org; Wed, 18 Feb 2009 14:04:15 -0500 Message-ID: <499C5BAE.40202@gmail.com> Date: Wed, 18 Feb 2009 14:04:14 -0500 From: Andrea Pellegrini MIME-Version: 1.0 Subject: Re: [Qemu-devel] Monitor Memory Accesses References: <499C03A9.6040003@gmail.com> <761ea48b0902180500wbe676d4x3895d37df10e495b@mail.gmail.com> <499C0A81.8090106@gmail.com> <761ea48b0902180526q1be52725x748c7c14b5d907de@mail.gmail.com> <499C2BEF.6010107@gmail.com> <761ea48b0902180752p2e665a07vbb922fb6621a7173@mail.gmail.com> <20090218111027.D27797@stanley.csl.cornell.edu> <499C38F3.9050204@gmail.com> <20090218132622.U28170@stanley.csl.cornell.edu> In-Reply-To: <20090218132622.U28170@stanley.csl.cornell.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 I agree. I only need a basic timing simulation, I can start simply with CPI=1, issue one instruction per clock, assume a perfect branch predictor and calling good for right now. Thanks for the link to the code, I'll take a look at your patch in the afternoon, ~Andrea Vince Weaver wrote: > On Wed, 18 Feb 2009, Andrea Pellegrini wrote: >> nice to talk to you again. I figured that we are trying to do >> basically the same thing. Are you able to use the traces from Qemu >> with Dinero? If so, in case of cache miss, can you stall the >> execution of Qemu for some cycles? > > You can use Qemu to generate traces for Dinero, patches for that were > previously mentioned in this thread. > > Stalling is meaningless though... Qemu is not cycle-accurate. > > If you really want cycle accurate values, you're going to have to feed > the traces from Qemu into a timing simulator. It might be possible to > create a simple mips timing simulator that hooks into Qemu (see my > wddd 2008 paper) but that would involve significant hacking that's not > really related to Qemu development. > > Vince > > > > > >