Hi all

Does this ancient data format still have some use in these FPU days? I will say yes if fast convertion to ascii or high precicion is needed. Here is a demo of the convertion methods. If there is any interest I can also show how to do basic maths.

KetilO
Posted on 2002-07-15 09:12:38 by KetilO
and ... here is the code.
Posted on 2002-07-15 09:16:19 by KetilO
Originally posted by KetilO
If there is any interest I can also show how to do basic maths.

KetilO

If you have the time or the inclination then I'd for one would like to see some of this :)

Sliver
Posted on 2002-07-15 14:07:52 by Sliver
Ditto
Posted on 2002-07-16 08:18:36 by gscundiff
I would like that very much.
Have you ever heard of excess 64 BCD encoding?
TIA.
Posted on 2002-07-16 15:22:12 by Roy Cline
Hi all

There seem to be some interest in this number format, so here is a demo with basic math operations.

To Roy Cline: Excess 64 BCD??? Tell me more!

KetilO
Posted on 2002-07-18 07:45:17 by KetilO
31 41 59 26 53 59 41 (this is hex) = 3.14159265359 (pi)
41 hex = 65 - 64 = 1 therefore number is 3.xxxxxxxx
31 41 59 26 53 59 C1 (this is hex) = -3.14159265359
C1 hex = 193 - 128 = 65 - 64 = 1 therefore number is -3.xxxxxxx
31 41 59 26 53 59 40 '' " " = 0.314159265359
31 41 59 26 53 59 C0 " " " = -0.314159265359
The above is a 7 byte signed 12 digit precision excess 64 bcd numbers.
It helps to look at the encoded byte as a binary number you test
This was designed for 8 bit registers, therefore today ....?
Note -- not limited to 7 bytes - can be more or less.
Posted on 2002-07-18 22:39:24 by Roy Cline
Hi Roy Cline

Exactly the same format as in the demo, except I have the exponent in the high byte. Putting the exponent in the high byte helps if you need to sort the numbers (just flip bit 7, the sign). I also have a math pack (in 16 bit code) using binary floating point. If there is any inerest in the subject I can rewrite it to 32 bit code.

KetilO
Posted on 2002-07-19 01:53:19 by KetilO
Yes I agree about the high byte and sorting -- if sorting was necessary I
did exactly that. And, yes I "need" a math package for this format in 32 or 64 bit.
We use to code a precision flag into our routines. The flag was the number
of bytes of precision - actually - the flag could only be 8, 10, 12, or 14.
Yes, I would like the package.
TIA.
Posted on 2002-07-19 09:38:40 by Roy Cline
Hi KeltiO

The bcd values represents the real hexadecimal numbers ?

I mean when i calculate for example the number 1e16, it shows on the app

511000000000000000000000000000000000000000

but it is indeed

2386F26FC10000

How they are represented ? I didn't figure out the bcd numbers.

I'm trying to get the hexadecimal values for some equates like:

LDBL_EPSILON 1.08420217248550443412e-019
FLT_MIN 1.175494351e-38F
LDBL_MAX 1.189731495357231765e+4932
FLT_EPSILON 1.192092896e-07F
DBL_MAX 1.7976931348623158e+308
DBL_EPSILON 2.2204460492503131e-016
DBL_MIN 2.2250738585072014e-308
LDBL_MIN 3.3621031431120935063e-4932
FLT_MAX 3.402823466e+38F

Which values they really have in hexadecimal ?

Best Regards,

Beyond2000!
Posted on 2002-08-20 01:25:39 by Beyond2000!
Hi Beyond2000!

BCD (binary coded decimal) floating point is very different from binary floating point. In the demo the most signifficant byte holds the sign (most signifficant bit) and the binary representation of the exponent where 1e0=41h The exponent is really a pointer into a 128+Precision digits BCD. Also in BCD each number (0-9) is representated in a nybble (4 bits).

In short:

1e16=5110000......
2e1=4220000.....
3e0=4130000.....

KetilO
Posted on 2002-08-20 02:43:57 by KetilO
Hi all

Here is an unfinished demo of binary floating point the hard way. I did not finish it because I could not find an easy solution to the 999999.................. problem common to binary flating point. The demo confirms to the 10 byte (80 bit) floating point used by the FPU. You can set the presision by changing a constant (in 4 bytes steps)

KetilO
Posted on 2002-08-20 03:02:45 by KetilO