Re: [Qemu-devel] [RFC] bitops: Provide sext32() and sext64() for signextending bitfields

[Richard Henderson <rth@twiddle.net>]

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 <peter.maydell@linaro.org>
> ---
> 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~