This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Endian[n]ess, language-specific problems and help with egcs.
- To: smith at vaj5184 dot tu dot hac dot com
- Subject: Re: Endian[n]ess, language-specific problems and help with egcs.
- From: Ian Lance Taylor <ian at cygnus dot com>
- Date: Tue, 18 Aug 1998 12:22:10 -0400
- CC: toon at moene dot indiv dot nluug dot nl, egcs at cygnus dot com
Date: Mon, 17 Aug 1998 10:00:45 -0700
From: Smith <smith@vaj5184.tu.hac.com>
I was wondering if there is a list of what endian[n]ess
a CPU/OS uses.
Not as such. In general, you can get this information from the
gcc/config/*/*.h files. Look for BYTES_BIG_ENDIAN. You can also find
this information in BFD in a GNU binutils distribution.
I also realize that it's more complicated
in that some CPU's like PPC support LE in addition to BE,
so does that mean that PPC's are BE under MacOS/Linux/BeOS,
and LE under NT?
It's correct that the PowerPC is biendian. I believe your system
assignments are correct.
And from what I've read, it also appears that Alpha and
SGI have some kind of support for both BE and LE.
I believe Alphas are always little endian. MIPS chips are either big
or little endian; I believe SGI systems are always big endian. The
old DECstations used MIPS chips in little endian mode.
I've also seen somewhere that VAX seemed to use neither BE
('1234') or LE ('4321'), but instead '2143' or something
like that. Is that right?
No. The Vax is always little endian. The weird endianness you
describe was used on the PDP-11.
The real reason I replied was so that I can mention my war story of
porting gcc 1.34 to the Alpha Micro. The Alpha Micro was an
intellectual descendant of the PDP-11, but it used a 68000. The
memory interface was cross wired so that memory appeared in PDP-11
endianness rather than the normal 68000 big endian. I ported gcc to
this system, and discovered that gcc has a remarkably wide-spread and
detailed assumption that the processor is either big or little endian,
affecting all sorts of optimizations particularly involving bitfields
and size-changing typecasts. Getting decent code for a mixed endian
processor was rather difficult, and was a lingering source of bugs for
a long time.
Ian