yegorc.net/blog/endianness
In computers, numbers are stored in binary, and are usually organized into bytes. Endianness is the order of those bytes. A number stored in big-endian notation will have the least significant byte (the last two hexadecimal digits) stored in the last part of the memory (the "biggest" memory address). A little-endian number, on the other hand, has the least significant byte in the beginning of the memory (the "littlest" memory address. We're going to explore what this actually looks like under the hood, and reveal something interesting about how humans think about numbers.
Like most CPU architectures, x86 keeps memory in little-endian (the opposite of the way most people do it). In networking, little-endian notation is common, and in file standards, it's pretty arbitrary.
Here is an example that shows the endianness of 64-bit x86 by reading and writing the number 530881 from memory:
global _start
_start:
; we will use a system call to tell linux to allocate 4 bytes
; we pass the arguments by putting them in registers
; mov a, b is a comand to move the data from b into a
mov rax, 9 ; syscall 9 is mmap (allocate memory)
mov rdi, 0 ; start location
mov rsi, 4 ; amount of memory to allocate in bytes
mov rdx, 0b11 ; allow the memory to be read and written to
mov r10, 0x22 ; designate it as a private mapping (other processes can't read it)
mov r8, -1 ; file descriptor (we're not using this)
mov r9, 0 ; offset
syscall ; linux will read those registers and allocate some memory for us
; the memory address of the memory we allocated is now in the rax register
; we don't want to overwrite this so we put it in r12 instead
mov r12, rax
mov dword [r12], 530881 ; put our number in memory
mov rax, 1 ; syscall 1 is write
mov rdi, 1 ; write to standard output (fd 1)
mov rdx, 4 ; number of bytes to write
mov rsi, r12 ; the message
syscall
mov rax, 60 ; exit syscall
xor rdi, rdi ; return 0 (same as `mov rdi, 0` but allegedly faster)
syscall
You can compile this on GNU/Linux with nasm -f elf64 main.s -o main.o && ld main.o -o main and run it with ./main. The raw bytes it outputs aren't visible in most terminal emulators, but you can see them with hexyl or another hex viewer. The output of ./main | hexyl looks like this:
┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐
│00000000│ c1 19 08 00 ┊ │ו•0 ┊ │
└────────┴─────────────────────────┴─────────────────────────┴────────┴────────┘
If you ask Wolfram Alpha what 530881 is supposed to look like, you'll notice that the bytes are in fact backwards (0x000819c1 is instead 0xc1190800). The reasoning behind this is simple enough. When you are adding or multiplying two numbers by hand, you usually work from the right end of the number and work your way to the left. Computers generally read memory from the beginning, so storing numbers this way makes a lot of sense.
Of course, this begs the question: why don't we use this big-endian notation for our numbers? Especially considering that when this stuff was invented, hand calculation was all the more important. As you surely know, the majority of the world now uses Arabic numerals for its base-10 number needs. But Arabic, like most semitic languages, is read right to left. When Europeans started using arabic numerals, they didn't bother switching the order. So, in a way, people actually are using big-endian notation. Most Arabs are, anyway.