Big Ending and Little Ending Explained

[SemiconductorCat]

when we store data in computer memory, there are basically two ways of storing them. Simply one way is store the big byte first or storing the small byte first.

The term “big-ending” or “little-ending” is comming from the Gulliver’s Travel Advanture movie,where the “liliputians” are divided into two camps , who start to ate the egg from little and and who start to ate the egg from the big end.

The same meaning is there on the computing world. In little ending, you first store the lowerst byte , and in the big ending you store the most significiant byte first. Computing world also politically discriminated into these two categories, discrimination is everywhere in the world where computing is not just exception to it.

To make this clear , let’t take a look at a example. Suppose you need to store 12345678H (hexadecimal) value in compuer memory. In C programming language you can simply write.

Code: Select all

int i = 0×12345678;

If you took a logic probe and hack your computer memory and see , and if your computer is little ending you can find it like this. Please suppose that &i=0x0100h or address of i is situated at the memory location 0x0100h.



value 0x12345678h was stored in a little ending machine’s memory.

value 0x12345678h was stored in a big ending machine’s memory

And if you’r not touching assembly language/system programming or file types and I/O and you programming in a high level language like C/C++/Java probablly you don’t need to familar with the difference between little-big ends.

If you’r writing the network protocols or writing a device driver code for a networking interface then you should probablly know that all the networking communication is goes in big-ending representation. When you doing programming with sockets or higher level API you’ll met very rare cases you need to deal with this fact.

However if you want to deal with the file formats ,again this counts.For a example BMP,GIF and RTF are file formats that are examples for the “little ending” format. and JPEG is a example for “big ending”. Some file formats like AVI, WAV,TIFF supports both endings.

--happy coding--
--sandun--

[Neo]

Good post. Some more related information.

Little-endian operating systems:

• DragonFlyBSD on x86, and x86-64
• FreeBSD on x86, x86-64, and Itanium
• Linux on x86, x86-64, MIPSEL, Alpha, Itanium, S+core, MN103, CRIS, Blackfin, MicroblazeEL, ARM, M32REL, TILE, SH,
• XtensaEL and UniCore32
• Mac OS X on x86, x86-64
• NetBSD on x86, x86-64, Itanium, etc.
• OpenBSD on x86, x86-64, Itanium, etc.
• OpenVMS on VAX, Alpha and Itanium
• Solaris on x86, x86-64, PowerPC
• Tru64 UNIX on Alpha
• Windows on x86, x86-64, Alpha, PowerPC, MIPS and Itanium

Big-endian operating systems:

• AIX on POWER
• AmigaOS on PowerPC and 680x0
• FreeBSD on PowerPC and SPARC
• HP-UX on Itanium and PA-RISC
• Linux on MIPS, SPARC, PA-RISC, POWER, PowerPC, 680x0, ESA/390, z/Architecture, H8, FR-V, AVR32, Microblaze, ARMEB, M32R, SHEB and Xtensa.
• Mac OS on PowerPC and 680x0
• Mac OS X on PowerPC
• NetBSD on PowerPC, SPARC, etc.
• OpenBSD on PowerPC, SPARC, etc.
• MVS and DOS/VSE on ESA/390, and z/VSE and z/OS on z/Architecture
• Solaris on SPARC

Common file formats and their endian order are as follows:

• Adobe Photoshop -- Big Endian
• BMP (Windows and OS/2 Bitmaps) -- Little Endian
• DXF (AutoCad) -- Variable
• GIF -- Little Endian
• IMG (GEM Raster) -- Big Endian
• JPEG -- Big Endian
• FLI (Autodesk Animator) -- Little Endian
• MacPaint -- Big Endian
• PCX (PC Paintbrush) -- Little Endian
• PostScript -- Not Applicable (text!)
• POV (Persistence of Vision ray-tracer) -- Not Applicable (text!)
• QTM (Quicktime Movies) -- Little Endian (on a Mac!)
• Microsoft RIFF (.WAV & .AVI) -- Both
• Microsoft RTF (Rich Text Format) -- Little Endian
• SGI (Silicon Graphics) -- Big Endian
• Sun Raster -- Big Endian
• TGA (Targa) -- Little Endian
• TIFF -- Both, Endian identifier encoded into file
• WPG (WordPerfect Graphics Metafile) -- Big Endian (on a PC!)
• XWD (X Window Dump) -- Both, Endian identifier encoded into file

Are there other Endian methods?

Bi-endian hardware
Some architectures (including ARM, PowerPC, Alpha, SPARC V9, MIPS, PA-RISC and IA-64) feature a setting which allows for switchable endianness in data segments, code segments or both. This feature can improve performance or simplify the logic of networking devices and software. The word bi-endian, when said of hardware, denotes the capability of the machine to compute or pass data in either endian format.

Middle-endian (mixed-endian)
Numerous other orderings, generically called middle-endian or mixed-endian, are possible. On the PDP-11 (16-bit little-endian) for example, the compiler stored 32-bit values with the 16-bit halves swapped from the expected little-endian order. This ordering is known as PDP-endian. The ARM architecture can also produce this format when writing a 32-bit word to an address 2 bytes from a 32-bit word alignment.

Endianness in networking
Many IETF RFCs use the term network order; it simply describes the order of transmission for bits and bytes over the wire in network protocols. Among others the historic RFC 1700, corresponding to Internet standard STD 2, explains this big endian order.

The telephone network, historically and presently, sends the most significant part first, the area code; doing so allows routing while a telephone number is being composed.

The Internet Protocol defines big-endian as the standard network byte order used for all numeric values in the packet headers and by many higher level protocols and file formats that are designed for use over IP. The Berkeley sockets API defines a set of functions to convert 16-bit and 32-bit integers to and from network byte order: the htonl (host-to-network-long) and htons (host-to-network-short) functions convert 32-bit and 16-bit values respectively from machine (host) to network order; the ntohl and ntohs functions convert from network to host order. These functions may be a no-op on a big-endian system.

In CANopen multi-byte parameters are always sent least significant byte first (little endian).

While the lowest network protocols may deal with sub-byte formatting, all the layers above them usually consider the byte (mostly meant as octet) as their atomic unit.


Which is Better? Big or Little
You may see a lot of discussion about the relative merits of the two formats, mostly religious arguments based on the relative merits of the PC versus the Mac. Both formats have their advantages and disadvantages.

In "Little Endian" form, assembly language instructions for picking up a 1, 2, 4, or longer byte number proceed in exactly the same way for all formats: first pick up the lowest order byte at offset 0. Also, because of the 1:1 relationship between address offset and byte number (offset 0 is byte 0), multiple precision math routines are correspondingly easy to write.

In "Big Endian" form, by having the high-order byte come first, you can always test whether the number is positive or negative by looking at the byte at offset zero. You don't have to know how long the number is, nor do you have to skip over any bytes to find the byte containing the sign information. The numbers are also stored in the order in which they are printed out, so binary to decimal routines are particularly efficient.