Mincho Georgiev wrote:long long is not 64 bit integer under x86, rather is 2 32 bit integers, placed by the compiler in separate registers. However, maybe I'm wrong and forgot about it, since it was a long time ago using the vc 6.0, but I'm still pretty sure that 6.0 doesn't support neither __int64 nor unsigned long long types.
P.S. I remembered...
It does support __int64 only, but not unsigned long long. So it is preference dependent, i guess.
In MSVC++ 6.0 the platform-specific types "__int64" and "unsigned __int64" are both available. "long long" and "unsigned long long" are not available yet but the size is the same. With an appropriate portable definition of integer data types you can always use "higher level" types names like int64_t, uint64_t.
To actually get a 64 bit value placed in one 64 bit register by the compiler you need both a 64 bit box *and* a newer compiler, of course.
Sven
That's why I did the upper remark in a first place. It is not "64 bit number"
it's a data type. It's your choice whether to make portable definitions into the compiler's library or in every code that you going to compile, or to download vc++ 2008 and resolve that (plus many other issues) once and for all.
Mincho Georgiev wrote:long long is not 64 bit integer under x86, rather is 2 32 bit integers, placed by the compiler in separate registers. However, maybe I'm wrong and forgot about it, since it was a long time ago using the vc 6.0, but I'm still pretty sure that 6.0 doesn't support neither __int64 nor unsigned long long types.
P.S. I remembered...
It does support __int64 only, but not unsigned long long. So it is preference dependent, i guess.
In MSVC++ 6.0 the platform-specific types "__int64" and "unsigned __int64" are both available. "long long" and "unsigned long long" are not available yet but the size is the same. With an appropriate portable definition of integer data types you can always use "higher level" types names like int64_t, uint64_t.
To actually get a 64 bit value placed in one 64 bit register by the compiler you need both a 64 bit box *and* a newer compiler, of course.
Sven
That's why I did the upper remark in a first place. It is not "64 bit number"
it's a data type. It's your choice whether to make portable definitions into the compiler's library or in every code that you going to compile, or to download vc++ 2008 and resolve that (plus many other issues) once and for all.
Fully agreed. It is not that I would personally favor 6.0 over 2008 for any reason. My arguments in previous posts were only towards being possibly "forced" to use that old environment, and that you can still work at least somehow with it. "Programmer's paradise" clearly does not need or want 6.0, no doubt about that. And for chess programming practically nobody will be forced to use 6.0, this is probably kind of a software industry issue only.
phhnguyen wrote:BTW, does anyone compare VS200x with gcc (in Windows)? Any change for gcc (in term of performance)?
I did so 1 or 2 years ago. gcc on Linux was about 10% slower for my engine than Intel (which was about the same speed on either Linux or Windows) or Microsoft. Intel and Microsoft resulted in about the same speed, Microsoft being marginally faster. However note that for most applications Intel is reported to give the fastest code.
gcc on Cygwin was even much worse than gcc on Linux due to a very old 32 bit version, but that has been fixed in the meantime. Now I would expect gcc on windows to have the same performance as gcc on Linux, i.e 10% behind Microsoft.
