From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53773 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pcntu-0008IR-Qq for qemu-devel@nongnu.org; Tue, 11 Jan 2011 18:45:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pcntt-0006MN-Qz for qemu-devel@nongnu.org; Tue, 11 Jan 2011 18:45:18 -0500 Received: from hall.aurel32.net ([88.191.126.93]:40328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pcntt-0006Le-LL for qemu-devel@nongnu.org; Tue, 11 Jan 2011 18:45:17 -0500 Date: Wed, 12 Jan 2011 00:45:15 +0100 From: Aurelien Jarno Subject: Re: [Qemu-devel] [PATCH 0/7] Define "deposit" tcg operation, v2 Message-ID: <20110111234515.GD22287@hall.aurel32.net> References: <1294716228-9299-1-git-send-email-rth@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1294716228-9299-1-git-send-email-rth@twiddle.net> Sender: Aurelien Jarno List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel@nongnu.org, agraf@suse.de On Mon, Jan 10, 2011 at 07:23:41PM -0800, Richard Henderson wrote: > Changes since v1: > * No attempt to pack pos+len into one operand. Updated backends > to match this change. > > * Example in the README is a bit more complex. > > * Define an official tcg_scratch_alloc routine, used by the i386 > target for the case in which we need a scratch register. I had > said that triggering this wasn't possible with mainline, but I > was wrong. The rlwimi example I posted in the other thread hits > this case. > > Aurelien suggested using a shorter name like "dep", but I think that > would be more confusing than not. This opcode is not really used > enough to warrent cropping 4 characters, in my opinion. > It was just a suggestion, I am also fine with "deposit". The implementation of the deposit op (that is the first patch) looks fine to me, and I am convince this new op is useful. It's probably going to be useful for the s390 target, that tried to solve the same problem with a sync op. To go further, I think we should split the patch series into two (no need to resend it), the op itself, and the implementation/usage in various host/targets. The latter can go part by part, so the various persons can review them separately. The whole series is still useful anyway to see the potential of such a new op. Even if the code for the new op is quite simple, adding a new op has some consequences (the main one being is that it's difficult to remove it latter), so I propose that it is reviewed/acked by a few persons before being committed. People, please do that or send your comments. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net