Boost :

Date view	Thread view	Subject view	Author view

From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2006-12-08 13:17:36

Next message: Andy: "[boost] Review Request: Guid"
Previous message: Daren Lee: "Re: [boost] [interprocess] linux porting problems"
In reply to: Johan Råde: "Re: [boost] Optimized portable isnan, isfinite, fpclassify etc"
Next in thread: Johan Råde: "Re: [boost] Optimized portable isnan, isfinite, fpclassify etc"
Reply: Johan Råde: "Re: [boost] Optimized portable isnan, isfinite, fpclassify etc"

Johan Rede wrote:

> Do both platforms support uint64_t?

No, they support __int64 and long long. uint64_t can be
typedef'ed as unsigned __int64 or unsigned long long.

> How is long double implemented in the VAX FP mode?
> Is it the same as double, or does it have more than 8 bytes?

On Tru64 and AlphaVMS (in both VAX FP modes and IEEE), there are two
types of long double: 128-bit long double and 64-bit long double. iVMS
supports only 128-bit double.

On Tru64 V5.0 and later, 128-bit long double is the default, but 64-bit
long double can be requested by compiling with -long_double_size 64 switch.
On VMS, it would be /l_double_size=[64,128] switch, but the default on VMS
has always been 128-bit long double. When /l_double_size=64 is specified
on iVMS, the compiler issues a warning and ignores the option.

The 64-bit long double is rarely used nowadays and this is why we have
dropped it for iVMS. I think, it would be completely reasonable if your
library asserts if the code was compiled for 64-bit long double. You can
recognize this case by checking the __X_FLOAT macro: for 64-bit long double
it is predefined as 0, otherwise, it is predefined as 1.

> How does the sign bit work in the VAX FP mode?
> Is it the leading bit of the leading byte?
> Do you reverse the sign of a number simply by flipping the sign bit?

The thing is that, while internal representation of (deprecated) 64-bit
long double depends on the floating-point mode, for 128-bit long double,
the internal representation is the same in all FP modes. If you want to
support VAX FP modes, this is another reason to support only 128-bit
long double across the board.

>> Based on the results I posted yesterday, is it correct to say that fpclassify
>> library passes the tests on both VMS platforms?
>
> That is correct. It has passed all tests on both VMS platforms,
> in both full ieee mode and fast ieee mode.

This is good!

> Could you run the attached version of the inspect tool on both platforms
> in VAX FP mode.

Attached results in the following order:

  AlphaVMS
    G_FLOAT
    D_FLOAT
  iVMS
    G_FLOAT
    D_FLOAT

AlphaVMS
========
CXXC::_5> @build inspect
HP C++ V7.1-018 for OpenVMS Alpha V7.3-2
AlphaServer 4100 5/533 4MB

*** G_FLOAT

This platform is big-endian.
BOOST_LITTTLE_ENDIAN is defined.

---------- float --------------------

0 00 00 00 00
sn.min -- -- -- --
-sn.min -- -- -- --
n.min/256 00 00 00 00
n.min/2 00 00 00 00
-n.min/2 00 00 00 00
n.min 80 00 00 00
1 80 40 00 00
3/4 40 40 00 00
4/3 aa 40 ab aa
max ff 7f ff ff
inf -- -- -- --
q.nan -- -- -- --
s.nan -- -- -- --

---------- double -------------------

0 00 00 00 00 00 00 00 00
sn.min -- -- -- -- -- -- -- --
-sn.min -- -- -- -- -- -- -- --
n.min/256 00 00 00 00 00 00 00 00
n.min/2 00 00 00 00 00 00 00 00
-n.min/2 00 00 00 00 00 00 00 00
n.min 10 00 00 00 00 00 00 00
1 10 40 00 00 00 00 00 00
3/4 08 40 00 00 00 00 00 00
4/3 15 40 55 55 55 55 55 55
max ff 7f ff ff ff ff ff ff
inf -- -- -- -- -- -- -- --
q.nan -- -- -- -- -- -- -- --
s.nan -- -- -- -- -- -- -- --

---------- long double --------------

0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
n.min/256 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
n.min/2 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00
-n.min/2 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 80
n.min 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00
1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 3f
3/4 00 00 00 00 00 00 00 00 00 00 00 00 00 80 fe 3f
4/3 55 55 55 55 55 55 55 55 55 55 55 55 55 55 ff 3f
max ff ff ff ff ff ff ff ff ff ff ff ff ff ff fe 7f
inf -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
q.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
s.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

*** D_FLOAT

This platform is big-endian.
BOOST_LITTTLE_ENDIAN is defined.

---------- float --------------------

---------- double -------------------

0 00 00 00 00 00 00 00 00
sn.min -- -- -- -- -- -- -- --
-sn.min -- -- -- -- -- -- -- --
n.min/256 00 00 00 00 00 00 00 00
n.min/2 00 00 00 00 00 00 00 00
-n.min/2 00 00 00 00 00 00 00 00
n.min 80 00 00 00 00 00 00 00
1 80 40 00 00 00 00 00 00
3/4 40 40 00 00 00 00 00 00
4/3 aa 40 aa aa aa aa a8 aa
max ff 7f ff ff ff ff f8 ff
inf -- -- -- -- -- -- -- --
q.nan -- -- -- -- -- -- -- --
s.nan -- -- -- -- -- -- -- --

---------- long double --------------

CXXC::_5>

iVMS
====
ICXX::_2> @build inspect
HP C++ V7.2-021 on OpenVMS IA64 V8.3
HP rx2600 (1.30GHz/3.0MB)

*** G_FLOAT

This platform is big-endian.
BOOST_LITTTLE_ENDIAN is defined.

---------- float --------------------

---------- double -------------------

---------- long double --------------

*** D_FLOAT

This platform is big-endian.
BOOST_LITTTLE_ENDIAN is defined.

---------- float --------------------

---------- double -------------------

---------- long double --------------

ICXX::_2>

Next message: Andy: "[boost] Review Request: Guid"
Previous message: Daren Lee: "Re: [boost] [interprocess] linux porting problems"
In reply to: Johan Råde: "Re: [boost] Optimized portable isnan, isfinite, fpclassify etc"
Next in thread: Johan Råde: "Re: [boost] Optimized portable isnan, isfinite, fpclassify etc"
Reply: Johan Råde: "Re: [boost] Optimized portable isnan, isfinite, fpclassify etc"

Date view	Thread view	Subject view	Author view

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk