This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Robust detection of endianness at compile time.
- From: Dean Anderson <dean at av8 dot com>
- To: tprince at computer dot org
- Cc: Ian Lance Taylor <iant at google dot com>, Andrew Haley <aph-gcc at littlepinkcloud dot COM>, Lee Rhodes <lee at rhoba dot com>, <gcc-help at gcc dot gnu dot org>
- Date: Mon, 30 Jul 2007 20:59:38 -0400 (EDT)
- Subject: Re: Robust detection of endianness at compile time.
MIPS could do big endian or little endian, as I recall. It was up to
the OS/hardware to select which.
I can't remember which flavor OSF/1 used on the MIPS. Same as Ultrix,
no doubt. I don't remember what ultrix used, either. Probably same as
Vax...oh yeah. ;-)
--Dean
On Mon, 30 Jul 2007, Tim Prince wrote:
> Ian Lance Taylor wrote:
> > Andrew Haley <aph-gcc@littlepinkcloud.COM> writes:
> >
> >
> >> AC_C_BIGENDIAN is for integers. As far as I am aware the PDP/ARM
> >> "middle-endian" problem only applies to floating-point words, and the
> >> situation for those is far more complex than mere endianness. Not
> >> every platform supports the IEEE-754 format, and picking apart other
> >> formats requires special-case programming. Happily, this isn't a
> >> problem that most people have to solve.
> >>
> Plauger's "Standard C Library" used short data types throughout when
> manipulating float and double, as VAX/ MIPS style data were still in
> fairly widespread use. I guess a phase of history has passed when no
> one invokes the way VAX and MIPS did things. Plauger's code would have
> worked for PDP; I wasn't aware of ARM floating point.
>
>
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000