> > I was up until 3:00am studying Qemu, and I came to the conclusion > that > > it doesn't make sense to try speeding up the output code, at least > not > > yet. A peephole optimizer or hand-coded sequences made to handle > common > > combinations of instructions would lead to the problems discussed > here: > > exceptions happening at the right time, self-modifying code, etc. > > Well yeah... I didn't say it would be easy :-)
I would like to suggest that perhaps it would be useful to experiment anyway. Self-modifying code cannot be that prevalent (unless you are a virus writer - which, yes, means that probably any standard Windows installation of any maturity would stop working ;-), exceptions are potentially more dangerous and branching into a translated blocks would need to be dealt with by (probably) retranslating on an instruction-by-instruction level and then allowing the branch to occur into the traditional translation. At any rate, making this a compile-time (or even runtime) option would allow for basic experimentation. Until we can go from instruction translation to logic translation, this system will never fullfill it's potential. Instruction translation can maintain the property of system correctness, which is indeed broken by logic translation (e.g. perhaps exceptions don't occur when they normally would, or need to be handled and translated resulting in slightly different behavior). However, I would like to assert that with the proper balance and approach, exact system correctness may not be strictly neccessary (I am thinking of certain exception cases) and logic translation has the potential to be wickidly faster (if the PPC can do something in 6 steps that takes an x86 15 steps, but there is an outside chance of a division by zero exception, why do it in 87 steps? Shouldn't we at least try to see if we can make it work in 6? or 12?). > > Worse, the translator might have to spend so much time doing this > that > > the result would actually be slower execution. > > Not if you do it right. Remember. by and large you only incur a > one-time > hit, and after that you're going as fast as your dynamic translator > is > smart. > > Here's a heuristic for you: optimize for the general case, not corner > cases. You still have to handle the corner cases, but they are corner > cases for a reason: you don't run into them as often. Exactly, as I hinted at in a previous post, it may turn out that some sequence of (for example) 5 instructions is so common in all software that the act of hand coding a replacement for those 5 instructions could result in a noticible overall performance improvement. And then you can start scaling the performance up from there. I will guarantee that we can find some sequences that do not have problems with exceptions that would be candidates (guaranteeing on branch and self-modifying is not as easy). But not to try? -Daniel _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel