Why are the hex numbers for big endian different than little endian?

Question

#include<stdio.h>

int main()
{
    typedef unsigned char *byte_pointer;
    
    void show_bytes(byte_pointer start, size_t len)
    {
        int i;
        for (i = 0; i < len; i++)
        {
            printf(" %.2x", start[i]);
            printf("\n");
        }
    }
    
    void show_int(int x)
    {
        show_bytes((byte_pointer) &x, sizeof(int));
    }
    
    void show_float(int x)
    {
        show_bytes((byte_pointer) &x, sizeof(float));
    }
    
    void show_pointer(int x)
    {
        show_bytes((byte_pointer) &x, sizeof(void *));
    }
    
    int a = 0x12345678;
    byte_pointer ap = (byte_pointer) &a;

    show_bytes(ap, 3);
    
    return 0;
}

(Solutions according to the CS:APP book)

Big endian: 12 34 56

Little endian: 78 56 34

I know systems have different conventions for storage allocation but if two systems use the same convention but are different endian why are the hex values different?

Answer 1

Endian-ness is an issue that arises when we use more than one storage location for a value/type, which we do because somethings won't fit in a single storage location.

As soon as we use multiple storage locations for a single value that gives rise to the question of:  What part of the value will we store in each storage location?

The first byte of a two-byte item will have a lower address than the second byte, and in particular, the address of the second byte will be at +1 from the address of the lower byte.

Storing a two-byte item in two bytes of storage, do we store the most significant byte first and the least significant byte second, or vice versa?

We choose to use directly consecutive bytes for the two bytes of the two-byte item, so no matter which (endian) way we choose to store such an item, we refer to the whole two-byte item by the lower address (the address of its first byte).

We can express these storage choices with a formula, here item[0] refer to the first byte while item[1] refers to the second byte.

   item[0] = value >> 8            // also value / 256
   item[1] = value & 0xFF          // also value % 256
   value = (item[0]<<8) | item[1]  // also item[0]*256 | item[1]

--vs--

   item[0] = value & 0xFF          // also value % 256
   item[1] = value >> 8            // also value / 256
   value = item[0] | (item[1]<<8)  // also item[0] | item[1]*256

The first set of formulas is for big endian, and the second for little endian.

By these formulas, it doesn't matter what order we access memory as to whether item[0] first, then item[1], or vice versa, or both at the same time (common in hardware), as long as the formulas for one endian are consistently used.

If the item in question is a four-byte value, then there are 4 possible orderings(!) — though only two of them are truly sensible.

For efficiency, the hardware offers us multibyte memory access in one instruction (and with one reference, namely to the lowest address of the multibyte item), and therefore, the hardware itself needs to define and consistently use one of the two possible/reasonable orderings.

If the hardware did not offer multibyte memory access, then the ordering would be entirely up to the software program itself to define (accessing memory one byte at a time), and the program could choose big or little endian, even differently for each variable, as long as it consistently accesses the multiple bytes of memory in the same manner to reassemble the values stored there.

In a similar manner, when we define a structure of multiple items (e.g. struct point { int x; int y; }, software chooses whether x comes first or y comes first in memory ordering.  However, since programmers (and compilers) will still choose to use hardware instructions to access individual fields such as x in one go, the hardware's endian configuration remains necessary.