Discussion:
Changing to use IEEE floating point on Alpha
(too old to reply)
Frank Gribbin
2017-04-19 16:40:32 UTC
Permalink
Raw Message
Does anyone have advice about changing from using VAX floating point representation to IEEE_FLOATING point. What are the pitfalls?

I'm tempted to do this to exchange floating point values between the Alpha and a linux box. I have a test FORTRAN TCP/IP server program that exchanges data with a python client on the linux box. I use struct in python to pack/unpack and swap the bytes. I use FORTRAN because my existing application does.

The FORTRAN and C compilers have /FLOAT=IEEE_FLOAT qualifier. So I could rebuild with that option (and remember to build our libraries that are built infrequently).

The original idea was to convert values to strings for exchange.

I'm using VMS 7.3-2 on an AlphaStation 255/233
Stephen Hoffman
2017-04-19 16:47:47 UTC
Permalink
Raw Message
Post by Frank Gribbin
Does anyone have advice about changing from using VAX floating point
representation to IEEE_FLOATING point. What are the pitfalls?
Search for discussions of floating point here:
http://h41379.www4.hpe.com/doc/82final/vax-to-itanium-porting.pdf
Yeah, you're not porting to Itanium, but the VAX to IEEE considerations
and changes are very similar if not the same; VAX to Itanium, or VAX to
Alpha.
--
Pure Personal Opinion | HoffmanLabs LLC
Bob Gezelter
2017-04-19 17:08:44 UTC
Permalink
Raw Message
Post by Frank Gribbin
Does anyone have advice about changing from using VAX floating point representation to IEEE_FLOATING point. What are the pitfalls?
I'm tempted to do this to exchange floating point values between the Alpha and a linux box. I have a test FORTRAN TCP/IP server program that exchanges data with a python client on the linux box. I use struct in python to pack/unpack and swap the bytes. I use FORTRAN because my existing application does.
The FORTRAN and C compilers have /FLOAT=IEEE_FLOAT qualifier. So I could rebuild with that option (and remember to build our libraries that are built infrequently).
The original idea was to convert values to strings for exchange.
I'm using VMS 7.3-2 on an AlphaStation 255/233
Frank,

Generally, I have not seen problems with switching code back and forth between VAX and IEEE.

As you have noted, it is important to keep the two formats separate. I would recommend keeping the objects in separate, parallel libraries. I would mark the executables and shareable library images with names clearly identifying which floating point format is used. This prevents the error of mixing different types and libraries.

A note of caution. There are codes which depend upon the precise limits of the floating point representation. The question of whether such dependencies is "common" is irrelevant. If the codebase has such dependencies, they should be modified to be based on appropriate conditionalization and parameterized (presuming that there will be a period when both the VAX and IEEE versions are active). As examples, I have seen such dependencies make appearances in random number generators and code which implements various mathematical functions.

- Bob Gezelter, http://www.rlgsc.com
David Froble
2017-04-19 17:12:23 UTC
Permalink
Raw Message
Post by Frank Gribbin
Does anyone have advice about changing from using VAX floating point representation to IEEE_FLOATING point. What are the pitfalls?
I'm tempted to do this to exchange floating point values between the Alpha and a linux box. I have a test FORTRAN TCP/IP server program that exchanges data with a python client on the linux box. I use struct in python to pack/unpack and swap the bytes. I use FORTRAN because my existing application does.
The FORTRAN and C compilers have /FLOAT=IEEE_FLOAT qualifier. So I could rebuild with that option (and remember to build our libraries that are built infrequently).
The original idea was to convert values to strings for exchange.
I'm using VMS 7.3-2 on an AlphaStation 255/233
Off the top of my head, what there is of it these days, I seem to recall that
the IEEE format has one bit less precision. Usually doesn't matter, but good to
know.

I also seem to remember that on Alpha, D_Float values are converted to IEEE for
operations, then converted back. Not sure how much my memory is to be trusted.

Text would probably be more bullet proof ....

If you're considering modifying your software, be aware of the need to convert
all your data files.
a***@yahoo.com
2017-04-19 17:55:32 UTC
Permalink
Raw Message
Post by David Froble
Post by Frank Gribbin
Does anyone have advice about changing from using VAX floating point representation to IEEE_FLOATING point. What are the pitfalls?
I'm tempted to do this to exchange floating point values between the Alpha and a linux box. I have a test FORTRAN TCP/IP server program that exchanges data with a python client on the linux box. I use struct in python to pack/unpack and swap the bytes. I use FORTRAN because my existing application does.
The FORTRAN and C compilers have /FLOAT=IEEE_FLOAT qualifier. So I could rebuild with that option (and remember to build our libraries that are built infrequently).
The original idea was to convert values to strings for exchange.
I'm using VMS 7.3-2 on an AlphaStation 255/233
Off the top of my head, what there is of it these days, I seem to recall that
the IEEE format has one bit less precision.
No, it isn't.
IEEE binary64 has the same precision as VAX G_Floating and the same # of bit in exponent.
Exponent range is smaller by 1, yes, in order to make space for subnormals.
And exponent bias is also off by 1.

