From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39796 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ObNBW-0005uI-6I for qemu-devel@nongnu.org; Tue, 20 Jul 2010 20:29:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ObNBU-00060g-NY for qemu-devel@nongnu.org; Tue, 20 Jul 2010 20:29:18 -0400 Received: from csmail.cs.umass.edu ([128.119.240.177]:56127) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ObNBU-00060c-IE for qemu-devel@nongnu.org; Tue, 20 Jul 2010 20:29:16 -0400 Message-ID: <4C463F59.6040402@cs.umass.edu> Date: Tue, 20 Jul 2010 20:29:13 -0400 From: Eliot Moss MIME-Version: 1.0 Subject: Re: [Qemu-devel] Automatic generation of code-generator components (RETRY) References: <4C446739.8020301@cs.umass.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: moss@cs.umass.edu List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org On 7/20/2010 6:14 PM, Blue Swirl wrote: > If you keep the development process open, with patches, RFCs and other > proposals flowing regularly to upstream QEMU, I'd suppose the > developer community would welcome this. But there have been several > forks of QEMU and merging those looks hard. The problem with those was > that the development was kept behind a curtain until it was 'finished' > according to some internal standards and then it was presented to us > as something that should just be swallowed in whole. In the continuous > cooperation model the result will be seamless. It's also possible that > there's too much mismatch between the goals of the projects, but with > early involvement of both sides, it can be detected before it's too > late. Yes, I agree that an incremental and open process will work much better. Obviously we'd need to learn the local customs :-) , but I expect we'd start with one or two of the existing guests and hosts, not replacing the current code but doing something like using a different but related name. Among other things, we'd probably want a scheme where we could test our code side by side a known-working version at the start -- an interesting challenge, but perhaps not too hard if we give it some thought. Anyway, yes, it's important not to present something that is a huge change, in one gulp, without experience-building and confidence-building steps in the middle. > I think this case is interesting for the currently unimplemented > hosts, or if the performance is improved from existing hosts compared > to TCG. The extra optimization pass may waste time which will not be > gained back by faster execution time of the better generated code. > There's also KVM, which should be always the fastest for cases where > host and target CPUs match. We can experiment some with different degrees of (simple) optimization, though I expect TCG probably already chose a sweet spot. I am not familiar yet with KVM and should become more so. I gather that it is the case where guest and host are the same, which indeed gives rise to both unique opportunities and unique challenges in performance. However, I remain confident that we can "encode" suitable strategies with our tool. You are right, though, that the most promise is for new ISAs. We probably cannot do much better than TCG front-ends and back-ends tuned by experts. However, the ease of reworking various details may make it easier to tune and possibly do a little better; certainly with new ISAs. > Again, current implementations basically consist of just a huge C > switch statement, so it's hard to improve performance from that. > Enabling new targets would be interesting though, or maybe one day an > automatically generated translator could beat a hand written one. Agreed. Again, thanks for your encouraging reply and your very thoughtful and useful suggestions. I have been pleased to find this a polite community -- sad that not all open source communities are so polite and friendly! Best wishes -- Eliot Moss