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 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