Rockbox mail archiveSubject: 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
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.
----- 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
> using bitwise shift operators (<< and >>) on negative signed values... It
> from the rockbox code that we assume the sign bit is left untouched (am I
> 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
> 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
> result type. If E1 has a signed type and nonnegative value, and E1 *2^E2
> representable in the result type, then that is the resulting value;
> 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
> the result is the integral part of the quotient of E1 divided by the
> 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
> when moving to another compiler or platform...
> Any thoughts on that?
Received on 2005-08-11