06-02-10 - Some random Win64 junk

To build x64 on the command line, use

vcvarsall.bat amd64

Oddly the x64 compiler is still in "c:\program files (x86)" , not "c:\program files" where it's supposed to be. Also there's this "x86_amd64" thing, I was like "WTF is that?" , it's the cross-compiler to build x64 apps from x86 machines.

amd64 is a synonym for x64. IA64 is Itanium.

The actual "CL" command line to build x64 vs x86 can stay unchanged I think (not sure about this yet). For example you still link shell32.lib , and you still define "WIN32".

Another nasty case where 64 bit bytes your ass is in the old printf non-typed varargs problem. If you use cblib/safeprintf this shouldn't be too bad. Fucking printf formatting for 64 bit ints is not standardized. One nice thing on MSVC is you can use "%Id" for size_t sized things, so it switches between 32 and 64. For real 64 bit use "%I64d" (on MSVC anyway).

size_t really fucking annoys me because it's unsigned. When I do a strlen() I almost always want that to go into a signed int because I'm moving counters around that might go negative. So I either have to cast or I get tons of warnings. Really fucking annoying. So I use my own strlen32 and anyone who thinks I will call strlen on a string greater than 2 GB is smoking some crack.

Here are the MSC vers :

MSVC++ 9.0  _MSC_VER = 1500
MSVC++ 8.0  _MSC_VER = 1400
MSVC++ 7.1  _MSC_VER = 1310
MSVC++ 7.0  _MSC_VER = 1300
MSVC++ 6.0  _MSC_VER = 1200
MSVC++ 5.0  _MSC_VER = 1100

Some important revs : "volatile" changes meaning in ver 1400 ; most of the intrinsics show up in 1300 but more show up in 1400. Template standard compliance changes dramatically in 1400.


Scott Graham said...

I think x64 cl is in the right place, the compiler is still a 32 bit app, it just cross-compiles to x64.

cbloom said...

"I think x64 cl is in the right place, the compiler is still a 32 bit app, it just cross-compiles to x64. "

I don't think so. The one in x86_amd64 is a cross-compiler. The one in "amd64" is native 64 bit.

Anonymous said...

Unsigned integers are wrong for just about anything except if you're doing bit operations.

My go-to demonstration of this is what happens when someone gives you an unsigned N and you want to do a for loop. for(uint x=0; x < N; ++x) does what you want for increasing, but for decreasing, for(uint x=N-1; x >= 0; --x) does not, instead you have to do crap with postdecrements in the comparison or something.

Anonymous said...

Which means you really want the loop index to be signed, which means you really want the variables you're comparing it to or initializing it from to be signed.

castano said...

what about this?

for(uint x=N-1; x < N; --x)

one of the nice things about unsigned variables is that when the valid range is [0, N] you only have to do one comparison to check whether the value is inside.

old rants