Re: __IEEE_*_ENDIAN vs. BYTE_ORDER

[Jeff Johnston <jjohnstn at redhat dot com>]

Ralf Corsepius wrote:
> 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>

Yes and yes, but historically this hasn't always been followed.

> >  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.

I have begun putting a patch together that has the default sys/param.h include 
both a machine/endian.h and a machine/param.h.  The reason for the 
machine/param.h is that ARM currently redefines HZ to 100 in 
sys/arm/sys/param.h.  I am moving this to machine/arm/machine/param.h.  I am 
also removing sysvi386/sys/param.h as it should be able to use the default now.

Both linux and RTEMS have their own sys/param.h and machine/param.h.  Both are 
consistent and won't use the default include files.  The linux directory 
actually has set up its own machine structure so it can add future platforms. 
The RTEMS directory will only get the one machine/param.h unless it overrides 
this outside of newlib.

-- Jeff J.