From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GfJ30-0006XM-Bj for qemu-devel@nongnu.org; Wed, 01 Nov 2006 11:34:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GfJ2y-0006W6-LP for qemu-devel@nongnu.org; Wed, 01 Nov 2006 11:34:37 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GfJ2y-0006Vy-Bs for qemu-devel@nongnu.org; Wed, 01 Nov 2006 11:34:36 -0500 Received: from [71.162.243.5] (helo=grelber.thyrsus.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GfJ2y-00034t-5l for qemu-devel@nongnu.org; Wed, 01 Nov 2006 11:34:36 -0500 From: Rob Landley Subject: Re: [Qemu-devel] qemu vs gcc4 Date: Wed, 1 Nov 2006 11:34:23 -0500 References: <45391B22.1050608@palmsource.com> <200610312051.30749.rob@landley.net> <200611010322.09885.paul@codesourcery.com> In-Reply-To: <200611010322.09885.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611011134.23937.rob@landley.net> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On Tuesday 31 October 2006 10:22 pm, Paul Brook wrote: > > > and glue them together like we do with dyngen. However once you've done > > > that you've implemented most of what's needed for fully dynamic qops, so > > > it doesn't really seem worth it. > > > > I missed a curve. What's "fully dynamic qops"? (There's no translation > > cache?) > > I mean all the qop stuff I've implemented. Still lost. Where does the "fully dynamic" part come in? > > Any idea where I can get a toolchain that can output a "hello world" > > program for m68k nommu? (Or perhaps you have a statically linked "hello > > world" program for the platform lying around?) > > Funnily enough I do :-) > http://www.codesourcery.com/gnu_toolchains/coldfire/ Woot. This download page was designed by your company's legal department, I take it? (There's no such thing as GNU/Linux, and you don't have to accept the GPL because it's based on copyright law, not contract law, so "informed consent" is not the basis for enforcement.) > > > Theoretically possible, but not so easy in practice. Especially when you > > > get things like partial flag clobbers, and lazy flag evaluation. Doing it > > > as a target specific hack is much simpler and quicker. > > > > I think I know what partial flag clobbers are (although if you're working > > your way back, in theory you could handle it with a mask of exposed bits), > > but what's lazy flag evaulation? (I thought that was the point of > > eliminating the unused flag setting. Are you saying the hardware also does > > this and we have to emulate that?) > > Lazy flag evaluation is where you don't bother calculating the actual flags > when executing the flag-setting instruction. Instead you save the > operands/result and compute the flags when you actually need them. Such as when the computation's in a loop but you only test after exiting the loop for other reasons? I'd have to see examples to figure out how it would make sense to optimize that... > > The exponential complexity is if you have to write different code for each > > combination of host and target. If every target disassembles to the same > > set of target QOPs, then you could have a hand-written assembly version of > > each QOP for each host platform, and still have N rather than N^2 of them. > > Right, but by the time you've got everything to use the same set of ops you > may as well teach qemu how to generate code instead of using potted > fragments. I'm thinking of "here's the code for performing this QOP on this processor". I'm not sure what distinction you're making. > Using hand-written assembly fragments probably doesn't make qemu any faster, > it just removes the gcc dependency. Which seems like a good thing to me. (Or at least the gcc _version_ dependency.) > Using qops also allows qemu to generate better (faster) translated code. Currently, I'm interested in building qemu under compiler versions I actually have installed, without having to apply patches that the patch authors consider too disgusting to integrate. > Paul Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery