View Single Post
  #7  
Old 06-10-2009, 02:30 PM
gaeorn
Developer
 
Join Date: Apr 2009
Location: USA
Posts: 478
Default

Quote:
Originally Posted by Bulle View Post
It would be unfair to say it is poor programming not to have "natural" 64-bits support. 64-bits support when programming on a 32-bits platform has to be seriously planned in advance, and even then it requires corrections once you switch to the actual 64-bits platform. It is an outstanding effort to support both, C is like that, close to the "machine". If you want hardware indepence, use Java or something else. EQEmu is in C, we have to live with that.
Especially when you consider that development started on this before 64bit microprocessors were available to most people.

Quote:
Problems do not only occur when casting values, but for example when reading binary data from files (ints are not the same size). Cross-processor compatibility support (like in PowerPC vs Intel) could mitigate this problem, but EQEmu on Mac is not really something I have heard of. We have to live with that too !

That said, I will answer the question of gaeorn :
The surefire way to ensure you do not alter 32-bits code when adding changes for 64-bits support is to use #defines. Everytime you need to replace an existing portion of code with your new code you use something like this :
Code:
#ifdef     __64_bits__
<your new code>
#else  /* __64_bits__ */
<the old code>
#endif /* __64_bits__ */
The comments are there for readability (especially if you have tens of lines of code in there), and cost nothing.

Obviously you also have to #define the __64_bits__ macro somewhere when you are on a 64-bits plaform. It can be done on the compile-line with a -D__64_bits__ flag (read : your Makefile). There could be an existing flag for your compile platform but I cannot remember it off-hand. If it exists then just use it instead of my made-up macro.
Yeah, I know about #ifdef. I just was hoping to keep that to a minimum. I'm sure many parts of the code could be written in a way to run happily on both 32bit and 64bit. Only a handful will likely require wrapping with #ifdef blocks for the two architectures.

But, if the developers would prefer me to do all of it as #ifdef blocks, I can. Perhaps KLS or another developer can chime in with their preference.

Quote:
I can remember trying to compile EQEmu for 64-bits a year ago (and succeeding), but running the executables failed miserably with a segmentation fault. Not a surprise really, as the code is not meant to support it. Be warned this can be very tough to fix.
I ran into the same problem. Found it and resolved it. I've done enough changes to my 64bit version that it is very playable in my testing. However, it doesn't have a user population to truly test out everything.

Quote:
One hint : on a 64-bits Linux platform you can always create a chroot 32-bits installation to run your programs with everything 32-bits. That is how I use EQEmu on my (native 64-bits) server. The details vary depending on your distribution, I am on Gentoo and they provide a nice "how-to" on how to create the 32-bits chroot environment. Just know that you will need as much HD space as you use on your main Linux root to support it. Yes, it works fine.

Good luck
I use Fedora and it will very cleanly run 32bit binaries without a chroot. Fedora has split out the library paths to /lib and /lib64 (same for others like /usr/lib). The problem is it doesn't make a clean build environment for 32bit. But I have built a 32bit version on a system I have at work. It ran fine, but was noticeably slower performance, much more so than I would have expected. So I prefer to stick with 64bit and fix it. Besides, its the "right" way to do it, lol.
Reply With Quote