Re: Unix to Vax floating point conversion [message #4877 is a reply to message #4873] |
Tue, 15 August 1995 00:00  |
landsman
Messages: 93 Registered: August 1991
|
Member |
|
|
In article <40r3ah$rb0@saba.info.ucla.edu>, "R. David Baker" <rbaker> writes...
> We are using PVWave Version 5.0 on a VMS Vax, and need to read in IEEE
> binary from a Sun Sparc2. We tried to use the CONV_UNIX_VAX procedure
> from the IDL Astronomy User's Library
> (http://idlastro.gsfc.nasa.gov/contents.html), but didn't get it to
> work correctly. Here's what we did:
>
> CONV_UNIX_VAX,t,source_arch='sparc'
>
>
> The array t should be a 100 element array with floating values
> from 1.0 to 100.0. When we 'print,t', things look good except for
> numbers of even powers of two, i.e. 0,4,16,64. These values are set
> to 0.0 instead of the appropriate power of two. Any suggestions?
This works in IDL and so I suspect that there is a bug in the version of
PV-WAVE that you are using. Let me briefly quote from the IDL help for
the /FTOXDR (float to XDR) keyword to BYTEORDER:
"VAX Warning: Do not attempt to interpret an XDR (=Sparc) format
floating-point number as a native floating number on a VAX. VAXen generate
an illegal instruction trap when the CPU encounters illegal floating point
values. Under VAX/VMS the illegal value is automatically replaced with
zero and execution continues."
So the trick to doing the number conversions is to alway deal with bytes and
never interpret an XDR number on a VAX. In IDL Vax V4.0 there was a bug in
the /FTOXDR keyword, and another bug prevented one from even subscripting an
XDR number on a Vax. (Note: these bugs will be fixed in the next release of
IDL Vax VMS V4.0.1.) So I suspect that PV-WAVE 5.0 has a similar bug,
maybe when the converting the floating point number to bytes with the BYTE
extraction.
One solution would be to use CONV_UNIX_VAX on the SUN to convert
your numbers to VAX datatype, *before* transferring them to the VAX.
Note that none of the above problems apply to Alpha VMS machines, which
are considerably less finicky.
--Wayne Landsman landsman@sorbet.gsfc.nasa.gov
|
|
|