Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

be portable to miscellaneous CPU architectures #666

Merged
merged 5 commits into from May 16, 2015

Conversation

smcv
Copy link
Contributor

@smcv smcv commented May 8, 2015

The Quake 3 engine is portable to various CPUs, and I haven't noticed anything JK-specific in OpenJK that wouldn't be, other than an endianness fix in the MP3 code which is fixed in this branch. The current CMake files assume that everything non-ARM is x86, but the current "ARM" code-path is equally valid for any non-x86 architecture; this branch adapts it accordingly.

The major potential portability issues are:

  • Windows vs Unix: OpenJK supports both already
  • 32-bit vs. LP64 (64-bit Linux) vs. LLP64 (64-bit Windows): OpenJK supports all three already
  • x86 vs. not x86: there's at least some level of ARM support already
  • Little-endian (x86, most modern ARM) vs. big-endian (e.g. PowerPC): Mac OS X JK2 was available on PowerPC, although the relevant changes might not have been included in the GPL release; I've successfully tested the combination of this and my other pending branches on PowerPC

smcv added 5 commits May 8, 2015 22:37
This option is universally available, and the Quake III engine
assumes it. It is the default on x86 but not on, for instance,
ARM and PowerPC.
cmake already has a standard way to distinguish between 32- and 64-bit
platforms; there's no advantage in adding another.
There are more architectures than just x86, x86-64 and ARM, and the
Quake III engine supports most of them. I haven't seen anything
in OpenJK that is particularly platform-specific, other than what's
fixed in this branch.
There are plenty of CPU architectures that are neither ARM nor the
x86 family, for instance PowerPC and ARM64.
The mp3code came from Zinf (formerly FreeAmp) in which a similar
endianness bug was fixed back in 2003 <https://bugs.debian.org/56472>.
The bug is that the code uses LITTLE_ENDIAN as though it was a
feature-test macro like Q3_LITTLE_ENDIAN, but actually it's
always defined, regardless of platform: the actual test for
endianness with <endian.h> is BYTE_ORDER == LITTLE_ENDIAN.
As a result, it always takes the LE code path.

Rather than trying to use <endian.h> in a portable way, I've just
used the Quake 3 engine's equivalent macros.

I'm surprised this wasn't fixed in JK2/JA already, since at least JK2
ran on Mac back when that meant PowerPC, but perhaps changes from the
Mac port didn't all make it into Raven's GPL release.
xycaleth added a commit that referenced this pull request May 16, 2015
be portable to miscellaneous CPU architectures
@xycaleth xycaleth merged commit 1e1cbb7 into JACoders:master May 16, 2015
@smcv smcv deleted the portable branch July 29, 2015 09:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants