Compiling torque on x86-64 (amd64) non functional?

#21 Antonio, I think your best bet is gonna be to compile in 32 bit mode on that AMD. Even if you get past the errors you have now a brick wall awaits in the assembly stuff. Along with other assumtions in the code about 32bit stuff.


The problem comes with nasm and in that it don't support the 64bit output that the rest of the toolchain will produce. Undefining the NASM define is only a partial fix as only one file pays attention to that define. There are a handful of others that assume nasm is there and functional.

The basic 32bit compile is invoked via replacing the -march and -mcpu switches with -m32. You _will_ need the 32bit versions of all the dependant libraries for a successful compile though. (glibc, libgcc, ogg, vorbis, SDL, all the X libs etc..) I did manage a successful compile of the dedicated server for the AMD64, its a 32bit binary and I stopped there as thats all I was really interested in getting to compile.

#22 Robert has poked on this a bit (he has a shiny 64 bit system at home). Making Torque fully utilize 64 bit tech isn't as important to us as , say, making shadows line up properly, or getting TSE done, though I'm sure we'll work on it at some point.

#23 I have 32bit stuff installed already, need it to run mozilla. But if you could tell me the procedure and files to edit to get the file compiling in 32bit mode...

I'd rather not edit my /etc/make.conf

Tony

#24 @Ben/GG: As Greg mentioned, the primary issue he had was the fact that NASM doesn't actually support the platform (yet), forcing a drop down to 32 bit architecture. I don't see an immediate solution here regarding making Torque "64 bit ready to rock!" without dropping down to a 32 bit subset, unless an alternative to NASM is found, someone releases a 64 bit ready version (rumor is AMD probably has to have an internal one), or TGE selects a different alternative.

The good news is that we are up and running on the platform (nothing major noted yet), so it's possible--just doesn't use the full 64 bit architecture, so ultimately it's a temp solution.

@Community: I'll try to drag the details out of Greg, or see if he can give a rudimentary "how-to"--I run him ragged as it is, so it won't be "soon", but we'll at least post back with the major areas that were issues.

I do know that the major areas were inline asm (x86UNIXCPUInfo.cc, specifically the CPU speed checks needed minor changes), the OFFSET macro, and then the link phase to get cooperative libs, specifically with NASM-intended source.

#25 Dead easy to compile in 32bit mode (once the 32bit supporting stuff is there)

Change this:

CFLAGS.GENERAL    = -DUSE_FILE_REDIRECT -I/usr/X11R6/include/ -MD -march=i586 \
          -mcpu=i686 -ffast-math -pipe

to

CFLAGS.GENERAL    = -DUSE_FILE_REDIRECT -I/usr/X11R6/include/ -MD -m32 \
           -ffast-math -pipe

and

LFLAGS=

to

LFLAGS=-m32

then type make and watch it build. The assembly, macros, types and such only come into to play if you want it compiled as a 64bit app.

Assembly in 64bit is different registers and instructions change.
nasm don't generate 64 bit object files. (yasm is supposed to but I couldn't get _it_ to compile and didn't feel like fighting that battle)

#26 Yeah and another, more basic thing, there is no Nvidia or ATI support for AMD 64 architeture yet.

#27 Nvidia Linux drivers AMD64
Nvidia and ATI drivers WinXP 64

#28 ~poke~

how is this going?

#29 Got it to compile in 32bit mode, good deal. and yes, there is nvidia drivers, they are even availiable on nvidia's site now.

~T

#30 Uh oh. getting this now:

tony@node0 torque $ make
--> Linking out.GCC3.DEBUG/torqueDemo_DEBUG.bin
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../lib/libGLU.a when searching for -lGLU
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../libGLU.a when searching for -lGLU
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/../lib/libGLU.a when searching for -lGLU
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libGLU.a when searching for -lGLU
/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lGLU
collect2: ld returned 1 exit status
make[1]: *** [out.GCC3.DEBUG/torqueDemo_DEBUG.bin] Error 1
make: *** [default] Error 2

suggestions?

Trying to compile the mesa source, and having trouble forcing it to compile the x86 source, any ideas?

~T

#31 Tony I have all this working (Torque on AMD64) if you want a blow-by-blow.

Paul.

#32 Yes, yes I do. feel free to email me at antonio [at] farinetti.net or antonio_farinetti [at] yahoo.com

#33 I've mailed you with the details but I've left out some bits. I see here from your post that you're trying to compile X and GLU using the 64-bit compiler.
Rather install the emul-linux libs for those - they go into /usr/lib32 and provide 32-bit apps with emulated versions of the libraries they need.

