From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57773) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsFAN-0005o2-Iq for qemu-devel@nongnu.org; Thu, 27 Jun 2013 12:35:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UsFAK-0000vf-OQ for qemu-devel@nongnu.org; Thu, 27 Jun 2013 12:35:27 -0400 Received: from mail-yh0-x232.google.com ([2607:f8b0:4002:c01::232]:65485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsFAK-0000vY-KT for qemu-devel@nongnu.org; Thu, 27 Jun 2013 12:35:24 -0400 Received: by mail-yh0-f50.google.com with SMTP id i72so510766yha.23 for ; Thu, 27 Jun 2013 09:35:24 -0700 (PDT) Sender: Richard Henderson Message-ID: <51CC69C7.6020207@twiddle.net> Date: Thu, 27 Jun 2013 09:35:19 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1372348062-4516-1-git-send-email-peter.maydell@linaro.org> In-Reply-To: <1372348062-4516-1-git-send-email-peter.maydell@linaro.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] bitops: Provide sext32() and sext64() for signextending bitfields List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org, patches@linaro.org On 06/27/2013 08:47 AM, Peter Maydell wrote: > A common operation in instruction decoding is to take a field > from an instruction that represents a signed integer in some > arbitrary number of bits, and sign extend it into a C signed > integer type for manipulation. Provide new functions sext32() > and sext64() to abstract away the bit manipulation. > > Signed-off-by: Peter Maydell > --- > I think we've vaguely tossed around the idea of a function to > abstract away the concept of doing a signextension before, > so here's an RFC... > > Does the API look right? The other approach I thought of would > be to have functions sextract32()/sextract64() which work like > the existing extract{32,64} but return signed (and sign > extended) values, but providing the raw sign-extension separately > seemed more flexible. (If we want the sextract ops then we could > implement them as sext32(extract32(value, start, length), length).) Seems sensible. I've been wondering if we should provide tcg-op.h helpers for the same thing -- even without introducing new tcg opcodes yet -- just for clarity in the translators. Though of course, the hosts that tend to provide deposit opcodes also tend to provide extract opcodes... > This implementation continues to rely on the behaviour of right-shift > of signed integers (as do most of the places which open-code this > operation today; see also HACKING section 6). If we decide in future > that we'd rather do this in a strictly-portable way we'll have a > single place we need to change. Fair enough. The patch itself looks good. r~