I am considering compiling a 64-bit version of Simutrans-Experimental for the Windows platform if I can, and I am wondering whether the base Simutrans code has any problems for 64-bit compatibility. In particular, I notice that there is a possible problem with the pointer hashtable: the hashing function just returns a 32-bit unsigned integer cast of the pointer, which works on 32-bit systems, but not on 64-bit systems, since 64-bit systems (using 64-bit applications) have 64-bit pointers.
Are there any other issues like this, does anyone know? Are there serious migration issues to a fully 64-bit build?
A hastable cannot fail. Double keys are no problem, since anyway this value will be divided by 111 and the remaning number is taken for hashing. For the actual comparison long is used, which should be large enough for a point on any system according to C++99 standards, as far as I know.
The most serious issue may be the different systax for default int and long types of MSVC and gcc. What size is int on MSVC 64bit?
For simutrans using 64Bit is not helpful, since there will be a lot misalignments of structures. Also the map will be 30% more memory consuming (meaning more meory to be streamed through the processore, i.e. slow total speed).
Ahh, so you're saying that it will work better when compiled as 32-bit? The main reason that I am looking into it was because some 64-bit Linux users reported instability with Simutrans-Experimental...
Edit: Incidentally, in Windows and Linux (GCC), int is 32-bit on a 64-bit platform. There are some platforms on which int is 64-bit. The real problem is not so much int as long, which is 32-bit on Windows 32-and 64-bit, but 64-bit on Linux (GCC) 64-bit, while being 32-bit on Linux (GCC) 32-bit.
long must be 64 bit on Windows64 (unfourtunately only the german page clear states this?). Everything else is a violation of the standard. I rather suspect int to be different. Since size_t returns a 64 bit values long must be 64bit. (Since you can define arrays >4GB with x64 architekture compilers).
On DOS, long could be even 16 bit, since the maximum size of a segment was 65536 bytes, and thus sizeof(void*)>sizeof(long). But for all flat memory models (as used with todays architectures) the definition that sizeof(DATA)<=largest long number automatically implies that on 64Bit OS long is 64bit.
The information on 64-bit types I obtained here (http://en.wikipedia.org/wiki/64-bit#Specific_data_models).
Wonderful, Microsoft seems to indeed to violate the C++ standard that requires size_t<=long ... The only portable way seems to be to cast to size_t then. (http://www.viva64.com/content/articles/64-bit-development/?f=Optimization.html&lang=en&content=64-bit-development)
Casting - that's not good for performance, is it?
Casting to size_t is actually a no-op, since the data are identical.
Ahh, I see, interesting.