How is each byte in integer state stored in CPU / memory?

Question

I tried this

char c[4]; int i=89; memcpy(&c[0],&i,4); cout<<(int)c[0]<<endl; cout<<(int)c[1]<<endl; cout<<(int)c[2]<<endl; cout<<(int)c[3]<<endl; 

the output is similar:
89
0
0
0

which quite comprehends my stomach because I thought the number would be stored in memory as 0x00000059, since c [0] is 89? I thought it should be in c [3] ...

Answer 1

Because the processor you are working on is little-endian . The byte order of a multibyte fundamental type is replaced. On a large car, it will be as you expect.

Answer 2

This is because you are running the program on little endian cpu. See also endianness here and there .

Answer 3

Endian-ness is obviously the answer, as Goz pointed out.

But for those who are not clear what this means, it is also important to understand that the byte order displayed in the example is the same as the order in the original int. Memcpy does not change the byte order, regardless of the edian platform type.

Answer 4

Since byte ordering is an arbitrary design decision. As soon as there is no byte order ¹ in the register.

Byte order occurs when we address smaller units, such as bytes. This is almost an arbitrary decision that the CPU developer receives: big-endian or little-endian.

It is useful to simplify the situation and understand that this is mainly communication with peripheral devices that are ordered by bytes. Yes, it can be detected through byte addressing, as you proved, but in general, scalar values ​​are loaded and stored as units in registers, in which case the byte order does not change anything. The most significant bits are on the "left", at least as we usually write numbers. And therefore, the << and >> operators always produce exactly the same results in large and low order machines when they are used in accordance with language standards.

But in order to read and write data streams to peripheral devices, you are forced to choose the byte order. This is because peripheral devices are basically byte stream devices. Does the lowest address have the most significant bits or the least? This was done in both directions, and the camps were fairly evenly divided.

Since the memory itself is addressed bytes, you can certainly get other behavior without peripherals, but this usually does not happen without deliberate peeping inside, like you.

Imagine a CPU that has no bytes, only 32-bit words addressed as 0, 1, 2. The C compiler does char, int and all 32-bit objects long. (This is permitted by Cx9.) Wow, byte ordering problems! And this! But .. what happens when we connect our first peripheral device?

---

1. _{Well, x86 has registers with an alias of smaller registers, but this is another story.}

Answer 5

Different machines may have different byte order, but look at this code and think about what happens, depending on how the bytes come out:

 long x = 89; short *p = (short*)&x; short y = *p; 

Answer 6

If you want your application to be portable or developed as a team, you probably will not want to follow this logic, as this can lead to error crashes and prolong development.