Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

ulong data type behaves as uint using emulator

Hi,

I have a problem with arithmetics using ulong values.

E.g. I try to do something like this (it's an OpenCL code): 

    
ulong A = 0;
A = A - 1;

And I thought I should get 0xffffffffffffffff (64 ones), but I get 0xffffffff (32 ones).

I've seen this code in OPRA example: 

 
unsigned long count = bits;
count = ( count & 0x5555555555555555 ) + ( ( count >> 1 ) & 0x5555555555555555 );

which confirms the ability to work with 64b data types.

On the other hand, when I try unsigned long long, everything works fine. OpenCL documentations states that ulong is a 64b data type, which I got confirmed using size_of(ulong).

I'm currently using emulation (-march=emulator) - could it be the source of the problem?

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Hi,

    What platform (Linux/Windows) and version of the OpenCL compiler are you using? How are you outputting the hex result values (printf in host / printf in kernel)?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I'm using Windows7 and I'm printing them using 

    printf("A: %lx", A);

    both in kernel and on host.

    Edit: Thanks for pointing out the printf function - I should use %llx instead of %lx (although getting an aoc warning).​ Everything works as it should be.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    As I think you figured out, the printf format string is interpreted by the host system because that's where the output ends up. Since Windows systems interpret long as 32b, it was truncating the results when printing with %lx. %llx on Windows should work as expected.