__IEEE_*_ENDIAN vs. BYTE_ORDER

[Jeff Johnston]

Jeff Johnston wrote:
> 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.
>

I have checked the patch in.  I modified the RTEMS sys/param.h to include the 
new machine/endian.h.  This should solve your original problem with arm-rtems. 
Let me know if you run into any problems.

-- Jeff J.