# Thread: how can i find out whether my cpu is low indian or high indian?

1. ## how can i find out whether my cpu is low endian or high endian?

hello all, how can i determine which kind of cpu is being used in a system ?
how should i go about it ?
by teh way im looking for a portable solution meaning my source code can be compiled and executed on all platforms .
tanx in advance

2. Uh, well first of all, it's 'endian'. Anyway, easiest way is to cast the address of an integer to that of a char, and then check for a specific bit pattern, eg:

Code:
```
inline bool is_little_endian( void )
{
static size_t const
value = 1;
static bool const
result = *reinterpret_cast< char const* >( &value ) == 1;
return result;
}

inline bool is_big_endian( void )
{
return !is_little_endian( );
}```

3. Originally Posted by Sebastiani
Uh, well first of all, it's 'endian'. Anyway, easiest way is to cast the address of an integer to that of a char, and then check for a specific bit pattern, eg:

Code:
```
inline bool is_little_endian( void )
{
static size_t const
value = 1;
static bool const
result = *reinterpret_cast< char const* >( &value ) == 1;
return result;
}

inline bool is_big_endian( void )
{
return !is_little_endian( );
}```
Ahh, my bad ! thanks for saying that .
anyway, would you explain that bit of code alittle bit ? well im kinda confused !
i understand that we are trying to assign value's address (which would be an integer like 0x1245 for example ) to another variable! so that we can check its first bit (out of the 2 bit representing high and low value (precise and non-precise) for every variable in memory)
.well i dont know how to access that so called hight portion of a variable ! and how it is done in this example of yours!

4. Well just to be sure we're on the same page here, 'endian' is a matter of byte (not bit) order. Anyway, the basic idea is this: First we declare some type of integer larger than a byte. On most systems, size_t is sufficient. So let's say the variable has a hexidecimal value of 0x12345678 located at the address 0x40000000. Now, if we're running on a little-endian machine, the layout of the variable in memory is going to be:

[0x40000000] 0x78
[0x40000001] 0x56
[0x40000002] 0x34
[0x40000003] 0x12

So if we convert the base address of this 4-byte integer to a char* and dereference it, we will simply be extracting the byte at 0x40000000. If we check this byte and it turns up to be 0x78, then we know that the least significant byte came first, hence little-endian.

5. Originally Posted by Sebastiani
Well just to be sure we're on the same page here, 'endian' is a matter of byte (not bit) order. Anyway, the basic idea is this: First we declare some type of integer larger than a byte. On most systems, size_t is sufficient. So let's say the variable has a hexidecimal value of 0x12345678 located at the address 0x40000000. Now, if we're running on a little-endian machine, the layout of the variable in memory is going to be:

[0x40000000] 0x78
[0x40000001] 0x56
[0x40000002] 0x34
[0x40000003] 0x12

So if we convert the base address of this 4-byte integer to a char* and dereference it, we will simply be extracting the byte at 0x40000000. If we check this byte and it turns up to be 0x78, then we know that the least significant byte came first, hence little-endian.
Thanks a million Sebastiani .
now i get that .

6. bye the way i think i have some more qustions to ask ,
first of all whats the point in declaring those variables static ? is it important to do so ? or no its not crucial ?
and why did you used const ? is it good programming practice or no it is meant to be there! ?

and how can i for example see the third byte of a 4 Byte (size_t) variable ?we just did it for the first Byte , how can we extend this functionalty to other bytes of a variable ?
is the procedure the same ? or no it differs completely .
many thanks in advance

7. >> whats the point in declaring those variables static

A static variable is only initialized once, so it's just more efficient to do do it that way. Not necessarily crucial, though.

>> and why did you used const ? is it good programming practice

Basically, yes.

>> how can i for example see the third byte of a 4 Byte (size_t) variable ?

Just cast the address of the variable to a char* and then access it like an array, eg: ptr[ 2 ].

8. Originally Posted by Sebastiani
>> whats the point in declaring those variables static

A static variable is only initialized once, so it's just more efficient to do do it that way. Not necessarily crucial, though.

>> and why did you used const ? is it good programming practice

Basically, yes.

>> how can i for example see the third byte of a 4 Byte (size_t) variable ?

Just cast the address of the variable to a char* and then access it like an array, eg: ptr[ 2 ].
thanks bro, you are a genius
really tanx , a new horizon just appeared before my eyes
again tanx

9. You're welcome.

10. sorry to bother , but well i have another question , it just crossed my head!
well they say that in emulation , it is vital to know what kind of cpu you are emulating(target system cpu) and what cpu you are using for emulation ( your own cpu)
tell me how this scenario is correct in this case :
an emulator tries to run another system's codes,
for this it receives the instructions and then convert them into the machine language and then
stores them in the emulated ram "( here an array ;e.g 2d array !)
and then reads form that emulated ram (array)
so how is it going to be different on different cpu's ? i mean we are the one who map the opcodes in the correct order into the memory! not our cpu!

im kinda confused! how this high/low endian has to do with emulation!

11. Mostly it is about how data is stored in the "rom".
Say that you have an instruction that is supposed to be 0x12345678 (4 bytes).
If we read this into an int, on a little endian machine, we will get the wrong result because the least significant byte is first and on little endian, it comes last.

So basically we must know what type of endianess-format the target cpu is and what endianess the processor that does the emulation has, so that you do not screw up the information order.

12. Originally Posted by Elysia
Mostly it is about how data is stored in the "rom".
Say that you have an instruction that is supposed to be 0x12345678 (4 bytes).
If we read this into an int, on a little endian machine, we will get the wrong result because the least significant byte is first and on little endian, it comes last.

So basically we must know what type of endianess-format the target cpu is and what endianess the processor that does the emulation has, so that you do not screw up the information order.
thank you very much .
another question :
does different cpu manufacturers which utilize different architectures,use different cpu endianness-format ? or no they use a specific format for desktops and another one for lets say mainframes ?
i mean AMD cpus Vs Intel's .
they use different architecture i think , so are they different in endianness too?

13. All x86 cpus are little endian. There is a reason for that, of course. Otherwise all applications would stop working.
Other architectures does not need to use little endian, however.

14. thank very much you Elysia .

15. hmm! well it seems my questions today are not finishing!
im stuck here! i dont know how to get it to work!
i wrote
Code:
```size_t   value = 0x12345678;
size_t  * integer_pointer = &value;

char * char_pointer = reinterpret_cast<char *>(integer_pointer);```
now what! how am i supposed to derefrence it ?
im sure it is not sth like
Code:
`cout<<"the first byte is "<<*char_pointer !`
i tried to reinterpret it again as ( int * ) to get the answer but again it fails!
Code:
`cout<<"the first Byte is "<<*reinterpret_cast< size_t * > (char_pointer);`
again it doesnt give me 78!
(im trying to get to know the reinterpret_cast<>() a bit more , and specially to be able to reference different bytes of a variable through that char pointer ! thats why im doing it this way! dont know what else i can do for this kind of stuff!)
and by the way i encountered a weird issue!
Code:
`size_t const result = *reinterpret_cast< char const* > (& Variable_X);`
this code gives me almost always the correct answer! but sometimes when i change the value it gives me nonsense ! why ? what could be the cause ?

Popular pages Recent additions