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
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
and ... here is the code.
Originally posted by KetilO
If there is any interest I can also show how to do basic maths.
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
I would like that very much.
Have you ever heard of excess 64 BCD encoding?
TIA.
Have you ever heard of excess 64 BCD encoding?
TIA.
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
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
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
and mask off some bits.
This was designed for 8 bit registers, therefore today ....?
Note -- not limited to 7 bytes - can be more or less.
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
and mask off some bits.
This was designed for 8 bit registers, therefore today ....?
Note -- not limited to 7 bytes - can be more or less.
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
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
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.
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.
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!
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!
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
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
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
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