Implement Linux architecture support generically #129
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
travis-ci reveals that this breaks cross-compiling. I'll push a revised branch soon. |
smcv
force-pushed
the
generic-platform
branch
2 times, most recently
from
7e61d41
to
0de5dc8
Compare
…ix64 It isn't mentioned anywhere else, and deleting it from the Linux code path means we don't need to maintain an exhaustive list of 64-bit architectures.
The ARCH in the Makefile must match the ARCH_STRING in q_platform.h; otherwise, ioquake3 will install (for instance) uiARCH.so but look for uiARCH_STRING.so, which isn't going to go well (particularly for the modular renderer). Like i386, but unlike most (all?) other Linux platforms, uname -m on 32-bit ARM machines can have various results starting with "arm", depending on the specific CPU version (e.g. Raspberry Pi is armv6l, RPi2 is armv7l). Again similar to the x86 family, it's appropriate for them to share an architecture suffix; q_platform.h has traditionally used "arm" so let's use that. 64-bit ARM makes a clean break from this, much like 64-bit x86 does: uname -m produces a string not starting with arm (specifically "aarch64"), and gcc predefines __aarch64__ instead of __arm__. As a result, it is unaffected by this change.
GNU platforms (Linux, kFreeBSD, Hurd) have endian.h to determine endianness, so all architectures except x86_64 are in fact treated identically, except that their ARCH_STRING is different. The ARCH_STRING must always be identical to the ARCH from the Makefile, otherwise the engine will not find its cgame, game and ui plugins under their expected names and startup will fail. If we pass it in from the Makefile, then an identical value is guaranteed, and we can get rid of an increasingly long list of defined(__some_cpu__) tests. The one remaining quirk is that we test __x86_64__ to determine whether to define idx64; I've kept that, but separated it from the ARCH_STRING. On non-Linux platforms we only support a few architectures anyway, so keeping the list up to date is less of a burden; *BSD porters could probably use the same technique to get support for lots of architectures with little effort, but I have not done that here, because I cannot test it. Windows must continue to support preprocessor-based architecture tests in any case, so that the MSVC solutions (which do not use the Makefile) can continue to work. However, Windows only runs on a few CPU families, so this shouldn't be a significant burden in practice. When cross-compiling, the tools are compiled for the build architecture (COMPILE_PLATFORM, COMPILE_ARCH) rather than the host architecture (PLATFORM, ARCH), so define ARCH_STRING to COMPILE_ARCH on a GNU COMPILE_PLATFORM.
|
Updated branch appears to fix cross-compiling locally (currently waiting for travis-ci results), and ensures that 32-bit ARM variants produce (e.g.) cgamearm.so as they have traditionally done, rather than switching to something weird like cgamearmv5tel.so. The first two commits would be worth merging even if you don't want the third. |
timangus
added a commit
that referenced
this pull request
Jul 15, 2015
Implement Linux architecture support generically
smcv
added a commit
to smcv/OpenJK
that referenced
this pull request
Jul 26, 2015
This is ioquake/ioq3#129, adapted for the OpenJK codebase. GNU and *BSD platforms have a built-in way to determine endianness, so all architectures except x86_64 are in fact treated identically, except that their ARCH_STRING is different. The ARCH_STRING must always be identical to the Architecture from CMake, otherwise the engine will not find its cgame, game and ui plugins under their expected names and startup will fail. If we pass it in from CMake, then an identical value is guaranteed, and we can get rid of an increasingly long list of defined(__some_cpu__) tests. The one remaining quirk is that we test the predefined macro __x86_64__ (on Linux and other GNU platforms) or __amd64__ (on *BSD) to determine whether to define idx64; I've kept that, but separated it from the ARCH_STRING. OpenJK does not distinguish between GNU and *BSD platforms in its build system, so unlike my similar ioquake3 patch, I've included an untested version of the same change for *BSD. Windows and OS X only support a few architectures anyway, so keeping the list up to date is less of a burden there.
alarixnia
added a commit
to alarixnia/ioq3
that referenced
this pull request
Sep 9, 2020
This extends ioquake#129 to FreeBSD/NetBSD/OpenBSD. Tested on NetBSD.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ioquake3 currently requires trivial code changes every time Linux developers get interested in running it on a new CPU, most recently #128 for ARM64 (aka aarch64). For the vast majority of CPUs, the only change is to add ARCH_STRING detection, which must be kept in sync with the ARCH from the Makefile (which is just
uname -m, with one special case for the 32-bit x86 family).This branch passes the ARCH from the Makefile directly to q_platform.h on Linux and other GNU platforms, making it unnecessary to change anything to support new CPUs in most cases. Code changes should now only be needed if the new CPU is relevant to non-GNU platforms (Windows, OS X, *BSD), if there is genuinely something weird and assumption-breaking about it, or if someone contributes a JIT to replace the lowest-common-denominator QVM interpreter on that platform.