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

[Peter Maydell]

On 27 June 2013 18:58, Markus Armbruster <address@hidden> wrote:
> Peter Maydell <address@hidden> writes:
>> 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).)
>
> If you have sextractN(), then sextN(v, l) == sextractN(v, 0, l), isn't
> it?  I'd expect even a moderately competent optimizer to optimize such
> uses of sextractN() just as well as your sextN().

Good point. I think that biases in favour of just implementing
sextractN().

>> +static inline int32_t sext32(uint32_t value, int length)
>> +{
>> +    /* Note that this implementation relies on right shift of signed
>> +     * integers being an arithmetic shift.
>> +     */
>> +    return ((int32_t)(value << (32 - length))) >> length;
>> +}
>
> Err, shouldn't you shift right by (32 - length), too?

Doh. I said I hadn't tested this ;-)

> Here's sextract32(), not even compile-tested:
>
> static inline int32_t sextract32(uint32_t value, int start, int length)
> {
>     return ((int32_t)(value << (32 - length - start))) >> (32 - length);
> }

Looks plausible. We should probably add in the assert() from
extract32().

thanks
-- PMM