Difference between revisions of "Endianness"
JeremyRand (talk | contribs) (Performance) |
JeremyRand (talk | contribs) (Porting Buggy Software) |
||
Line 14: | Line 14: | ||
LE mode may be slightly faster than BE mode for code that can be optimized by deliberately accessing variables with a smaller-than-usual data size. Note that this class of optimization is a memory-safety bug if implemented incorrectly; see [[#Security|the Security section]] for information on downsides of this performance advantage. | LE mode may be slightly faster than BE mode for code that can be optimized by deliberately accessing variables with a smaller-than-usual data size. Note that this class of optimization is a memory-safety bug if implemented incorrectly; see [[#Security|the Security section]] for information on downsides of this performance advantage. | ||
+ | |||
+ | = Porting Buggy Software = | ||
+ | |||
+ | With rare exceptions, correctly written software will work in both BE and LE modes without issues. However, if software was only subject to QA testing on one endianness mode, there is a nontrivial chance that it was written to rely on assumptions that only are accurate for that mode. In practice, this means that software that was exclusively tested on x86 is likely to exhibit bugs in BE mode, while software that was exclusively tested on old Macs is likely to exhibit bugs in LE mode. | ||
= References = | = References = | ||
<references /> | <references /> |
Revision as of 13:03, 22 February 2023
All POWER CPU's from POWER3 onward support both big-endian (BE) and little-endian (LE) modes.[1] This is in contrast to x86, which supports only little-endian mode.
Operating System Support
Some distros only support BE; others only support LE; others support both. See the Operating System Compatibility List to check support in your preferred distro.
Security
BE mode has a security advantage over LE mode: there exist certain classes of memory-safety bugs (e.g. accessing a variable with the wrong data size) that typically cause an immediate crash (or otherwise obviously-wrong behavior) in BE mode, but instead manifest as silent security vulnerabilities in LE mode. Theoretically, it is likely that a sanitizer could achieve similar security benefits in LE mode, but such a sanitizer would have a performance impact that usage of BE mode would not incur. (Also, no such sanitizer is currently known to exist.)
Performance
Networking-heavy code may be slightly faster in BE mode, because many network protocols serialize data as BE.
LE mode may be slightly faster than BE mode for code that can be optimized by deliberately accessing variables with a smaller-than-usual data size. Note that this class of optimization is a memory-safety bug if implemented incorrectly; see the Security section for information on downsides of this performance advantage.
Porting Buggy Software
With rare exceptions, correctly written software will work in both BE and LE modes without issues. However, if software was only subject to QA testing on one endianness mode, there is a nontrivial chance that it was written to rely on assumptions that only are accurate for that mode. In practice, this means that software that was exclusively tested on x86 is likely to exhibit bugs in BE mode, while software that was exclusively tested on old Macs is likely to exhibit bugs in LE mode.