How to determine the way data is stored in memory?

[Abhishek]

lets consider that I have defined an integer like this.
int a=5;
now taking the fact that an integer is allocated 2 bytes in memory and
the memory address increases in the left to right direction, which way
is the 16bit representationof 5 stored..
i.e 15 is 0000000000001111 representation in binary right? if the
memory address increases in left to right direction with each memory
address being capable of holding 8bits (i.e 1 byte)..can u tellme the
structure in which it is stored..is it like this???
00 00 00 00 00 00 11 11
^lesser address ^greater address.
or is it in different format?
Please elaborate.
Thank you very much for ur patience.
Bye

 

[Vladimir S. Oka]

lets consider that I have defined an integer like this.
int a=5;
now taking the fact that an integer is allocated 2 bytes in
memory and the memory address increases in the left to right
direction, which way is the 16bit representationof 5 stored..
i.e 15 is 0000000000001111 representation in binary right? if
the memory address increases in left to right direction with
each memory address being capable of holding 8bits (i.e 1
byte)..can u tellme the structure in which it is stored..is it
like this??? 00 00 00 00 00 00 11 11
^lesser address ^greater address.
or is it in different format?
Please elaborate.
Thank you very much for ur patience.
Bye

There's nothing really to elaborate -- it depends on the
hardware you're using. These generally come in low- and
high-endian flavours (lower order vs higher order bits first,
respectivelly), but there's nothing proscribing something
weirder.

Cheers

Vladimir

 

[Gordon Burditt]

lets consider that I have defined an integer like this.

int a=5;
now taking the fact that an integer is allocated 2 bytes

That is an assumption that is true only on some machines.

Also be aware that the C standard denies and stomps on and spits
on the assumption that "byte" is equivalent to "octet", although
some implementations do that.

in memory and
the memory address increases in the left to right direction, which way

Memory addresses do not have "left" or "right" direction.
The assumption that an integer is represented as big-endian
is only true on some machines.

is the 16bit representationof 5 stored..
i.e 15 is 0000000000001111 representation in binary right? if the
memory address increases in left to right direction with each memory
address being capable of holding 8bits (i.e 1 byte)..can
u

u is a structure in a UNIX V6 kernel. I don't see how it's
relevant here.

tellme the
structure in which it is stored..is it like this???
00 00 00 00 00 00 11 11
^lesser address ^greater address.

If you are claiming that two bits are stored per byte, and that a
16-bit integer takes up 8 octets, that's not true of any C
implementation.

or is it in different format?
Please elaborate.
Thank you very much for ur patience.

A core dump in binary of the integer you describe might be:

00000000 00001111

ASSUMING: CHAR_BIT = 8, 16-bit integer, and bit-endian.

Gordon L. Burditt

 

[Vladimir S. Oka]

There's nothing really to elaborate -- it depends on the
hardware you're using. These generally come in low- and
high-endian flavours (lower order vs higher order bits first,
respectivelly), but there's nothing proscribing something
weirder.

Cheers

Vladimir

Sorry, hit send too quickly...

The way to determine how your machine stores data:

Initialise an int variable to something with different high- and
low-order bits. Point to it using a char* and read out the
value there. If on your system char is narrower than an int,
you're in luck, and will be able to tell the endianness based
on the value read. if sizeof int == sizeof char, you could try
to use long, instead of int, or any integer type that's wider
than char.

In any case the exercise should be fun... ;-)

Cheers

Vladimir

 

[gamehack]

If your C implementation provides stdint.h you can use this:

void check_endianness(void)
{
int32_t b = 1;

int8_t* i;
i = (int8_t*) &b;

if(*i == 1)
{
printf("Little endian\n");
}
else
{
printf("Big endian\n");
}

}

lets consider that I have defined an integer like this.
int a=5;
now taking the fact that an integer is allocated 2 bytes in memory and...

[snip]

 

[Abhishek]

thank you.

 

[Abhishek]

can you please explain how can this program validate such an
assumption?
Please explain it to me line by line. I have not used that header file
anytime before.
Thank you very much for your interest.
bye

 

[Rod Pemberton]

lets consider that I have defined an integer like this.
int a=5;
now taking the fact that an integer is allocated 2 bytes in memory and
the memory address increases in the left to right direction, which way
is the 16bit representationof 5 stored..
i.e 15 is 0000000000001111 representation in binary right? if the
memory address increases in left to right direction with each memory
address being capable of holding 8bits (i.e 1 byte)..can u tellme the
structure in which it is stored..is it like this???
00 00 00 00 00 00 11 11
^lesser address ^greater address.
or is it in different format?
Please elaborate.
Thank you very much for ur patience.
Bye

There are two common methods that I know of for determining endianess.
These can be extended to show the actual ordering.
1) using casts, get the char at the address of an int set to one(1), if it's
one then it's little endian

int x=1;
if((*(char*)&x)==1) {/* little endian */ }

2) setup a union with a long and char types, set the long to one(1), if the
low char is one the it's little endian
union {long Long; char Char[sizeof(long)]} u;
u.Long=1;
if(u.Char[0]==1) {/* little endian */}

The second case could be extended to show you the exact ordering by spitting
out the other values of Char[].


Rod Pemberton

 

[gamehack]

Now look:

void check_endianness(void)
{

int32_t b = 1;

int8_t* i;
i = (int8_t*) &b;

if(*i == 1)
{
printf("Little endian\n");
}
else
{
printf("Big endian\n");
}

}

int32_t b = 1;
This defines an 32 bit integer and assigns it's value to 1. Now imagine
how this happens in memory (hex notation):
0x00 0x00 0x00 0x01 -> This how the actual number is in hex
If it is big-endian(the number ends in the big end, i.e. the last
memory location from left to right) the number will be stored as:

Addr0 Addr1 Addr2 Addr3
0x00 0x00 0x00 0x01

If it was little end, it will end in the little end(smallest address),
so it will be:

Addr0 Addr1 Addr2 Addr3
0x01 0x00 0x00 0x00

Then int8_t* i; creates a pointer to a byte(an octet in this case) and
this i = (int8_t*) &b; assigns Addr0 to i. So I have the contents of
Addr0 in my *i variable.

Now look up again. If *i == 1 it means that the number ended on the
little end => little endian, if not => big endian. Do you understand
the code now?

Regards

 

[Ian Collins]

can you please explain how can this program validate such an
assumption?

Can you please lean to quote - how can someone explain a program if you
don't quote it?

The header provides a number of C99 typdefs for exact and inexact
integer types, specifying the size in bits. So a uint32_t is a 32 bit
unsigned int.

The program simply assigns 1 to a 32 bit int and tests to see if the
first byte is 1, if so, you have a little endian machine.

Ian

 

[Gordon Burditt]

The header provides a number of C99 typdefs for exact and inexact

integer types, specifying the size in bits. So a uint32_t is a 32 bit
unsigned int.

The program simply assigns 1 to a 32 bit int and tests to see if the
first byte is 1, if so, you have a little endian machine.

Maybe. There are 24 possible orders for a 4-octet integer, and
6 of them end up with the first octet being 1. Only one of those
orders is "little-endian". NOT having a first octet of 1 does
NOT mean the order is "big-endian".

Gordon L. Burditt

 

[CBFalconer]

can you please explain how can this program validate such an
assumption? Please explain it to me line by line. I have not
used that header file anytime before.

You have failed to include any context, thus making your article
meaningless to most. Do not assume readers can see, or have ever
received, any preceding articles in a thread. Do include adequate
context, so your article stands by itself. Google is not Usenet.

Read my sig and the URL referenced therein BEFORE posting again,
please.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Ian Collins]

Maybe. There are 24 possible orders for a 4-octet integer, and
6 of them end up with the first octet being 1. Only one of those
orders is "little-endian". NOT having a first octet of 1 does
NOT mean the order is "big-endian".

I was simply explaining the example provided.

Can you point me at a machine that uses one of the other 22 orders, I'd
like to play with one....

 

[Jordan Abel]

I was simply explaining the example provided.

Can you point me at a machine that uses one of the other 22 orders, I'd
like to play with one....

the PDP-11. 0x12345678L is stored as 34 12 78 56

 

[Rod Pemberton]

I was simply explaining the example provided.

Can you point me at a machine that uses one of the other 22 orders, I'd
like to play with one....

Any little-endian 16-bit CPU will come up as 'middle-endian' when judging by
32-bit byte order. Once, everything goes 64-bit, we'll have the same
problem with little-endian 32-bit CPUs, such as Intel and AMD, when judging
by 64-bit byte order.


Rod Pemberton

 

[Ian Collins]

the PDP-11. 0x12345678L is stored as 34 12 78 56

Good point, though I haven't played with one of those for 20 years...

Maybe the original example should have used unsigned rather than uint32_t.

 

[Jordan Abel]

Any little-endian 16-bit CPU will come up as 'middle-endian' when judging by
32-bit byte order. Once, everything goes 64-bit, we'll have the same
problem with little-endian 32-bit CPUs, such as Intel and AMD, when judging
by 64-bit byte order.

I thought the PDP was a special case - the designers of the floating
point hardware not talking to the designers of the integer hardware, and
that modern systems try to keep consistent.

[read: little-endian 32-bit cpus will probably store 64-bits as struct
{ lo, hi } ]

 

[Stan Milam]

If your C implementation provides stdint.h you can use this:

void check_endianness(void)
{
int32_t b = 1;

int8_t* i;
i = (int8_t*) &b;

if(*i == 1)
{
printf("Little endian\n");
}
else
{
printf("Big endian\n");
}

}

Or,
int
is_big_endian( void )
{
short s = 0x0001;
char *c = (char *) &s;
return (c[sizeof(short) - 1] == 1);
}

Regards,
Stan Milam.

 

[Keith Thompson]

Any little-endian 16-bit CPU will come up as 'middle-endian' when judging by
32-bit byte order. Once, everything goes 64-bit, we'll have the same
problem with little-endian 32-bit CPUs, such as Intel and AMD, when judging
by 64-bit byte order.

I don't see why. The PDP-11 is the only system I know of that has
ever used inconsistent ordering (which is not to say that no such
systems exist).