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 <[email protected]> > --- > 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~
