From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fJMCb-0001Cc-B2 for qemu-devel@nongnu.org; Thu, 17 May 2018 12:56:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fJMCa-0000Na-IG for qemu-devel@nongnu.org; Thu, 17 May 2018 12:56:29 -0400 Received: from mail-ot0-x244.google.com ([2607:f8b0:4003:c0f::244]:35290) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fJMCa-0000NF-CO for qemu-devel@nongnu.org; Thu, 17 May 2018 12:56:28 -0400 Received: by mail-ot0-x244.google.com with SMTP id h8-v6so5839127otb.2 for ; Thu, 17 May 2018 09:56:27 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20180516223007.10256-1-richard.henderson@linaro.org> <20180516223007.10256-27-richard.henderson@linaro.org> From: Peter Maydell Date: Thu, 17 May 2018 17:56:06 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] [PATCH v3-a 26/27] target/arm: Extend vec_reg_offset to larger sizes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: QEMU Developers , qemu-arm On 17 May 2018 at 17:51, Richard Henderson wrote: > On 05/17/2018 08:57 AM, Peter Maydell wrote: >> This looks right for element sizes up to 8, but I don't understand >> how it handles 16 byte elements as the commit message says -- the >> d[0] and d[1] are the wrong way round and don't form a single >> 16-byte big-endian value, so they must need special casing somewhere >> else ? > > You're right that it's not a proper int128 for host arithmetic. Fortunately, > the only operation we have on 128-bit values, at present, is move. > > How better might you word the commit message? You could add in the comment in the function something like: "For 32 byte elements, we return an offset of zero. The two halves will not form a host int128 if the host is bigendian, since they're in the wrong order. However the only 32 byte operation we have is a move, so we can ignore this for the moment. More complicated 32 byte operations would have to special case loading and storing from the zregs array." thanks -- PMM