Re: bitshift of int8, int16, etc?

[David Bateman]

John W. Eaton wrote:
> On 25-Jun-2007, David Bateman wrote:
>
> | The fact is that as matlab doesn't
> | implement this yet, whatever we choose to do will be wrong in any case
> | and need modifying in the long run. So simple is probably better..
>
> In that case, the simplest (or at least "safest") thing is probably to
> just disable these operations and wait.
>   
They are already there, they just behave incorrectly for signed
integers, overflow and have a behavior that is dependent on the compiler
for right shifts of negative values for signed integers.

> But if you want to keep these operators, then I think we should
> definitely avoid doing anything where the behavior is dependent on the
> implementation of the C compiler. 
The patch I supplied makes the operators non compiler dependent and
implement a strict twos complement arithmetic shift.

>  If you want to try to define and
> implement additional behavior that is not defined by the C standard,
> then I don't think I can be of much help because I don't normally use
> these operators, though I would note that in C++, the program
>
>   #include <iostream>
>   int
>   main (void)
>   {
>     unsigned char x = 255;
>     std::cerr << (x << 1) << std::endl;
>     return 0;
>   }
>
> prints 510, but I'm not sure that's a behavior we would want since
> other operations on intX types saturate.
>   
However, the same with the code.

#include <iostream>
#include <inttypes.h>

#define T uint8_t

int main (int argc, char **argv)
{
  T a = atoi(argv[1]);
  int shift = atoi(argv[2]);
  T b;
  if (shift > 0)
    b = (a << shift);
  else
    if (a < 0)
      b = -(((-a) >> -shift) & std::numeric_limits<T>::max());
    else
      b = (a >> -shift);
  std::cerr << static_cast<double>(b) << std::endl;
}

prints "254". This is closer to what we are actually implementing and
makes sense in a strict arithmetic shift. Enforcing saturation will be
harder, so I'm inclined at least till matlab does something one way or
the other to just make it do a strict arithmetic shift on a twos
complement representation independent of the compiler, which is what the
patch I supplied does..

Cheers
David



> jwe
>
>
>   


-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary