[FFmpeg-cvslog] r18599 - trunk/libavcodec/xan.c

[Måns Rullgård]

Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> On Fri, Apr 17, 2009 at 09:21:21PM +0100, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> 
>> > On Fri, Apr 17, 2009 at 10:05:27PM +0200, reimar wrote:
>> >> Author: reimar
>> >> Date: Fri Apr 17 22:05:27 2009
>> >> New Revision: 18599
>> >> 
>> >> Log:
>> >> Use sign_extend function instead of reimplementing it.
>> >> 
>> >> Modified:
>> >>    trunk/libavcodec/xan.c
>> >> 
>> >> Modified: trunk/libavcodec/xan.c
>> >> ==============================================================================
>> >> --- trunk/libavcodec/xan.c	Fri Apr 17 22:01:45 2009	(r18598)
>> >> +++ trunk/libavcodec/xan.c	Fri Apr 17 22:05:27 2009	(r18599)
>> >> @@ -333,16 +333,10 @@ static void xan_wc3_decode_frame(XanCont
>> >>              }
>> >>          } else {
>> >>              /* run-based motion compensation from last frame */
>> >> -            motion_x = *vector_segment >> 4;
>> >> -            motion_y = *vector_segment & 0xF;
>> >> +            motion_x = sign_extend(*vector_segment >> 4,  4);
>> >> +            motion_y = sign_extend(*vector_segment & 0xF, 4);
>> >
>> > Someone forgot to document sign_extend, should I be doing the "& 0xF"
>> > or can I assume that any future optimized implementation will flush
>> > the upper bits, too?
>> 
>> What do you mean?  sign_extend() fills the size of an int, whatever
>> that happens to be, typically 32 bits.
>
> Let me say it differently:
> It is not documented if future implementations may assume
> val < (1 << bits)

I would say they may not.

> for example for a fixed value of "bits" and a machine with extremely slow
> shifts and bit operations, someone might have the idea of implementing
> it as
>> if (val & (1 << (bits-1)))
>>     val += ~0 << bits;

If shifts are slow, that's two of them and thus doubly slow.

-- 
M?ns Rullg?rd
mans at mansr.com