ExCrypt, as well as other modules in the GxOSS project, all assume that the binary will be compiled for amd64 (probably also x86). This causes broken builds and other hazards in the code.
- excrypt_aes.c is strictly tied to Intel SIMD CPU extensions (SSE4) because of the use of
wmmintrin.h. This breaks builds on non-x64 platforms, which leads into the next issue...
- A lot of code assumes that the CPU is little endian and calls
bswapXX() functions. This will work for x86 and arm64 targets, but not for PowerPC; ppc is in big-endian mode by default. If any of the GxOSS suite is to run on PowerPC (i.e., we do NAND image builds on the 360 itself), then this will have to change.
None of this is critical for short-term development on x86/amd64 Windows and Linux, but it is an issue for arm64 macOS/Windows, and it further hinders portability to other platforms.
ExCrypt, as well as other modules in the GxOSS project, all assume that the binary will be compiled for amd64 (probably also x86). This causes broken builds and other hazards in the code.
wmmintrin.h. This breaks builds on non-x64 platforms, which leads into the next issue...bswapXX()functions. This will work for x86 and arm64 targets, but not for PowerPC; ppc is in big-endian mode by default. If any of the GxOSS suite is to run on PowerPC (i.e., we do NAND image builds on the 360 itself), then this will have to change.None of this is critical for short-term development on x86/amd64 Windows and Linux, but it is an issue for arm64 macOS/Windows, and it further hinders portability to other platforms.