Source: ioquake3 Version: 1.36+svn2287-1 Severity: wishlist Tags: help upstream User: debian-...@lists.debian.org Usertags: port-x32
ioquake3 defines the feature-test macro "idx64" if the compiler predefined macro __x86_64__ is defined, or "id386" if the platform is i386. The x32 ILP32 ABI is neither of these, leading to broken assumptions in various places (notably the x86 JIT in vm_x86.c, where a pointer is assumed to be 64 bits long if idx64 is defined). idx64 represents the normal x86_64 LP64 ABI, so it is not correct for this to be defined on x32. id386 represents the i386 ABI, so that is not correct for x32 either. If someone wants to port and test ioquake3 on x32, a minimal port would probably be to treat x32 (defined(__x86_64__) && !defined(__LP64__)) as neither id386 nor idx64, resulting in the same non-optimized code paths being used as for e.g. arm64, ia64 or mips (pure interpreter rather than a JIT, no optimized assembler versions of functions, etc.). I suspect this would work fine. For a full port at the same level as i386 and x86_64, each special case for id386 or idx64 would need to be checked to work out whether this is a way in which x32 is more like i386 (ILP32 data model) or more like x86_64 (modern FPU with SSE, legacy i387 instructions best avoided), probably via a new idx32 macro representing the x32 ABI. This might be a waste of effort, because modern x86_64 CPUs are so much faster than the 1999 CPUs that this engine was designed for anyway. Either of these changes, if done, should happen upstream first: https://github.com/ioquake/ioq3 I do not intend to work on either of these myself. x32 users can use the amd64 binary until/unless x32 porting happens. smcv