Same for IEEE binary32 vs VAX F_Floating
Post by David Froble
Usually doesn't matter, but good to
know.
I also seem to remember that on Alpha, D_Float values are converted to IEEE for
operations, then converted back. Not sure how much my memory is to be trusted.
IEEE 754 has no direct equivalent of VAX D_Floating.
Post by David Froble
Text would probably be more bullet proof ....
If you're considering modifying your software, be aware of the need to convert
all your data files.
John Reagan
2017-04-19 21:19:39 UTC
Permalink
Raw Message
Post by David Froble
Post by Frank Gribbin
Does anyone have advice about changing from using VAX floating point representation to IEEE_FLOATING point. What are the pitfalls?
I'm tempted to do this to exchange floating point values between the Alpha and a linux box. I have a test FORTRAN TCP/IP server program that exchanges data with a python client on the linux box. I use struct in python to pack/unpack and swap the bytes. I use FORTRAN because my existing application does.
The FORTRAN and C compilers have /FLOAT=IEEE_FLOAT qualifier. So I could rebuild with that option (and remember to build our libraries that are built infrequently).
The original idea was to convert values to strings for exchange.
I'm using VMS 7.3-2 on an AlphaStation 255/233
Off the top of my head, what there is of it these days, I seem to recall that
the IEEE format has one bit less precision. Usually doesn't matter, but good to
know.
I also seem to remember that on Alpha, D_Float values are converted to IEEE for
operations, then converted back. Not sure how much my memory is to be trusted.
D float is converted to/from G float, not IEEE.
David Froble
2017-04-19 22:24:16 UTC
Permalink
Raw Message
Post by John Reagan
Post by David Froble
Post by Frank Gribbin
Does anyone have advice about changing from using VAX floating point representation to IEEE_FLOATING point. What are the pitfalls?
I'm tempted to do this to exchange floating point values between the Alpha and a linux box. I have a test FORTRAN TCP/IP server program that exchanges data with a python client on the linux box. I use struct in python to pack/unpack and swap the bytes. I use FORTRAN because my existing application does.
The FORTRAN and C compilers have /FLOAT=IEEE_FLOAT qualifier. So I could rebuild with that option (and remember to build our libraries that are built infrequently).
The original idea was to convert values to strings for exchange.
I'm using VMS 7.3-2 on an AlphaStation 255/233
Off the top of my head, what there is of it these days, I seem to recall that
the IEEE format has one bit less precision. Usually doesn't matter, but good to
know.
I also seem to remember that on Alpha, D_Float values are converted to IEEE for
operations, then converted back. Not sure how much my memory is to be trusted.
D float is converted to/from G float, not IEEE.
Ah, well, senior moments ....
touc
2017-04-19 18:42:38 UTC
Permalink
Raw Message
Post by Frank Gribbin
Does anyone have advice about changing from using VAX floating point representation to IEEE_FLOATING point. What are the pitfalls?
I'm tempted to do this to exchange floating point values between the Alpha and a linux box. I have a test FORTRAN TCP/IP server program that exchanges data with a python client on the linux box. I use struct in python to pack/unpack and swap the bytes. I use FORTRAN because my existing application does.
The FORTRAN and C compilers have /FLOAT=IEEE_FLOAT qualifier. So I could rebuild with that option (and remember to build our libraries that are built infrequently).
The original idea was to convert values to strings for exchange.
I'm using VMS 7.3-2 on an AlphaStation 255/233
Depending upon your performance requirements then compiling with
IEEE_FLOAT is the way to go. htons/ntohs and friends are useful for
integer endian conversion and don't forget the routines such as
CVT$CONVERT_FLOAT and CVT$FTOF that will convert from/to most formats
and endians.

We regularly passed binary structures with numbers of varying formats
between Alpha, Sun and PCs (Linux & Wins) at several 10's thousands
messages per second ... it just works as expected with no drama.

Stephen Bainbridge
Stephen Hoffman
2017-04-19 19:43:22 UTC
Permalink
Raw Message
htons/ntohs and friends are useful for integer endian conversion....
FWIW... Little-known on OpenVMS, but also available is XDR:

https://tools.ietf.org/html/rfc1014.html
http://h30266.www3.hpe.com/odl/vax/network/tcpip53/rpc_prog/6528pro_007.html#xdr_chap


For Python, xdrlib can deal with for the other end of the connection.

ASN.1 is also available on OpenVMS via OpenSSL, as an alternative to
using XDR, and Python has various libraries available for ASN.1.

Of course rolling your own code works, too.
--
Pure Personal Opinion | HoffmanLabs LLC
Bob Koehler
2017-04-20 13:14:12 UTC
Permalink
Raw Message
Post by Stephen Hoffman
htons/ntohs and friends are useful for integer endian conversion....
https://tools.ietf.org/html/rfc1014.html
http://h30266.www3.hpe.com/odl/vax/network/tcpip53/rpc_prog/6528pro_007.html#xdr_chap
Yes, I think that is te one we used.
Frank Gribbin
2017-04-27 08:51:24 UTC
Permalink
Raw Message
Post by Frank Gribbin
Does anyone have advice about changing from using VAX floating point representation to IEEE_FLOATING point. What are the pitfalls?
I'm tempted to do this to exchange floating point values between the Alpha and a linux box. I have a test FORTRAN TCP/IP server program that exchanges data with a python client on the linux box. I use struct in python to pack/unpack and swap the bytes. I use FORTRAN because my existing application does.
The FORTRAN and C compilers have /FLOAT=IEEE_FLOAT qualifier. So I could rebuild with that option (and remember to build our libraries that are built infrequently).
The original idea was to convert values to strings for exchange.
I'm using VMS 7.3-2 on an AlphaStation 255/233
Frank Gribbin
2017-04-27 09:03:32 UTC
Permalink
Raw Message
Thanks to everyone for their thoughtful comments.

The mention of RTL CVT$FTOF is especially welcome, since I could just convert the necessary values on the Alpha before sending them.

I've also looked for routines that could do the conversion under linux but wihout success.
Loading...