Re: __IEEE_*_ENDIAN vs. BYTE_ORDER

[Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>]

On Mon, 2004-05-03 at 23:56, Jeff Johnston wrote:
> Ralf Corsepius wrote:
> > On Wed, 2004-04-28 at 23:21, Ralf Corsepius wrote:
> > 
> >>On Wed, 2004-04-28 at 22:45, Jeff Johnston wrote:
> >>
> >>>Ralf Corsepius wrote:
> >>>
> >>>>Hi,
> >>>>
> >>>>Newlib's sys/param.h applies __IEEE_*_ENDIAN (from machine/ieeefp.h) to
> >>>>define BYTE_ORDER.
> >>>>
> >>>>AFAIU, __IEEE_*_ENDIAN denotes the floating point endianess, only, which
> >>>>doesn't necessarily match with a CPU's general endianess.
> >>>>
> >>>>
> >>>>E.g. some arm-CPUs seem to use __IEEE_BIG_ENDIAN, while actually being
> >>>>little endian targets.
> >>>>
> >>>>On these targets newlib's sys/param.h results into
> >>>>#define __IEEE_BIG_ENDIAN
> >>>>#define BYTE_ORDER BIG_ENDIAN
> >>>>
> >>>>even for little endian arm targets, while I think
> >>>>#define __IEEE_BIG_ENDIAN
> >>>>#define BYTE_ORDER LITTLE_ENDIAN
> >>>>
> >>>>would have been correct.
> >>>>
> >>>>I.e. I suspect newlib's sys/param.h to be "illegally" using
> >>>>__IEEE_*_ENDIAN to setup BYTE_ORDER. I am wrong or right?
> >>>>
> >>>
> >>>Newlib's sys/param.h is simply defaulting.  Note that it checks to see if 
> >>>BYTE_ORDER is already defined.  In special cases such as the ARM where the byte 
> >>>order and the floating-point byte order don't match up, the sys/config.h file 
> >>>should have defined the BYTE_ORDER as appropriate.
> >>>
> >>>I believe the attached patch should do the trick.
> >>
> >>Thanks, I see how this works.
> >>
> >>However, wouldn't it be cleaner to separate BYTE_ORDER from
> >>__IEEE_*_ENDIAN, to implement a sys/endian.h header and use this header
> > 
> > Sorry, typo: s,sys/endian.h,machine/endian.h,
> > 
> > 
> >>in sys/params.h, similar to the way BSD handles this issue?
> > 
> 
> I went back and took another look at this.
FYI: I haven't yet tried your patch, yet and have been patch using a
machine/endian.h instead.

>   Actually, sys/param.h is already 
> being overridden when necessary by various platforms.  The ARM is one of these 
> and you will see a special sys/param.h in the libc/sys/arm directory.

Well, I should have been more precise: My target is arm-rtems. This
target applies libc/sys/rtems/param.h and ignores libc/sys/<cpu>/param.h

<thinking> 
Why libc/arm/sys/param.h? Shouldn't sys/*.h headers be reserved for
OS-dependent headers and shouldn't architecture dependent headers better
go to machine/*.h?
</thinking>

>   In this 
> file, a check is made for __ARMEB__ rather than the default above.

Hmm, I need to check the details, but if what you say applies, this
would either mean a bug in RTEMS support files in newlib or a general
issue configuration issue in newlib.

Ralf