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.

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

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.

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
>

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

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