Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: using bitwise shift operators on negative signed values

Re: using bitwise shift operators on negative signed values

From: David Bryant <dbryant_at_impulse.net>
Date: Thu, 11 Aug 2005 10:47:14 -0700

I would not worry about this too much. For right-shifting negative signed
values, the propagation of the sign bit is pretty much universal. I have
seen one compiler (for an ST micro) that did not have this as the default
behavior, but even then there was a switch to enable it.

Also, it's not just dsp.c that depends on this. I'm sure the codecs are full
of these, and I know for a fact that WavPack is (and it has been ported okay
to many platforms). I suspect that changing this code to not rely on sign
propagation would be very burdensome and also result in a big performance
hit.

The problem with left-shifting is overflow, and the code should probably be
written so that does not happen by design. Assuming that a left-shifted
negative value would stay negative even on overflow would be non-portable.

David

----- Original Message -----
From: "Frederic Devernay"
To: "Rockbox development"
Sent: Thursday, August 11, 2005 8:32 AM
Subject: using bitwise shift operators on negative signed values


> While reading the code in dsp.c, I was wondering what really was the
result of
> using bitwise shift operators (<< and >>) on negative signed values... It
seems
> from the rockbox code that we assume the sign bit is left untouched (am I
right?).
>
> I just took a look at the C99 standard, and it says (section 6.5.7):
>
> "The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
are
> filled with zeros. If E1 has an unsigned type, the value of the result is
> E1*2^E2, reduced modulo one more than the maximum value representable in
the
> result type. If E1 has a signed type and nonnegative value, and E1 *2^E2
is
> representable in the result type, then that is the resulting value;
otherwise,
> the behavior is *undefined*.
>
> The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an
> unsigned type or if E1 has a signed type and a nonnegative value, the
value of
> the result is the integral part of the quotient of E1 divided by the
quantity, 2
> raised to the power E2. If E1 has a signed type and a negative value, the
> resulting value is *implementation-defined*."
>
> This means that much of the code in dsp.c is probably non-portable and may
break
> when moving to another compiler or platform...
>
> Any thoughts on that?
>
> Fred
> _______________________________________________
> http://cool.haxx.se/mailman/listinfo/rockbox
>

_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2005-08-11

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy