Big Endian and Little Endian

[bhatia]

Hello all,

If I have a C-like data structure such that

struct Data {
int a; //16-bit value
char[3]; //3 ASCII characters
int b; //32-bit value
int c; //24-bit value
}

then assuming I were to store this on a 32 bit wide byte addressable
memory,
then, say, if a= 0A 0B, b=43 44 45, c= 80 00 00 44 and d = 123 (all in
hex), then would I be correct in saying that in a big endian
architecture it
would be stored like the following:

Address 0: 0A 0B 43 44
Address 1: 45 80 00 00
Address 2: 44 00 01 23

and in a little endian:

Address 0: 0B 0A 43 44
Address 1: 45 44 00 00
Address 2: 80 23 01 00

??

I assume this is correct but would appreciate a check nonetheless.

What I wanted to know was if I were to copy
byte by byte (in the more probable scenario you have described) from
the
little endian architecture to the big endian architecture would I end
up
with the same ordering as in the big endian and therefore need to swap
bytes? In other words, if my little endian architecture stores data in
the
following form:

Address 0: 0B 0A 43 44
Address 1: 45 44 00 00
Address 2: 80 23 01 00

and I were to copy this byte by byte to a big endian architecture is
this
what I would end up with:

Address 0: 0B 0A 43 44
Address 1: 45 44 00 00
Address 2: 80 23 01 00

??

or would it look completely different?

What if instead of copying byte by byte I were to copy word by word
(i.e. an
entire address at the time) would I still end up with the same result?

Thanks in anticipation

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

If I have a C-like data structure such that

struct Data {
int a; //16-bit value
char[3]; //3 ASCII characters
int b; //32-bit value
int c; //24-bit value
}

I don't know any C-like language that assigns different sizes to int
according to comments. Asking for concrete answers about pseudocode has
little sense.

hex), then would I be correct in saying that in a big endian
architecture it would be stored like the following:

No. The compiler can add padding bytes to align fields to multiples of 2, or
four, or any other thing the designers of the compiler decide is good for
that machine.

If you copy byte by byte the result is a copy byte by byte, no rocket
science involved. But the tool used to do the copy can have his own
peculiarities.

 

[Robbie Hatley]

Hello all,

If I have a C-like data structure such that

struct Data {
int a; //16-bit value
char[3]; //3 ASCII characters
int b; //32-bit value
int c; //24-bit value
}

then assuming I were to store this on a 32 bit wide byte addressable
memory,
then, say, if a= 0A 0B, b=43 44 45, c= 80 00 00 44 and d = 123 (all in
hex), then would I be correct in saying that in a big endian
architecture it
would be stored like the following:

Address 0: 0A 0B 43 44
Address 1: 45 80 00 00
Address 2: 44 00 01 23

and in a little endian:

Address 0: 0B 0A 43 44
Address 1: 45 44 00 00
Address 2: 80 23 01 00

Not quite. Firstly, address 0 is illegal. Real addresses will always
be non-zero. Secondly, I'm pretty sure most (all?) computers address
data by byte, not by word.

But those things aside, you have roughly the right idea. It would
look more like this, though:

int Var = 0x0A0B4344; // stored at RAM address 0x1B5A3A40, let's say.
Little-Endian representation:
0x1B5A3A40 44
0x1B5A3a41 43
0x1B5A3a42 0B
0x1B5A3a43 0A

Big-Endian representation:
0x1B5A3a40 0A
0x1B5A3a41 0B
0x1B5A3a42 43
0x1B5A3a43 44

If I were to copy byte by byte (in the more probable scenario
you have described) from the little endian architecture to the
big endian architecture would I end up with the same ordering
as in the big endian and therefore need to swap bytes?

Yes. Which is why you wouldn't want to do it byte-by-byte.
Copy the data value by value instead, and you'll be fine.
For instance, say you have an int, 87456, store in a little-endian
RAM or hard-disk. Transfer the whole number to a big-endian system
and it will be stored differently there, but will remain 87456.

If you must transfer data byte-by-byte between systems of different
endian-ness, then you will have to handle the re-ordering of the
bytes in your software. In the case of big-endian to little-endian
(or vice-versa), a simple reversal is called for. One trick I can
think of uses typecasting:

// on a big-endian system:
unsigned char InputArray[4];
unsigned char Reorder[4];
// Load bytes from little-endian system into InputArray.
// Then reorder the bytes:
Reorder[0] = InputArray[3];
Reorder[1] = InputArray[2];
Reorder[2] = InputArray[1];
Reorder[3] = InputArray[0];
// Typecast array of unsigned char back to int:
int MyInteger = *reinterpret_cast<int*>(&Reorder[0]);
// Reuse InputArray and Reorder to reconstitue further 32bit values.


--
Cheers,
Robbie Hatley
Tustin, CA, USA
lonewolfintj at pacbell dot net
(put "[usenet]" in subject to bypass spam filter)
http://home.pacbell.net/earnur/