Sign in to follow this  

Safe to say all are in little endian nowadays ?

Recommended Posts

Posted (edited)

Hi,
I searched a bit on Google and what I see is always "little endian" : Android, IOS, PS4, XBOX ONE...
Is it safe to say all is little endian nowadays ?
If not, here a way used to check the endian :

#if defined( __linux__ )
  #include <endian.h>
  #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
    #define ENDIAN_LITTLE
  #else
    #define ENDIAN_BIG
  #endif // __BYTE_ORDER__
#elif defined( __m68k__ ) || defined( mc68000 ) || defined( _M_M68K ) || ( defined( __MIPS__ ) && defined( __MISPEB__ ) ) || \
      defined( __ppc__ ) || defined( __POWERPC__ ) || defined( _M_PPC ) || defined( __sparc__ ) || defined( __hppa__ )
      #define ENDIAN_BIG
#else
  #define ENDIAN_LITTLE
#endif // ENDIAN

Not sure it's safe.
Thanks

Edited by Alundra

Share this post


Link to post
Share on other sites

For games, it's pretty safe. For embedded devices, micro-controllers, digital signal processors, network hardware, etc. it's not safe.

Share this post


Link to post
Share on other sites
All the devices you will encounter are little endian.

A small percentage of servers, like AIX, are big endian. You will not encounter these in games, not even for server back-ends. Those are the "big iron" machines running Cobol in the back offices of old banks, or the ancient air traffic controller centers.

An small percentage of microcontrollers are big endian or mixed endian. You probably aren't writing games for an audio signal processor chip.

Every PC, laptop, desktop, server, phone, tablet, game console, or other interesting device for games is little endian.

Even back in the older days, the only time you needed to worry about it was when you were transferring data from one system to another system, such as moving data to/from a "big iron" machine and a terminal. Some data protocol specify "network byte ordering", which is big endian. Some data files also specify big endian, but that is rare these days.

Share this post


Link to post
Share on other sites

Nope. Never safe to say anything like that.  It's like structural engineers saying "we don't need to take earthquakes into account because we haven't had earthquake in the last 50 years anyway."

Share this post


Link to post
Share on other sites

Except earthquakes directly interfere with a bridge, while on the other hand, you have full control what external access exists, and which conditions it should obey to make it work.

Share this post


Link to post
Share on other sites

You can also test/validate the system endianness at runtime like so (although "runtime" is sort of a misnomer in this case, as the compiler might very well optimize this down to simply the proper result):

eEndianness GetEndianness()
{
    eEndianness endianness = eUnknown;

    uint16_t test = 0xff00;

    uint8_t* pPtr = (uint8_t*)&test;

    if ( ( 0x00 == pPtr[0] ) && ( 0xff == pPtr[1] ) )
    {
        endianness = eLittleEndian;
    }
    else if ( ( 0xff == pPtr[0] ) && ( 0x00 == pPtr[1] ) )
    {
        endianness = eBigEndian;
    }

    Assert( eUnknown != endianness );

    return endianness;
}

Share this post


Link to post
Share on other sites

You can also test/validate the system endianness at runtime like so...

I'm not aware of any system configuration where the endianess is likely to switch *while your program is running*. Compile-time checks are perfectly adequate.

As to the question of frequency, most ARM chips can run in either endian. Power chips (the newer variants of PowerPC) are also bi-endian. You'll probably never run into such a chip in games development, but if you are writing generalised software, there's still a decent chance.

Share this post


Link to post
Share on other sites
Posted (edited)

I'm not aware of any system configuration where the endianess is likely to switch *while your program is running*. Compile-time checks are perfectly adequate.

 

Just put an ifdef or static assertion in any bit of the code affected by endianness (which should be like, 0% of your structures) and then fix it when you port to one of those platforms later.

 

Yes, I was not quite clear enough on the intent.  I didn't mean to imply you would need to do this "live" all the time.  Rather, you can use it to validate that your assumption about the endianness of the system is valid.  To Hodgman's point, an assertion or static assertion at the right place to indicate if there's a mismatch.

Edited by SBD

Share this post


Link to post
Share on other sites

You'd only typically worry about this when you are transferring data from one system to another, and that check should still apply even today.  But, it's not a compile-time check "is my architecture big or little endian?", more like a runtime-check "is this byte array using big or little endian?"  I typically just dictate that on the format of the file, that whoever is de/serializing it should use that endian regardless of the system.

If you are saving game data from and for a particular system only, then you should use whichever the architecture uses.

Share this post


Link to post
Share on other sites
Posted (edited)

Yes, I do the same, I use a value 1 or 0 for little / big endian and then I have simple inline function which check the endian source to convert using the define of the actual compilation endian.
So, basically it's more an issue to check the good endian based on platform because then all others place uses the #ifdef to know the actual endian.

Edited by Alundra

Share this post


Link to post
Share on other sites

If you are saving game data from and for a particular system only, then you should use whichever the architecture uses.

This. You don't ship the same assets on every platform. You burn big-endian encoded files on your Xbox360 DVDs, and little endian encoded files on your X86 Windows DVD.

The main groundwork here is making sure that your engine is designed to compile your data once for each platform.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this