Hi im, just wondering does anyone know what the default endian the gcc compiles the code in for basic gcc i think gcc.3.1.4
I'm basically asking cuz I want to know the .o object file the compiler makes is the endian based off the gcc compiler or based off the OS endian
Neither, AFAIK. Endianness is part of the CPU architecture, not the OS or compiler.
x86 is little-endian.
Where the endian is fixed in the architecture, you have no choice.
But for MIPS say, you have command line options
Originally Posted by GCC_for_MIPS
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
There are some architectures where you can choose, according to Wikipedia. No personal experience, just pointing out the fact.
@kiros88
Is there a specific reason why you're asking this? Someone might be able to answer your question, if you actually told us what that is.
gcc is a cross-compiler with support for lots of micro-architectures, so the endianness depends on the target architecture selected.
Technically, it IS a compiler thing. I mean, there's nothing that will avoid the compiler to represent everything in big endian, but when operations are executed swapping the bytes before doing so and then swapping them again.
I mean, it makes no sense for a compiler to do such a thing, but it's possible.
The reason the compiler chooses big/little endian is usually because it's just the best choice for an architecture. And I can't imagine any compiler using another endianess than the one used by the compiler.
The endianness of a specific microprocessor has nothing to do with the compiler, it is rooted solely in the micro-architecture.
The compiler has no choice but to conform to the specifications of the ABI which in turn has to conform to the micro's architecture.
The compiler doesn't choose - it has to conform to it. In cases where the micro is bi-endian, the compiler's behavior can be modified by options given on the command line.
I'm not quite sure the C/C++ standards mandate this. Does it even specify integers are stored in either big-endian or little-endian? May it not be a random third option? May a compiler not preform certain actions on an integer before and after addition, to make sure the values are stored in a different format?
For instance, I think it's allowed for a compiler to store every integer with one subtracted. It makes no sense, but it's allowed. So that if we do:
Will be stored as "\x02\x00\x00\x00" rather than "\x03\x00\x00\x00" in memory. As long as before any operation it is incremented and then decremented again to set the integer to the format the compiler choose, that would work perfectly.Code:int a = 3;
I can even think of situations where such things may be useful. Imagine there's a large application that is completely performance uncritical. A compiler might be free to use little endian, as the coders failed to support anything else due to some ........-ups at their side. Now the compiler might swap the bytes before and after all operations.
While this makes the application a lot slower, it may fix a lot of porting. It would be a dreadful hack, yes.
My point is not that it should be done. My point is that a compiler is still actually free to choose whatever it likes, I believe.
Well perhaps in theory this might be possible, however there is absolutely no point in writing a compiler that doesn't make optimum or nearly optimum use of the architecture it compiles on. Compilers and architectures go hand in hand in improving program efficiency at the instruction level.
1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
3. Get rid of conio.h and other antiquated DOS crap headers.
4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.
@EVOEx
Instructions are also data in memory. How would a CPU with little-endian architecture fetch correct instructions from memory if the byte order of those instructions was big-endian?
I kinda took it for granted that when he said "Where endian is fixed, you have no choice ... but for MIPS..." it meant there were some places it wasn't fixed, and you had a choice. Say MIPS for example.
Quzah.
Hope is the first step on the road to disappointment.
I missed that little "say".
My computer uses low-endian. When i declare an integer like this:
When printed in a file as binary i get this:Code:int x = (int('P') << 24) | (int('M') << 16) | (int('B') << 8) | 'G';
While i alligned the letters in big-endian, they were printed in little-endian as they should be. So i come to think that compilers use big-endian in order not to confuse their users. Think it like this:GBMP
00001110 is 14 in big-endian and 112 in little-endian but we tend to think from right to left when we see a number ( would you think 123 as 321? )
Devoted my life to programming...
No, shifting "respects" endianness. Therefore, int('P') << 24 pushes it to the far right.
Otherwise shifting would not be portable, and will be of very limited use on little-endian machines.
Then how do you explain what i said? ( I'm sure i have little-endian system )
How do you explain that the letters were printed the opposite way???
Devoted my life to programming...
