Re: [Qemu-devel] qemu vs gcc4

[Rob Landley]

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