[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bitshift of int8, int16, etc?
From: |
David Bateman |
Subject: |
Re: bitshift of int8, int16, etc? |
Date: |
Tue, 26 Jun 2007 09:49:44 +0200 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060921) |
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
- Re: bitshift of int8, int16, etc?, (continued)
- Re: bitshift of int8, int16, etc?, David Bateman, 2007/06/25
- Re: bitshift of int8, int16, etc?, Daniel J Sebald, 2007/06/25
- Re: bitshift of int8, int16, etc?, David Bateman, 2007/06/25
- Re: bitshift of int8, int16, etc?, Daniel J Sebald, 2007/06/25
- Re: bitshift of int8, int16, etc?, Søren Hauberg, 2007/06/25
- Re: bitshift of int8, int16, etc?, John W. Eaton, 2007/06/25
- Re: bitshift of int8, int16, etc?, Daniel J Sebald, 2007/06/25
- Re: bitshift of int8, int16, etc?, John W. Eaton, 2007/06/25
- Re: bitshift of int8, int16, etc?, Daniel J Sebald, 2007/06/25
- Re: bitshift of int8, int16, etc?, John W. Eaton, 2007/06/25
- Re: bitshift of int8, int16, etc?,
David Bateman <=
- Re: bitshift of int8, int16, etc?, John W. Eaton, 2007/06/27