emerge -s emul-linux will bring up a list of the ones you need - nvidia, X, sdl and soundlibs off the top of my head.

Paul.

#34 @Paul: did you find a version of a 64 bit nasm compiler anywhere, or are you using total 32 bit emulation as your message above implies?

I would love to get our 64 bit server able to actually run as 64 bit, but the lack of a 64 bit nasm compiler was one of the big stumbling blocks.

#35 @Stephen,
Not yet. This is entirely emulated and requires a little trickery with 32-bit libraries to get working. It does work reliably though and at near native speeds. It's also good enough to play Tribes2 on AMD64 :) I will get a HOWTO together soon for Gentoo Linux.

Native compilation is my next step although I'm quite a newbie when it comes to Torque's source so I'll need help. I think Gregory's idea of Yasm is probably the best bet at the moment - get a native build to complete with 64-bit gcc and use yasm to output the assembly routines in 64-bit elf format. I would love to optimise some of those routines for the Hammer...

#36 @Paul: Ok, sounds like we're at the same stage then (our dedicated server has been running in 32 bit emulation mode on a 64 bit CPU since July).

I've been checking periodically with the nasm folks about a 64 bit version, but it appears that there is little, if any, works in progress along these lines. Unfortunately, this is something -way- beyond my project member's skill set.

#37 @Stephen,
Not yet. This is entirely emulated and requires a little trickery with 32-bit libraries to get working. It does work reliably though and at near native speeds. It's also good enough to play Tribes2 on AMD64 :) I will get a HOWTO together soon for Gentoo Linux.

Native compilation is my next step although I'm quite a newbie when it comes to Torque's source so I'll need help. I think Gregory's idea of Yasm is probably the best bet at the moment - get a native build to complete with 64-bit gcc and use yasm to output the assembly routines in 64-bit elf format. I would love to optimise some of those routines for the Hammer...

#38 @all,

thanks for everything. I'm glad that there is activity now to use torque on 64bit systems.

I never thought that when I started this thread back in may that it would last this long, but I've almost got it running on my system thanks to paul, and I am very happy!

#39 Oops - sorry for the duplicate post - I must learn to read those dialogs which warn about resubmitting the POST data :)

Time to go native 64! I can compile and install Yasm and it seems to output the correct format. Whether the routines actually _work_ is another problem for another time. These sets of errors:

--> Compiling platformX86UNIX/x86UNIXCPUInfo.cc
In file included from platformX86UNIX/platformX86UNIX.h:15,
from platformX86UNIX/x86UNIXCPUInfo.cc:9:
platform/event.h:137: warning: cast from pointer to integer of different size
platform/event.h:140: warning: cast from pointer to integer of different size
platform/event.h:143: warning: cast from pointer to integer of different size
{standard input}: Assembler messages:
{standard input}:172: Error: suffix or operands invalid for 'push'
{standard input}:173: Error: suffix or operands invalid for 'push'
{standard input}:177: Error: suffix or operands invalid for 'pop'
{standard input}:178: Error: suffix or operands invalid for 'pop'
{standard input}:191: Error: suffix or operands invalid for 'push'
{standard input}:192: Error: suffix or operands invalid for 'push'
{standard input}:197: Error: suffix or operands invalid for 'pop'
{standard input}:198: Error: suffix or operands invalid for 'pop'
make[1]: *** [linux.out.GCC3.RELEASE/platformX86UNIX/x86UNIXCPUInfo.obj] Error 1make:
*** [default] Error 2

as posted by Gregory above are easily fixable. pushl %eax is illegal under AMD64 - it must be encoded as pushq %rax since all stack pushes and pops are implicitly 64-bit. So I'm going to add in a #define in that file.

The one question I have is the Offset typedef. I presume the only change is to make the cast unsigned long like so: ?

#ifdef __x86_64__
#define Offset(m,T) ((unsigned long)(&((T *)1)->m) - 1)

Any ideas?

#40 @All,
Making Torque 64-bit clean is a large job for which I unfortunately have no time at the moment although I would like to tackle it sometime if no-one else is doing it. The main problem is pointer <-> int conversion which is harmless when compiling on 32-bits but won't work at all on 64 bits :) There are also some nasty gotchas with variable arguments and lazy gcc prototypes.
So for now, I'll stick to the 32-bit emulation howto (and perhaps even learn some more of Torque itself which is why I bought it in the first place - heh).