Different types - different endianness?

Question

I'm working on rather old code atm, and this code tests the endianness of types like short, int, long and long long separately.

Are there systems "still in use" that actually have different endianness for different types (due to different sizes of these types)? The only example that I know of is the PDP-11, where the two 16 bit halves of 32 bit values are stored in "big endian order" whereas the two 8 bit halves of each of these 16 bit are stored in "little endian order".

Due to undefined behavior in the mentioned tests I probably need to rewrite parts of this and want to know if it's worth the effort to keep that complexity. I know that (and how) I can write code that's independent of the system endianness, but this would be a lot of changes that I currently don't have the time for.

Alter

Are there any tags that I should/could add? "history" related but not too broad? – Alter

I would take a look at the systems to which you predict the code will be ported in the next 5 years. The chances are that you'll find that no modern system is as anarchic as the PDP-11 w.r.t the byte order of long was. Personally, I would not worry about mixed-endianness unless there was a current system that the code runs on that has it. You might well need to worry about big-endian vs little-endian, though there are usually ways to treat that systematically via serialization functions. – Pinguid

A more recent case is one of the several obsolete floating-point coprocessors for early generation ARMs, which used the opposite endianness to the main processor -- so float and double were big-endian where int etc were little-endian. (I vaguely remember that this was because the coprocessor was a nearly-unmodified MC68881, designed to work with the 68020 series, which were big-endian throughout.) By "more recent", mind, I mean the early 1990s. Modern ARM, with built-in FPU, uses consistent endianness for everything. – Silma

@JonathanLeffler Unfortunately, I do not even (really) know which systems are currently of most interest, thus predicting anything is really difficult here. It seems older versions of the software (GNU CLISP, if you're curious) are (still) running on "anarchic" machines, and breaking compability isn't really the best idea here. Though I discovered that in other parts of the code the endianess is assumed to be the same for all types, so I guess this ship has sailed ^^ – Alter

@Silma Yes, that's a good example (even if not depending on the type's size)! – Alter

"this code tests the endianness". Perhaps it should not. Not that there's an absolute ultimate truth out there. – Libava

See my answer below. Yes, there are still a lot of big endian processors, and some that are configurable. That tells you that there are applications where it is important. Generally, for code, there is a conditional compilation for the processor, or the the code or board design explicitly sets the endian bit in the processor control register or control line. – Inexhaustible

@n.m. I'm totally with You ... ideally the tests for endianness shouldn't be needed. But the rest of the (decades old, huge, jungle like) code base heavily makes use of (bad) code that needs to know the endianness. If You're interested, the code base being talked about is GNU CLISP. – Alter

Answer 1

Big endian machines are still in use, in digital signal processors (DSP) where TI provides numerous examples, and in general purpose processors where the Motorola 68000 is an example. Notably, in some DSP and RISC processors (c.f. ARM and Power), endianess is configurable and sometimes at multiple levels.

Here is an example by TI that combines big-endian and little-endian processors for particular functionality, "OMAP910 Device"

The history of endianess in general purpose processors is described in the following IEEE article, Endianess in personal computers

Reasons for using a DSP or ARM in a design include that the device may be optimized for a particular functionality, more cost effective, require less supporting circuity, or use less power compared to a general purpose processor. The OMAP910 demonstrates endianess for an intended functionality.

Code developed to run on platforms with different endianess, is often conditionalized for the endianess of the platform and where configurable and relevant, the rule is generally to explicitly set or detect the endianess.

Inexhaustible

Good point, edited accordingly. The ARM and Power of course are RISC processors. – Inexhaustible