Re: [boost] Optimized portable isnan, isfinite, fpclassify etc

From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2006-10-17 19:20:05

  I've got some additional comments about the endian'ness of HP-UX --
  see attached. To our slight embarrassment, while HP-UX/ia64 does
  predefine _BIG_ENDIAN macro, our other big-endian platform --
  PA-RISC -- does not. However, the proposed fallback strategy is
  guaranteed to generate the correct result for a platform where
  neither _BIG_ENDIAN nor _LITTLE_ENDIAN macro is defined.

  If people think, that this is a good idea to check _BIG_ENDIAN/
  _LITTLE_ENDIAN macro first and, then, fall back to OS/architecture
  check, I can submit an obvious, trivial patch for endian.hpp.

  To me, the crux of the matter is that while little-endian HP-UX/ia64
  is a remote possibility, it is not completely impossible. And if
  this creature ever comes to existence, it will define _LITTLE_ENDIAN
  macro, so the endian'ness check will continue to work.

"
> A compile time check is adequate.

True, but the proper way to check at compile time is to test for one
of the _BIG_ENDIAN or _LITTLE_ENDIAN macros. I believe most or all of
the big-endian Unix platforms define _BIG_ENDIAN = 1, but few of the
little-endian platforms define _LITTLE_ENDIAN. So I'd suggest
checking for one of the two macros, and then, only if neither of them
is set, fall back to checking the OS and architecture.

By the way, while unlikely, a little-endian HP-UX ABI on Integrity
isn't completely out of the question at some point in the future. We
already have the ability to compile little-endian code with our HP-UX
compiler, and the _BIG_ENDIAN macro is the way to tell which option
was used.
"

  And more of the discussion:

"
> The real question is: is little-endian HP-UX ABI on Integrity more
> than just an academic exercise? How can such code  operate on
> a big-endian OS?

Maybe not today, but who knows tomorrow? As I said, it may be
unlikely, but not so much so to completely ignore the possibility.
Checking for the appropriate macros first means the code won't have
to be changed if and when that possibility ever becomes reality.

The endianness is selected in the user mask portion of the PSR, so
it's completely under the application's control. We run Linux
executables today on HP-UX simply by having a layer that does the
endian switch at the system call boundary.
"

----- Original Message ----- 
From: "Johan Råde" <rade_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, October 17, 2006 11:43 AM
Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc

> Boris Gubenko wrote:
>> Boris Gubenko wrote:
>>> I'm checking with the OS folks and will report back here,
>>> for both HP-UX/ia64 and Tru64 Alpha.
>>
>> And the answer is:
>>
>>> You are correct that both platforms are capable of executing in
>>> either endianness.  However, the operating systems operate in only
>>> one.
>>> HP-UX is *always* big endian
>>> Tru64 is *always* little endian
>>> [...]
>>> Summary:
>>> A compile time check is adequate.
>>>
>>
>> So, with current <endian.hpp>, I think, that we are all set for
>> these platforms.
>>
>> Thanks,
>>   Boris
>>
>
> Excellent. Thanks for the help.
>
> --Johan
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>