VAX D-Float format
Chieh Cheng
I am trying to decode and decipher Intergraph Microstation's Design
file format. It uses the VAX D-Float format. Although it is also 64
bit long, it is somewhat different from the IEEE double float format.
The format is as follows:
bit 15: sign
bit 14 - 7: Exponent
bit 6 - 0: Exponent
bit 16 to 63 is the fraction. I assume it is one fraction, however,
the diagram in the book divided it into three equal parts. Like the
exponent shown above.
Can someone help me with this format? How can I convert this binary
data to a double float?
Any help is greatly appreciated. Thanks.
Gregg E Economou
>Can someone help me with this format? How can I convert this binary
>data to a double float?
what machine are you doing this on? Ultrix has routines to convert between
the IEEE and VAX floating formats as an extension to the standard
library.
Steve Lionel
In article <34575f82....@serve.installshield.com>,
chieh...@geocities.com (Chieh Cheng) writes:
|>I am trying to decode and decipher Intergraph Microstation's Design
|>file format. It uses the VAX D-Float format. Although it is also 64
|>bit long, it is somewhat different from the IEEE double float format.
Here's the description of VAX floating formats from the OpenVMS FAQ:
VAX2. What is the layout of the VAX floating point format?
The VAX floating point format is derived from one of the PDP-11 FP formats,
which helps explain its strange layout. There are four formats defined:
F 32-bit single-precision, D and G 64-bit double-precision and H 128-bit
quadruple precision. For all formats, the lowest addressed 16-bit "word"
contains the sign and exponent (and for other than H, some of the most
significant fraction bits). Each successive higher-addressed word contains
the next 16 lesser-significant fraction bits. Bit 15 of the first word is the
sign, 1 for negative, 0 for positive. Zero is represented by a biased
exponent value of zero and a sign of zero; the fraction bits are ignored (but
on Alpha, non-zero fraction bits in a zero value cause an error.) A value
with biased exponent zero and sign bit 1 is a "reserved operand" - touching
it causes an error - fraction bits are ignored. There are no minus zero,
infinity, denormalized or NaN values.
For all formats, the fraction is normalized and the radix point assumed to be
to the left of the MSB, hence 0.5 <= f < 1.0. The MSB, always being 1, is
not stored. The binary exponent is stored with a bias varying with type in
bits 14:n of the lowest-addressed word.
Type Exponent bits Exponent bias Fraction bits (including hidden)
==========================================================================
F 8 128 24
D 8 128 56
G 11 1024 53
H 15 16384 113
The layout for D is identical to that for F except for 32 additional
fraction bits.
Example: +1.5 in F float is hex 000040C0 (fraction of .11[base 2], biased
exponent of 129)
--
Steve Lionel mailto:Steve....@digital.com
Fortran Development http://www.digital.com/info/slionel.html
Digital Equipment Corporation
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698 "Free advice is worth every cent"
For information on DIGITAL Fortran, see http://www.digital.com/fortran
Hoff Hoffman
In article <34575f82....@serve.installshield.com>, chieh...@geocities.com (Chieh Cheng) writes:
:I am trying to decode and decipher Intergraph Microstation's Design
:file format. It uses the VAX D-Float format. Although it is also 64
:bit long, it is somewhat different from the IEEE double float format.
Well, the VAX architecture predated the IEEE floating point
standards by a few years. :-)
:The format is as follows:
:
:bit 15: sign
:bit 14 - 7: Exponent
:bit 6 - 0: Exponent
:
:bit 16 to 63 is the fraction. I assume it is one fraction, however,
:the diagram in the book divided it into three equal parts. Like the
:exponent shown above.
Your book appears somewhat confused, as D_Float bits 6 through 0
are part of the fraction, not the exponent.
Here are the VAX F_Floating, D_Floating, G_Floating, and H_Floating
floating-point formats:
31 16 15 14 7 6 0
+-----------+--+-----+----------+ fraction normalized;
F | frac-1 |S | exp | frac-2 | exponent bias 128.
+-----------+-------------------+
31 16 15 14 7 6 0
+-----------+--+-----+----------+ fraction normalized;
D | frac-3 |S | exp | frac-4 | exponent bias 128.
+-----------+-------------------+
| frac-1 | frac-2 |
+-----------+-------------------+
31 16 15 14 4 3 0
+-----------+--+-------+--------+ fraction normalized;
G | frac-3 |S | exp | frac-4 | exponent bias 1024.
+-----------+-------------------+
| frac-1 | frac-2 |
+-----------+-------------------+
31 16 15 14 0
+-----------+--+----------------+ fraction normalized;
H | frac-7 |S | exp | exponent bias 16384
+-----------+-------------------+
| frac-5 | frac-6 |
+-----------+-------------------+
| frac-3 | frac-4 |
+-----------+-------------------+
| frac-1 | frac-2 |
+-----------+-------------------+
With the least significant to the most significant bits of the
fraction being listed from frac-1 to frac-n. S is the sign bit.
:Can someone help me with this format? How can I convert this binary
:data to a double float?
A double float using what format? On all recent OpenVMS releases,
there are library routines to convert this stuff for you -- without
access to these routines, we need to know what floating point format
you want to convert this format to...
To convert it to j-random format, you need to move the exponent and
the fraction into the appropriate fields. And DIGITAL VAX and Alpha
systems, as well as systems based on the Intel IA32 architecture are
little-endian, other platforms may use a big-endian scheme.
:Any help is greatly appreciated. Thanks.
Take a look at the OpenVMS Frequently Asked Questions (FAQ), and
see if the Floating Point information included there helps any.
(In addition to what is here.)
----------------------------------------------------------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering h*ff...@xdelta.enet.dec.c*m
headers and addresses munged to avoid automated spammers: junk-e-mail
Steve Atkins
Chieh Cheng wrote:
>
> I am trying to decode and decipher Intergraph Microstation's Design
> file format. It uses the VAX D-Float format. Although it is also 64
> bit long, it is somewhat different from the IEEE double float format.
>
> bit 15: sign
> bit 14 - 7: Exponent
> bit 6 - 0: Exponent
>
> bit 16 to 63 is the fraction. I assume it is one fraction, however,
> the diagram in the book divided it into three equal parts. Like the
> exponent shown above.
>
> data to a double float?
Ugly, ugly, ugly untested code. This should all be done
with structures. This is a really good example as to how
not to write bit twiddling code.
--------------
uint16 *A; // pointer to float_d
uint64 frac; // fraction
uint64 s; // sign
uint64 exp; // exponent
uint64 tfloat; // IEEE double format number
double result;
s = (*A) >> 15;
exp = ((*A) >> 7) & 0xff;
frac = ((*A++) & 0x7f) << 16;
frac = (frac | (*A++)) << 16;
frac = (frac | (*A++)) << 16;
frac |= (*A++);
tfloat = s << 63;
// exp is excess128 for d_floats and excess1023 for t_floats
tfloat |= (exp + 1023 - 128) << 48;
// You lose three bits of precision
tfloat |= frac >> 3;
result = *(double*)(&tfloat);
--------------
Use at your own risk.
--
-- Steve Atkins -- st...@blighty.com
-- 'Play that funky music....'
John Laird
> file format. It uses the VAX D-Float format. Although it is also 64
> bit long, it is somewhat different from the IEEE double float format.
> The format is as follows:
>
> bit 15: sign
> bit 14 - 7: Exponent
> bit 6 - 0: Exponent
>
> bit 16 to 63 is the fraction. I assume it is one fraction, however,
> the diagram in the book divided it into three equal parts. Like the
> exponent shown above.
>
Bit 15 : sign
Bits 14-7 : exponent
Bits 6-0 : most significant bits of fraction
Bits 31-16: less significant bits of fraction
Bits 47-32: lesser significant bits of fraction
Bits 63-48: least significant bits of fraction
The least significant fraction bit is bit 48, and the most significant bit is
bit 6. The layout is apparently illogical in that layed out in ascending
memory order, the fraction bits are not contiguous. I think it goes back
to PDP-11 days when the two 16-bit words would have been loaded into the FPU
separately. (If you swap the 16-bit words around, it all looks much better).
You don't say whether you are running on a big-endian or little-endian machine.
It is vital that you know this in order to understand how to translate from
this (VAX) binary D_floating format to your binary IEEE format.
Assuming you are on a big-endian machine, take each 8 bytes and rearrange
them into a byte array in the following order: 2 1 4 3 6 5 8 7. The bits
will now look like this:
6
3 0
SEEEEEEEEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
^^ ^
|| - fraction bits, most significant at bit 54
| --------- exponent bits, most significant at bit 62
---------- sign bit
Compare this with your IEEE format, and you should be able to work out how
to shift bits about. (If you are using a little-endian machine, most likely
Intel, order the bytes 7 8 5 6 3 4 1 2)
There are two other very important points:
a) The fraction is _normalised_, which is to say it has been represented
as a fraction between 0.5 (inclusive) and 1.0 (exclusive), and the most
significant fraction bit (now always 1) is _not stored_. In other words,
there is a hidden bit between bits 6 and 7 in the D_float format which is
_always_ 1, and which is to be considered as part of the fraction. I don't
know off-hand whether IEEE uses normalised fractions with a hidden bit or
not.
b) The exponent is in excess 128 format, meaning that an actual value of
N is stored as N+128. Thus the exponent is always apparently positive
in the range 0 to 255, and 128 should be subtracted to give the true value
in the range -128 to 127. A stored exponent of 0 means one of two things -
if the sign bit is 0, the whole number is zero regardless of the fraction
bits, while if the sign bit is 1, the whole number is a reserved operand or
NaN in some dialects.
--
John Laird (jo...@yrl.co.uk) "I have discovered a truly elegant sig,
Yezerski Roper Ltd sadly there is no room here to show it."
http://www.yrl.co.uk
Pedasmith
In article <3458B4...@blighty.com>, Steve Atkins <st...@blighty.com>
writes:
>Ugly, ugly, ugly untested code. This should all be done
>with structures. This is a really good example as to how
>not to write bit twiddling code.
>
>-
As a developer who both [a] has written vax<-->ieee converters and [b] had
to fix other developers "improvements" to my code and [c] happened to be the
only person to *test* their float conversions:
Thorough testing is important!
[1] Make sure you try different bit patterns in each byte
[2] The code
if (x != ieee2vax (vax2ieee (x))
won't actually test the conversion -- it will only ensure that you've got
symetrical errors. That is, ieee2vax might put the bytes in the wrong
order,
only to have vax2ieee swap them back.
Peter Smith
And above all, ".5" is a _very_ bad test value
John Wilson
In article <EIw6u...@cwi.nl>, Dik T. Winter <d...@cwi.nl> wrote:
>I may note that D-Float is pretty similar in concept to IEEE fp. Converting
>a valid D-Float representation to IEEE double precision is in general
>straightforward (but beware of overflow), as is the reverse. One point
>though, although exponent bias is the same for both, there is a offset
>by one between exponents, because D-Float is normalized at 0.5 <= f < 1.0
>while IEEE is normalized at 1.0 <= f < 2.0.
Actually the bias is different (128. in D_FLOAT vs. 127. in IEEE), so the
exponent offset between the two formats is 2.
John Wilson
D Bit
Dik T. Winter
In article <63aalh$7...@usenet.pa.dec.com> lio...@mail.dec.com (Steve Lionel) writes:
> For all formats, the fraction is normalized and the radix point assumed to be
> to the left of the MSB, hence 0.5 <= f < 1.0. The MSB, always being 1, is
> not stored. The binary exponent is stored with a bias varying with type in
> bits 14:n of the lowest-addressed word.
I may note that D-Float is pretty similar in concept to IEEE fp. Converting
a valid D-Float representation to IEEE double precision is in general
straightforward (but beware of overflow), as is the reverse. One point
though, although exponent bias is the same for both, there is a offset
by one between exponents, because D-Float is normalized at 0.5 <= f < 1.0
while IEEE is normalized at 1.0 <= f < 2.0.
I wish that the designers in their description of floating point
representation had normalized on the range in which a fraction (mantissa)
was normalized.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Chieh Cheng
>>Can someone help me with this format? How can I convert this binary
>>data to a double float?
>
>the IEEE and VAX floating formats as an extension to the standard
>library.
Well, it's not on any particular machine. I am working on this project
using Java. So I've got to read in the bits and work out the details
myself.
Dik T. Winter
In article <3459f...@news.wizvax.net> wil...@dbit.com (John Wilson) writes:
> In article <EIw6u...@cwi.nl>, Dik T. Winter <d...@cwi.nl> wrote:
> >though, although exponent bias is the same for both, there is a offset
> >by one between exponents, because D-Float is normalized at 0.5 <= f < 1.0
> >while IEEE is normalized at 1.0 <= f < 2.0.
>
> exponent offset between the two formats is 2.
You are right of course.
Chieh Cheng
On 30 Oct 1997 15:55:29 GMT, lio...@mail.dec.com (Steve Lionel) wrote:
> Type Exponent bits Exponent bias Fraction bits (including hidden)
> ==========================================================================
> F 8 128 24
> D 8 128 56
> G 11 1024 53
> H 15 16384 113
>
>exponent of 129)
Is that conversion correct? I can't seem to figure out the conversion.
I thought the bias is 128, how come it is 129 in the example.
I tried the following conversions, but none of them give the correct
answer. What am I doing wrong?
000040C0 = 0000 0000 0000 0000 0100 0000 1100 0000
S = 0
F = 100 0000 = 64
E = 100 0000 1 = 129
x = (-1)^S * 1.F * 2^(E - 128):
x = (-1)^0 * 1.64 * 2^(129 -128)
x = 1 * 1.64 * 2^1
x = 1.64 * 2
x = 3.28
x = (-1)^S * 1.F * 2^(E - 128):
x = (-1)^0 * 0.64 * 2^(129 -128)
x = 1 * 0.64 * 2^1
x = 0.64 * 2
x = 1.28
x = (-1)^S * 1.F * 2^(E - 129)
x = (-1)^0 * 1.64 * 2^(129 -129)
x = 1 * 1.64 * 1
x = 1.64
x = (-1)^S * 0.F * 2^(E - 129)
x = (-1)^0 * 0.64 * 2^(129 -129)
x = 1 * 0.64 * 1
x = 0.64
Steve Lionel
In article <345e03ce....@serve.installshield.com>,
chieh...@geocities.com (Chieh Cheng) writes:
|>On 30 Oct 1997 15:55:29 GMT, lio...@mail.dec.com (Steve Lionel) wrote:
|>> Type Exponent bits Exponent bias Fraction bits (including hidden)
|>> ==========================================================================
|>> F 8 128 24
|>> D 8 128 56
|>> G 11 1024 53
|>> H 15 16384 113
|>>
|>>Example: +1.5 in F float is hex 000040C0 (fraction of .11[base 2], biased
|>>exponent of 129)
|>
|>Is that conversion correct? I can't seem to figure out the conversion.
|>I thought the bias is 128, how come it is 129 in the example.
|>
|>I tried the following conversions, but none of them give the correct
|>answer. What am I doing wrong?
In VAX floating, the fraction is 0.F, not 1.F as it is in IEEE float.
Jerome Fine
I wish to purchase an Iomega Zip Drive - SCSI Internal
I get the impression that the original version is not being
made any longer. I have an (old) CQD 220M which
accepts SCSI-2.
Jerome Fine
RT-11/TSX-PLUS User/Addict
John Foust
>I am trying to decode and decipher Intergraph Microstation's Design
>file format. It uses the VAX D-Float format.
Maybe see ftp://ftp.dbit.com/pub/pdp11/info/fpp.txt
- John
Jerome Fine
>John Wilson wrote:
>>I wish to purchase an Iomega Zip Drive - SCSI Internal
>>I get the impression that the original version is not being
>>made any longer. I have an (old) CQD 220M which
>>accepts SCSI-2.
>faster, so that explains the price cuts in the original Zips. I bought
>a "SCSI Insider" just a couple of months ago, I paid like $130 at a show
>but I've seen most versions available refurbed for $89.95 in all the
>catalogs, I *think* it included the Insider. Anyway I've been using an
>external SCSI Zip drive with my CDU-720/M and it works great, and I
>uploaded a version of PUTR to ftp.dbit.com that has the preliminary
>SCSI support (no handling of RT-11 MSCP partitions though), using a
>disk initialized as an RK07 works great at both ends so you can move
>stuff between DOS and RT way faster than Kermit.
Jerome Fine replies:
Thanks very much for the information. Are the newer faster models available
now?
Also, where do I find those catalogs so I can find the older refurbished
"SCSI
Insider" versions? Did they have an Iomega model number? The fellow who
asked me to look for him needs the drive immediately. So if the original
Zips
are not available, I will have to go with something that is. I have also
hear
of a Fujitzu M2513A as also doing the job - more expensive because the media
can be over 600 MBytes.
Jerome Fine
RT-11/TSX-PLUS User/Addict
Philippe Pouliquen
Steve Lionel wrote:
> |>On 30 Oct 1997 15:55:29 GMT, lio...@mail.dec.com (Steve Lionel) wrote:
> |>> Type Exponent bits Exponent bias Fraction bits (including hidden)
> |>> ==========================================================================
> |>> F 8 128 24
> |>> D 8 128 56
> |>> G 11 1024 53
> |>> H 15 16384 113
precision)
T 11 1023 53 (IEEE double
precision)
I've added the IEEE floating point info from the alpha architecture
reference
manual for comparison (the alpha supports both IEEE and VAX formats, but
will
drop the last three mantissa bits when operating on D_floating).
> In VAX floating, the fraction is 0.F, not 1.F as it is in IEEE float.
I believe you meant "...the fraction is 0.1F not 1.F...". Both the VAX
formats
and the IEEE format do not include the redundant most significant
fraction bit
(this is what is meant by "hidden 1").
> --
> Steve Lionel mailto:Steve....@digital.com
> Fortran Development http://www.digital.com/info/slionel.html
> Digital Equipment Corporation
> 110 Spit Brook Road, ZKO2-3/N30
> Nashua, NH 03062-2698 "Free advice is worth every cent"
>
> For information on DIGITAL Fortran, see http://www.digital.com/fortran
Here is the generic bit pattern for the VAX and IEEE floats:
Sign Exponent Mantissa IEEE value VAX value
0 0111...101 000...000 2^-2=0.25 2^-3=0.125
0 0111...110 000...000 2^-1=0.5 2^-2=0.25
0 0111...111 000...000 2^0=1 2^-1=0.5
0 1000...000 000...000 2^1=2 2^0=1
0 1000...001 000...000 2^2=4 2^1=2
0 1000...010 000...000 2^3=8 2^2=4
1 0111...111 000...000 -(2^0)=-1 -(2^-1)=-0.5
1 1000...000 000...000 -(2^1)=-2 -(2^0)=-1
You will note that in every case, F_floating and S_floating differ by a
factor of 2, and G_floating and T_floating also differ by a factor of 2.
A D_floating is just a F_floating with an extra 32 bits of mantissa.
Here are some more examples with non-zero mantissa:
0 0111...111 100...000 (1.5)*(2^0)=1.5 (1.5)*(2^-1)=0.75
0 1000...000 100...000 (1.5)*(2^1)=3 (1.5)*(2^0)=1.5
So you have some D_floating data, and you want to process it with a
modern
IEEE compliant machine? (and you don't want to buy an alpha running
VMS?)
Here's what you would want to do with the bits:
D_floating bits: F_floating bits: G_floating bits: H_floating
bits:
sign: D63 F31=D63 G63=D63 H127=D63
e D62 F30=D62 G62=D62 H126=D62
x D61 F29=D61 G61=D61 H125=D61
p G60=D61 H124=D61
o G59=D61 H123=D61
n G58=D61 H122=D61
e H121=D61
n H120=D61
t H119=D61
H118=D61
D60 F28=D60 G57=D60 H117=D60
D59 F27=D59 G56=D59 H116=D59
D58 F26=D58 G55=D58 H115=D58
D57 F25=D57 G54=D57 H114=D57
D56 F24=D56 G53=D56 H113=D56
D55 F23=D55 G52=D55 H112=D55
m D54 F22=D54 G51=D54 H111=D54
a D53 F21=D53 G50=D53 H110=D53
n D52 F20=D52 G49=D52 H109=D52
t . . . . . . .
i . . . . . . .
s . . . . . . .
s D34 F2 =D34 G31=D34 H91 =D34
a D33 F1 =D33 G30=D33 H90 =D33
D32 F0 =D32 G29=D32 H89 =D32
D31 G28=D31 H88 =D31
D30 G27=D30 H87 =D30
D29 G26=D29 H86 =D29
. . . . .
. . . . .
. . . . .
D5 G2 =D5 H62 =D5
D4 G1 =D4 H61 =D4
D3 G0 =D3 H60 =D3
D2 H59 =D2
D1 H58 =D1
D0 H57 =D0
H56 = 0
H55 = 0
H54 = 0
. .
H2 = 0
H1 = 0
H0 = 0
Once you have the correct VAX format, convert to the same size IEEE
format
by dividing by 2.
Hope this helps and sets this issue to rest. (I also hope I didn't make
a
typo :-)
Philippe Pouliquen
Electrical and Computer Engineering
Johns Hopkins University
Baltimore, USA
John Laird
In article <3461DA...@alpha.ece.jhu.edu>, Philippe Pouliquen <phil...@alpha.ece.jhu.edu> writes:
>
>(much snipped)
>
> Here is the generic bit pattern for the VAX and IEEE floats:
>
> Sign Exponent Mantissa IEEE value VAX value
>
>
I will bet you the Alphastation on my desk that you are wrong (and it's
not even mine to gamble). This bit pattern interpreted as either F_floating
or D_floating on a VAX (or an Alpha) is _0.5_. The zero mantissa represents
a binary fraction of 0.1 or 1/2. The exponent of 128, after removal of
the 128 excess, is 0. So we have 1/2 times 2 raised to the power 0, ie. 0.5 !
I believe IEEE normalises to 1.F as opposed to 0.F (as Steve Lionel correctly
stated), and the excess is also different by 1, resulting in a factor of 4
when comparing the same bit pattern against F_FLOAT or D_FLOAT.