Raptor Computing Systems Community Forums (BETA)
Software => Applications and Porting => Topic started by: tle on August 21, 2025, 08:26:40 pm
-
In light of the emergence of AI-assistant toolings, I am wondering if anyone has recommendation of any model/tooling that could help developers identify quickly logics in the codebase that might be impacted with endianess? I am looking into the source code of DOOM 3 BFG and slowly going through to see if it could be ported to PPC64 Big Endian but darn it is so much time-consuming, there must be a better way I assume
-
Vector registers are endian. The most common use of vector code is through intrinsics, which should handle endian issues.
What is your development environment? What error messages do you get when you simply try to compile the code?
-
Generally anything that deals in a quantity and then starts addressing pieces of it (like a uint32_t that the code then starts accessing parts of with uint16_t or uint8_t, for example) will be sensitive to endianness, but there are other ways to make endian-dependent code, of course. But those are the most obvious sorts of "code smells."
-
Vector registers are endian. The most common use of vector code is through intrinsics, which should handle endian issues.
What is your development environment? What error messages do you get when you simply try to compile the code?
Most of the time I would not get any error but likely run into unexpected behaviour when running the game or apps.
-
Most of the time I would not get any error but likely run into unexpected behaviour when running the game or apps.
Your verbs are unclear - "would not" and "likely run into" are future tense, as in, you are projecting what might occur. Are you saying the entire code base compiled but has odd behavior when running in Big-endian mode?
If you can compile the source code, run it in Little-endian mode and see if the same unexpected behaviors are present.
-
Most of the time I would not get any error but likely run into unexpected behaviour when running the game or apps.
Your verbs are unclear - "would not" and "likely run into" are future tense, as in, you are projecting what might occur. Are you saying the entire code base compiled but has odd behavior when running in Big-endian mode?
If you can compile the source code, run it in Little-endian mode and see if the same unexpected behaviors are present.
Yes, I do project there are potential issue if the app is complex. Sometimes the app just crash early on, but sometimes it does not. The latter scenario can be real pain if applications are lacking of tests. I agree with you that one could always do comparison with ppc64le version. My question is simply curiosity if there is any tool that could analyze the codes / assembly / bytecodes to pick up places that might susceptible to endianness issue
-
My thought is that endianness is so intrinsic to vector register function that scenes would not even render. That is why any code that is expected to be portable would use compiler intrinsics to handle vector functions or any direct access to memory, as ClassicHasClass suggested.
In my experience, just getting "portable" code to compile is an achievement. I'd worry about it actually working later. You might be worrying about a problem you don't actually have to solve right now.
Then again, I am not a fan of Asinine Intelligence, and my views are biased towards Actual Intelligence, so I probably should not be responding :)
-
I thought about this a bit more and maybe the authors of DOOM3 use their own vector intrinsics. If you are wanting to port to big-endian, but they are using little-endian GPU-based vector registers, that would be where I would look for serious endian issues. If I was hunting this down, I would be grepping for "vector" or "GPU" and looking to see what header files pop up.
-
I don't recall if Doom 3 did, but I know Quake 4 and Prey ran on the Power Mac G5 - I played both of them on my Quad - so the engine (at least at some point) was definitely endian-neutral.
-
Doom 3 as released circa 2004 is endian-neutral and has Altivec/VMX optimizations, yes. But Doom 3 BFG Edition - a later remastering of the game with an updated OpenGL implementation and engine - is a different animal outright. tle's probably right about there being problems.
-
It does seem to me that seeing if the code will even compile in the projected build environment is a more immediate problem.
-
Doom 3 as released circa 2004 is endian-neutral and has Altivec/VMX optimizations, yes. But Doom 3 BFG Edition - a later remastering of the game with an updated OpenGL implementation and engine - is a different animal outright. tle's probably right about there being problems.
I just remembered: I've got the official Xbox 360 version of Doom 3 BFG Edition here (I mean, it's ppc64 on Xenon), so it looks like BFG certainly can run big too. Just not sure what source code @tle is working from.
-
I guess, this: https://github.com/RobertBeckebans/RBDOOM-3-BFG/pull/1047
You was mentioned there, too ;-)