From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:56423)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1R8vD6-0008DZ-JB
	for qemu-devel@nongnu.org; Wed, 28 Sep 2011 10:34:09 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1R8vD1-0002yZ-0w
	for qemu-devel@nongnu.org; Wed, 28 Sep 2011 10:34:08 -0400
Received: from david.siemens.de ([192.35.17.14]:25118)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1R8vD0-0002va-D3
	for qemu-devel@nongnu.org; Wed, 28 Sep 2011 10:34:02 -0400
Message-ID: <4E83304F.4010008@siemens.com>
Date: Wed, 28 Sep 2011 16:33:51 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <4E8312D7.4080403@siemens.com> <4E832E88.6080909@twiddle.net>
In-Reply-To: <4E832E88.6080909@twiddle.net>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] tcg-i386: Introduce specific deposit
	helpers
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Henderson <rth@twiddle.net>
Cc: Blue Swirl <blauwirbel@gmail.com>, qemu-devel <qemu-devel@nongnu.org>, Aurelien Jarno <aurelien@aurel32.net>

On 2011-09-28 16:26, Richard Henderson wrote:
> On 09/28/2011 05:28 AM, Jan Kiszka wrote:
>> +#if TCG_TARGET_REG_BITS == 64
>> +    { INDEX_op_deposit8l_i32, { "r", "0", "r" } },
>> +#else
>> +    { INDEX_op_deposit8l_i32, { "abcd", "0", "abcd" } },
>> +#endif
>
> At minimum, abcd is spelled "q".

Ah, perfect.

>
> I don't particularly care for the 3 different opcodes.  Perhaps
> we'd be better off with an inline predicate for when the deposit
> opcode is "valid"?

We still need to dispatch at tcg generation time which variant is valid. 
Or what do you have in mind?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux