ASCII and "big endian"

okay, so this doesn't really have much to do with C, however I don't know where else to ask it. if moderators feel that this is an inappropriate spot to post this, feel free to move it, and sorry for the inconvience.

I'm trying to write the characters FDG into an int using their hex values. so far, this is what I've established: 0x00464447.

however I'm a little confused here. in the Windows PE file format's IMAGE_DOS_HEADER, there is the member e_magic (a WORD, or in native C, a short) which should be IMAGE_DOS_SIGNATURE for a valid executable file. IMAGE_DOS_SIGNATURE is defined like so:

Code:

---

#define IMAGE_DOS_SIGNATURE 0x5A4D

---

this is the very first value in any executable file, which from a hex editor is visible as the ASCII characters MZ. what I don't understand here, is that if the hex value for the ASCII character 'M' is 0x4D, and for 'Z' it is 0x5A, wouldn't that be ZM?

after doing a little research, I found something about big endian, and how it affects the order in which bytes are represented. I read a little about it at wikipedia but got lost in some complex explanations and equations.

is 0x00464447 what I'm looking for here for FDG, or should it be 0x00474446? or neither of them, and if this is the case, could someone please explain why?


thank you in advance.

Endianness is an observable effect of multi-byte* storage. So it depends on what exactly it is you are storing into. If you only look at single bytes, it always looks the same.
[*]Yes, I know what byte means.

okay, after some more thorough reading, it looks like neither of my attempts were correct, and that it should really look like: 0x47444600.

I tested it and it looks as it should, I'm storing it into a 32-bit value (unsigned long). Thanks Dave, and sorry to mods for posting without performing significant research.

I'm not sure why you're storing characters in a short int, but if you're sending integers over the network, you should convert them to/from network byte order using htons()/ntohs() & htonl()/ntohl()...

On x86 systems, byte order is always swapped in memory.
A 1 byte value of 0x12 is stored as 0x12 is memory.
A 2 byte value of 0x1234 is stored as 0x34 0x12 is memory.
A 4 byte value of 0x12345678 is stored as 0x78 0x56 0x34 0x12 in memory
Usually, since structs are read and written to disk in its raw memory form, it also usually means it's byteswapped. But is this what you're after?

Quote:

---

Originally Posted by Elysia

On x86 systems, byte order is always swapped in memory.
[...]
A 4 byte value of 0x12345678 is stored as 0x56 0x78 0x12 0x34 in memory (word swapped).
Usually, since structs are read and written to disk in its raw memory form, it also usually means it's byteswapped. But is this what you're after?

---

Can you demonstrate this? My initial attempt failed.

Quote:

---

Originally Posted by Dave_Sinkula

Can you demonstrate this? My initial attempt failed.

---

Because it is untrue.

Alright, so it seems even 4 bytes are swapped per byte. I remembered wrong >_<

Code:

---

int main()
{
        int nNum1 = 0x12;
        int nNum2 = 0x1234;
        int nNum4 = 0x12345678;
        char* pNum1 = (char*)&nNum1;
        char* pNum2 = (char*)&nNum2;
        char* pNum4 = (char*)&nNum4;

        fprintf(stdout, "Number 1 (1 byte): 0x%X\n", pNum1[0]);
        fprintf(stdout, "Number 2 (2 bytes): 0x%X%X\n", pNum2[0], pNum2[1]);
        fprintf(stdout, "Number 3 (4 bytes): 0x%X%X%X%X\n", pNum4[0], pNum4[1], pNum4[2], pNum4[3]);
        return 0;
}

---

OUTPUT:
Number 1 (1 byte): 0x12
Number 2 (2 bytes): 0x3412
Number 3 (4 bytes): 0x78563412

Quote:

---

Originally Posted by Elysia

On x86 systems, byte order is always swapped in memory.

---

I don't think "byte swapping" is a good way to explain endianness. The bytes aren't "swapped" for no reason, it is simply adherence to a principal that the most significant byte comes first (or last) in memory.

Your example of a 4-byte quantity on x86 is incorrect.

Quote:

---

Originally Posted by brewbuck

I don't think "byte swapping" is a good way to explain endianness. The bytes aren't "swapped" for no reason, it is simply adherence to a principal that the most significant byte comes first (or last) in memory.

---

True enough, but you would expect a value to be 0x1234 to be stored as 0x12 0x34 in memory, which isn't true on x86.

Quote:

---

Your example of a 4-byte quantity on x86 is incorrect.

---

I just saw that >_<

Quote:

---

Originally Posted by Elysia

On x86 systems, byte order is always swapped in memory.
A 4 byte value of 0x12345678 is stored as 0x56 0x78 0x12 0x34 in memory (word swapped).
Usually, since structs are read and written to disk in its raw memory form, it also usually means it's byteswapped. But is this what you're after?

---

Not quite, it's 0x78 0x56 0x34 0x12.
All the bytes are always in reverse order. That even goes for 64-bit types ala __int64;

Yep, everyone is picking on me today :eek: :p
But I already demonstrated I was wrong and edited the first post to match.

Quote:

---

Originally Posted by Elysia

True enough, but you would expect a value to be 0x1234 to be stored as 0x12 0x34 in memory, which isn't true on x86.

---

Why would you expect any particular storage at all? The truth is, when you look at the data in a hex editor, the lower addresses are usually shown leftmost and topmost -- standard reading order. So the value 0x1234 will appear as the two bytes 12 34 only if the more significant byte is stored at the lower address, a.k.a. the "first" address.

But there is no logical reason why we should consider lower addresses to come "before" higher addresses. It's just a human convention. Big-endian order means values "read" right -- unless you happen to read a language where the letters go right to left! Or, imagine a hex editor where the lowest address is displayed at the lower right, and increasing addresses go leftward and upward on the screen. There's nothing "wrong" with such an editor, and it would cause little-endian values to "read correctly" on the screen.

This idea of "left is first" is so ingrained that we don't realize that it's completely artificial.

Intel chips have traditionally been little-endian. This means values read "backward" in a hex editor, but this doesn't mean anything. In a way, it's more logical than big-endian ordering since the LEAST significant byte occurs at the LOWEST memory address. Small-to-small. Again, all totally arbitrary.

When I TYPE the value left to right, then I EXPECT it to be stored left to right in memory too. This is what I'm hinting at. It's not wrong. It's just unexpected to most of us.

Quote:

---

Originally Posted by Elysia

When I TYPE the value left to right, then I EXPECT it to be stored left to right in memory too. This is what I'm hinting at. It's not wrong. It's just unexpected to most of us.

---

What makes you think that lower addresses are "to the left of" higher addresses?

EDIT: And I'd say that the opposite is expected by most of us, because the majority of chips and data formats out there are BIG endian, not little endian.

Just out of curiosity, is Little Endian more efficient for a CPU than Big Endian?

I would expect math operations on Little Endian to be easier and faster than on Big Endian since all bits are read from right to left, instead of reading left 8 bits, then jump forward (right) 16 bits and read another 8 bits... Big Endian sort of looks like bit fragmentation to me.

To the CPU, it doesn't matter (otherwise I don't know if endianness would exist). It's just electricity - one or zero.

Quote:

---

Originally Posted by Elysia

Yep, everyone is picking on me today :eek: :p
But I already demonstrated I was wrong and edited the first post to match.

---

No, it's just at the time I posted, the other four posts above weren't there yet.

Endianness is not so much about efficiency, though historically little endian allowed a shortcut when it came to incrementing an int value. You could simply increment the first byte, and that would usually by enough. Or something like that so I've heard.

Both have advantages, they're just different.
In little endian, you can convert an int pointer to a short pointer or byte pointer to the same value without the memory address having to be altered. You make the type bigger by adding more bytes at the end.
However in big-endian, the value as an int appears the same way when you view the bytes by themselves, so debugging can be much easier.

Quote:

---

Originally Posted by iMalc

In little endian, you can convert an int pointer to a short pointer or byte pointer to the same value without the memory address having to be altered.

---

Actually, I think that's Big Endian that has that benefit, because the least significant byte is on the left.

Maybe they should combine the advantages of the two and have Reverse Left Endian. Just have the least significant BIT start at the left and then everything higher can go to the right.

Quote:

---

Originally Posted by cpjust

Actually, I think that's Big Endian that has that benefit, because the least significant byte is on the left.

Maybe they should combine the advantages of the two and have Reverse Left Endian. Just have the least significant BIT start at the left and then everything higher can go to the right.

---

HUH? What is this completely insane left/right stuff?

What makes you think the CPU has any concept of "left," why would it matter, what does it have to do with anything?

Or am I missing some sort of joke here?

Quote:

---

Originally Posted by brewbuck

HUH? What is this completely insane left/right stuff?

What makes you think the CPU has any concept of "left," why would it matter, what does it have to do with anything?

Or am I missing some sort of joke here?

---

Oops, I meant "Reverse Little Endian".

But to put it another way: Big Endian lets you write hex values from left to right, but the bits are not all sequencial, and with Little Endian the bits are sequencial, but the hex value is read right to left. So if you combine Little & Big Endian, you could have the bits sequencial and still read the hex bytes from left to right.

Quote:

---

Originally Posted by cpjust

Oops, I meant "Reverse Little Endian".

But to put it another way: Big Endian lets you write hex values from left to right, but the bits are not all sequencial, and with Little Endian the bits are sequencial, but the hex value is read right to left. So if you combine Little & Big Endian, you could have the bits sequencial and still read the hex bytes from left to right.

---

I think you are missing the point. The CPU has no idea of spatial organization of bits. Talking about left and right is meaningless. The issue with endianness is whether the least significant byte goes at the lowest address or the highest address. We're talking about low and high, not right and left. The idea that the lowest address is somehow "left of" higher addresses is just a human delusion.

Quote:

---

Originally Posted by cpjust

Actually, I think that's Big Endian that has that benefit, because the least significant byte is on the left.

Maybe they should combine the advantages of the two and have Reverse Left Endian. Just have the least significant BIT start at the left and then everything higher can go to the right.

---

No, I had it right.
I programmed on 680x0 (big-endian) Macs for many years, then switched to programming x86 (little-endian) PCs for many more years. It is definitely as I said.

As brewbuck states, there is no concept of the direction of the bits within each byte.
There is no way to combine the bennefits of both either.