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 _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
