News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

64-bit compatibility

Started by jamespetts, May 13, 2009, 01:54:27 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

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).

jamespetts

#2
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

#3
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.

jamespetts

The information on 64-bit types I obtained here.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

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)

jamespetts

Casting - that's not good for performance, is it?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

Casting to size_t is actually a no-op, since the data are identical.

jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.