qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu vs gcc4


From: Paul Brook
Subject: Re: [Qemu-devel] qemu vs gcc4
Date: Wed, 1 Nov 2006 17:01:59 +0000
User-agent: KMail/1.9.5

On Wednesday 01 November 2006 16:34, Rob Landley wrote:
> 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?

Generating code instead in blindly glueing together precompiled fragments.

> > > 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.)

I suspect it's more to do with due diligence on our part. While it might not 
have any legal meaning on its own, it makes it much harder for people to 
claim they infringed copyright accidentally. 

> > 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...

Ys, or when only some flags are used. eg:

 add %eax, %ebx
 adc %cex, %edx

The adc instruction only uses the carry flag, then clobbers all the rest. A 
naive implementation would evaluate all the flags after the add. With Lazy 
evaluation we evaluate just the carry flag before the adc, and know we don't 
have to bother calculating the other flags. It also avoids having to evaluate 
the flags at a TB boundary.

> > > 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.

The difference is whether qemu knows how to generate code for that target, or 
is blindly glueing binary blobs together.

Paul




reply via email to

[Prev in Thread] Current Thread [Next in Thread]