Be generically portable to new CPUs on all GNU platforms #17
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
GNU/Linux and GNU/kFreeBSD both use the GNU libc and runtime linker, which is the layer that this engine interacts with directly. The specific kernel used is below the level that this engine is dealing with. From Debian, via ioquake3 commit ioquake/ioq3@d2f8b9f. Commit message added by Simon McVittie. Bug-Debian: https://bugs.debian.org/413617 Reviewed-by: Simon McVittie <smcv@debian.org> Signed-off-by: Simon McVittie <smcv@debian.org>
As with GNU/kFreeBSD, it's treated as "Linux": all three use the GNU libc and runtime linker, which is mostly what matters for ioquake3. From Debian, via ioquake3 commit ioquake/ioq3@540e422. Bug-Debian: http://bugs.debian.org/679330 Reviewed-by: Simon McVittie <smcv@debian.org> Signed-off-by: Simon McVittie <smcv@debian.org>
…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. Originally committed to ioquake as ioquake/ioq3@071965b. Signed-off-by: Simon McVittie <smcv@debian.org>
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. Originally sent to ioquake3 as commit ioquake/ioq3@c91fab3. Signed-off-by: Simon McVittie <smcv@debian.org>
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 game-code does not actually use ARCH_STRING, but I've kept it in order to be consistent with the ioquake3 engine. 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. Originally sent to ioquake3 as commit ioquake/ioq3@2a71948. Signed-off-by: Simon McVittie <smcv@debian.org>
|
Looks good to me |
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.
This pull request collects several portability changes originating in Debian that were merged into ioquake3 between 2011 and 2015.
ARCH_STRINGis just the output ofuname -m. The only special cases needed are for 32-bit x86 and ARM, whereuname -mcan take multiple values (such asi586,i686,armv5tel,armv7l) which we need to normalize tox86andarmto be compatible across CPUs from the same family. This patch is enough to avoid needing a change like Add support for Aarch64 (ARM64) ioquake/ioq3#128 for each new architecture, and in particular provides aarch64 (64-bit ARM) support.The
ARCH_STRINGis not actually used anywhere in the gamecode, except for raising a#errorif it isn't defined. I could have deleted it completely, but I thought it was probably better to keepq_platform.hconsistent with the one in ioquake3.Please see the commit messages of the individual commits for more information.