missing integer cast when applied to bitwise expression - VxWorks

This is a discussion on missing integer cast when applied to bitwise expression - VxWorks ; Recently , I found a problem dealing with the integer cast in expression with bitwise operator with windriver diab compiler 5.5 and gnu both. For example, the following code unsigned short x; float re; x = 0x418; re = (int)(x ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: missing integer cast when applied to bitwise expression

  1. missing integer cast when applied to bitwise expression

    Recently , I found a problem dealing with the integer cast in
    expression with bitwise operator with windriver diab compiler 5.5 and
    gnu
    both.
    For example, the following code
    unsigned short x;
    float re;
    x = 0x418;
    re = (int)(x<<21)/0x200000;
    the result should be negative.
    however, the result from the vxWorks is 1056, a positive one.
    Anyone have encountered the same problem.
    Pls give some advice.

  2. Re: missing integer cast when applied to bitwise expression

    Are you sure that this is a problem with integer cast, and not a case
    of the compiler optimizing your code?

    x << 21 would be mathematically equivalent to x * 0x200000.

    Since you are also dividing by 0x200000, the compiler could be
    deciding that since 0x200000 / 0x200000 is 1, it can get away without
    doing either the multiplication of division at runtime. Therefore, it
    could then be typecasting 0x418, which is not a negative value.

    I would recommend checking the code that the compiler generates
    using ...
    objdump -d , where = {arm,
    mips, ppc, sh, pentium}

    Peter Mitsis

    ganyong wrote:
    > Recently , I found a problem dealing with the integer cast in
    > expression with bitwise operator with windriver diab compiler 5.5 and
    > gnu
    > both.
    > For example, the following code
    > unsigned short x;
    > float re;
    > x = 0x418;
    > re = (int)(x<<21)/0x200000;
    > the result should be negative.
    > however, the result from the vxWorks is 1056, a positive one.
    > Anyone have encountered the same problem.
    > Pls give some advice.


  3. Re: missing integer cast when applied to bitwise expression

    On 3 Giu, 14:55, ganyong wrote:
    > Recently , I found a problem dealing with the integer cast in
    > expression with bitwise operator with windriver diab compiler 5.5 and
    > gnu
    > both.
    > For example, the following code
    > unsigned short x;
    > float re;
    > x = 0x418;
    > re = (int)(x<<21)/0x200000;
    > the result should be negative.
    > however, the result from the vxWorks is 1056, a positive one.
    > Anyone have encountered the same problem.
    > Pls give some advice.


    I'm not sure if I really get the point of your code but AFAIK, a short
    is 16 bit. In your code, you first shift x, losing all the meaningful
    digits because it overflows. What you cast to int is something
    undefined, so this is maybe the problem.
    I'd rather write

    re = ( ( (int)x ) << 21 )/ 0x200000

    But anyway I don't see why you have to use a short int when you could
    just use an unsigned int and avoid the cast at all.

    Bye,

    Giacomo


  4. Re: missing integer cast when applied to bitwise expression

    On 6月4日, 下午3时18分, "benelli.giac...@gmail.com"
    wrote:
    > On 3 Giu, 14:55, ganyong wrote:
    >
    > > Recently , I found a problem dealing with the integer cast in
    > > expression with bitwise operator with windriver diab compiler 5.5 and
    > > gnu
    > > both.
    > > For example, the following code
    > > unsigned short x;
    > > float re;
    > > x = 0x418;
    > > re = (int)(x<<21)/0x200000;
    > > the result should be negative.
    > > however, the result from the vxWorks is 1056, a positive one.
    > > Anyone have encountered the same problem.
    > > Pls give some advice.

    >
    > I'm not sure if I really get the point of your code but AFAIK, a short
    > is 16 bit. In your code, you first shift x, losing all the meaningful
    > digits because it overflows. What you cast to int is something
    > undefined, so this is maybe the problem.
    > I'd rather write
    >
    > re = ( ( (int)x ) << 21 )/ 0x200000
    >
    > But anyway I don't see why you have to use a short int when you could
    > just use an unsigned int and avoid the cast at all.
    >
    > Bye,
    >
    > Giac


    In fact, the code will be like this;
    re =(float)((int)(x<<21)/0x200000 * 0.0025;
    In this way, the precision of re will be 0.0025.

    I've also tried the way you suggested, but I still get the same
    result.




  5. Re: missing integer cast when applied to bitwise expression

    At first, I also thought it may be the problem of complier
    optimization.
    However, I have defined the complier option as DEBUG.
    There will not be any optimization in the generated code.
    so, I am wondering whether it is the problem of WINDRIVER compiler.

    In fact, I want to port the code from sparc architecture to Intel.
    The code works fine under sparc gnu compiler.
    However, it doesn't work under WINDRIVER compiler(diab) and gnu
    compiler provided by WINDRIVER.


    On 6月3日, 下午10时14分, peter.mit...@gmail.com wrote:
    > Are you sure that this is a problem with integer cast, and not a case
    > of the compiler optimizing your code?
    >
    > x << 21 would be mathematically equivalent to x * 0x200000.
    >
    > Since you are also dividing by 0x200000, the compiler could be
    > deciding that since 0x200000 / 0x200000 is 1, it can get away without
    > doing either the multiplication of division at runtime. Therefore, it
    > could then be typecasting 0x418, which is not a negative value.
    >
    > I would recommend checking the code that the compiler generates
    > using ...
    > objdump -d , where = {arm,
    > mips, ppc, sh, pentium}
    >
    > Peter Mitsis
    >


  6. Re: missing integer cast when applied to bitwise expression

    On 8 Giu, 10:49, ganyong wrote:
    > At first, I also thought it may be the problem of complier
    > optimization.
    > However, I have defined the complier option as DEBUG.
    > There will not be any optimization in the generated code.
    > so, I am wondering whether it is the problem of WINDRIVER compiler.
    >
    > In fact, I want to port the code from sparc architecture to Intel.
    > The code works fine under sparc gnu compiler.
    > However, it doesn't work under WINDRIVER compiler(diab) and gnu
    > compiler provided by WINDRIVER.
    >
    > On 6月3日, 下午10时14分, peter.mit...@gmail.com wrote:
    >
    > > Are you sure that this is a problem with integer cast, and not a case
    > > of the compiler optimizing your code?

    >
    > > x << 21 would be mathematically equivalent to x * 0x200000.

    >
    > > Since you are also dividing by 0x200000, the compiler could be
    > > deciding that since 0x200000 / 0x200000 is 1, it can get away without
    > > doing either the multiplication of division at runtime. Therefore, it
    > > could then be typecasting 0x418, which is not a negative value.

    >
    > > I would recommend checking the code that the compiler generates
    > > using ...
    > > objdump -d , where = {arm,
    > > mips, ppc, sh, pentium}

    >
    > > Peter Mitsis


    My best advice is to split your expression into several simpler
    operations and check the intermediate results.
    Your line of code

    >>re = (int)(x<<21)/0x200000;


    hides a lot of compiler operations the problem hard to understand.
    Just do it one step at the time.
    Example:

    int x;
    x = 0x418;
    x<<=21;
    printf ("after the left shift, x is %08x", x); // Check the value of
    X. Should be 0x83000000!
    // Then check the value of the division etc...

    "Divide et impera", the Romans said Bye!

    Giacomo

  7. Re: missing integer cast when applied to bitwise expression

    But have you actually disassembled the code that the compiler
    creates? From where I stand, if you are going to start questioning
    the compiler, you had better verify for yourself what it has
    generated, and compare it to what you expect. Secondly, if you are
    already questionning the compiler, it does not really make sense to
    assume that if you use the DEBUG option that it will do as you
    expect. Thirdly, since you are changing compilers, AND the compiled
    code does not work between the two, it makes sense to check the
    output. What is different? Can you match the assembly to the C
    code? What version is the sparc gnu compiler? What version for the
    Wind River gnu compiler?

    To minimize possible differences that could arise when compiling for
    different processors, you can compile (if using WR's build
    infrastructure) with "make CPU=SIMSPARCSOLARIS TOOL=gnu" or "make
    CPU=SIMSPARCSOLARIS TOOL=diab".

    Peter

    On Jun 8, 4:44 am, ganyong wrote:On Jun 8,
    4:49 am, ganyong wrote:
    > At first, I also thought it may be the problem of complier
    > optimization.
    > However, I have defined the complier option as DEBUG.
    > There will not be any optimization in the generated code.
    > so, I am wondering whether it is the problem of WINDRIVER compiler.
    >
    > In fact, I want to port the code from sparc architecture to Intel.
    > The code works fine under sparc gnu compiler.
    > However, it doesn't work under WINDRIVER compiler(diab) and gnu
    > compiler provided by WINDRIVER.
    >
    > On 6月3日, 下午10时14分, peter.mit...@gmail.com wrote:
    >
    > > Are you sure that this is a problem with integer cast, and not a case
    > > of the compiler optimizing your code?

    >
    > > x << 21 would be mathematically equivalent to x * 0x200000.

    >
    > > Since you are also dividing by 0x200000, the compiler could be
    > > deciding that since 0x200000 / 0x200000 is 1, it can get away without
    > > doing either the multiplication of division at runtime. Therefore, it
    > > could then be typecasting 0x418, which is not a negative value.

    >
    > > I would recommend checking the code that the compiler generates
    > > using ...
    > > objdump -d , where = {arm,
    > > mips, ppc, sh, pentium}

    >
    > > Peter Mitsis



+ Reply to Thread