On 5/19/05, Thomas Steffen <[EMAIL PROTECTED]> wrote: > It as also because C avoids the n by m problem. >
My point is that you can have your cake and eat it too. For any given architecture gcc can generate the first approximation by way of dyngen or dyngen + gcc enhancements. But once you are past that point gcc for a given arch, gcc isn't really going to help you any more. So bring on the hand coding/optimizations. There's no doubt the hand coded stuff would be at least as good as gcc output. And that's because you can always make use of what gcc did if you can't think of anything better. There's really nothing magic going on we're in any danger of losing. QEMU generates a dynamic code generator dynamically. Clever but lucky hack, in that it really has no business working (yet it does, but the lucky part is why it is going to continue to break). Short of collusion from the gcc folks, I'm saying that it is no less than the Halting Problem that is staring us in the face here. But no more than that either. Practically speaking, we can probably go on like this indefinitely, it just seems unnecessary to me. The thing that separates QEMU from other projects like Bochs in my mind is that it dynamically generates code and it has other clever bits like samba and slirp integration. A high level view is that QEMU puts a high priority on usability compared to these other projects. _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel