From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50903)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1XzX68-0000Jl-La
	for qemu-devel@nongnu.org; Fri, 12 Dec 2014 15:46:06 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1XzX62-0002lQ-ND
	for qemu-devel@nongnu.org; Fri, 12 Dec 2014 15:46:00 -0500
Received: from mail-qa0-x230.google.com ([2607:f8b0:400d:c00::230]:53633)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1XzX62-0002lJ-It
	for qemu-devel@nongnu.org; Fri, 12 Dec 2014 15:45:54 -0500
Received: by mail-qa0-f48.google.com with SMTP id v10so5662120qac.21
	for <qemu-devel@nongnu.org>; Fri, 12 Dec 2014 12:45:54 -0800 (PST)
Sender: Richard Henderson <rth7680@gmail.com>
Message-ID: <548B53FD.6020000@twiddle.net>
Date: Fri, 12 Dec 2014 12:45:49 -0800
From: Richard Henderson <rth@twiddle.net>
MIME-Version: 1.0
References: <1418405504-11175-1-git-send-email-kbastian@mail.uni-paderborn.de>
	<1418405504-11175-6-git-send-email-kbastian@mail.uni-paderborn.de>
In-Reply-To: <1418405504-11175-6-git-send-email-kbastian@mail.uni-paderborn.de>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 5/8] target-tricore: Add instructions of RR
 opcode format, that have 0x4b as the first opcode
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: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>, qemu-devel@nongnu.org

On 12/12/2014 09:31 AM, Bastian Koppelmann wrote:
> +uint32_t helper_parity(target_ulong r1)
> +{
> +    uint32_t ret;
> +    uint32_t nOnes, i;
> +
> +    ret = 0;
> +    nOnes = 0;
> +    for (i = 0; i < 8; i++) {
> +        ret ^= (r1 & 1);
> +        r1 = r1 >> 1;
> +    }
> +    /* second byte */
> +    nOnes = 0;
> +    for (i = 0; i < 8; i++) {
> +        nOnes ^= (r1 & 1);
> +        r1 = r1 >> 1;
> +    }
> +    ret |= nOnes << 8;
> +    /* third byte */
> +    nOnes = 0;
> +    for (i = 0; i < 8; i++) {
> +        nOnes ^= (r1 & 1);
> +        r1 = r1 >> 1;
> +    }
> +    ret |= nOnes << 16;
> +    /* fourth byte */
> +    nOnes = 0;
> +    for (i = 0; i < 8; i++) {
> +        nOnes ^= (r1 & 1);
> +        r1 = r1 >> 1;
> +    }
> +    ret |= nOnes << 24;
> +
> +    return ret;
> +}
> +

Probably doesn't matter much, but

  ret = (ctpop8(r1) & 1)
        | ((ctpop8(r1 >> 8) & 1) << 8)
        | ((ctpop8(r1 >> 16) & 1) << 16)
        | ((ctpop8(r1 >> 24) & 1) << 24);

One could also make a case for adding new helpers that
use __builtin_parity rather than __builtin_popcount.

I usually like to look at things like this and see how
the general infrastructure can be improved...

Otherwise,

Reviewed-by: Richard Henderson <rth@twiddle.net>


r~