• Please review our updated Terms and Rules here

My Floating Point adventure

"floatAsBits" is a Java function, I presume? Yes, I am using Pascal but for the simple reason that it is easier to write out ideas using Pascal than using ML. Once the idea works fine, the whole must be translated into ML in the end and that means I cannot use built-in functions.
But thank you anyway for wanting to help me!
Actually floatAsBits() and its corollary bitsAsFloat() are my own internal routine to treat the floating point representation as raw data, not floating point values. You need to do something like from a high level language to get to the low level bit representation to extract things like mantissa, exponent, and signs. As for being in Java, shouldn't be hard to convert to another language. Most of my Java looks suspiciously like C.
 
Sorry for the late reaction but had work to do. The problem is that I'm not familiar with C as well. During breaks I studied the source code of C64's BASIC again and it gave me an idea. Now I have to work that out.
 
An update:

I'm able to turn ASCII into FP and back again using Pascal. What I do is converting the integer part and the fractal part of a number into ten words each. The result is converted into a FP with an 80-bits mantissa. To get the ASCII value again, the FP is converted into this 20-word array again. The whole is multiplied with 1 e 16 and then I calculate each digit by subtracting 1e40, 1e39, 1e38 etc. To speed up things I use tables, each record has a precision of nine words. OK, maybe a massive overkill but, as said before, it is easier to scale down then to scale up. This method has at least one advantage: it is fast.

Yet I still do have a problem. The tables only enable me to handle values up to roughly 10^20 / 10^-20. This is about 2^44 / 2^-44. This doesn't come even near handling max exponents of 127 / -127 that I had in mind. So at the moment I run into trouble when handling a value like 1.2345 e 38. OK, just when writing this, an idea popped up that maybe could handle that number but at this moment I have no idea to handle 1.2345 e -38. Yes, I could expand the tables but then I will have routines that are more tables than program.
I'm looking forward to ideas. TIA!
 
I have (more or less) completed a Pascal program that converts a string to Floating Point (FP) and vice versa. I only used basic functions like multiplication, addition, subtraction, SHR and SHL. No division. It is word orientated because my first target is the 8088. I already have converted the ASCII->FP part into assembly for this CPU.
In the future I also want to create the assembly for the 6502. This CPU is byte orientated and has no multiplication opcode so there is a challenge yet.

At this moment I support an 8-bit exponent and an 80-bit mantissa. Maybe overkill but is is easier to downgrade than to expand things.

"More or less" because I'm still tinkering. To speed up things I use tables. Explanation: I use an array of 7 words to calculate the binary value of the first digit of a fraction. So 0.3 is calculated by multiplying these 7 words with 3 and then shifting the whole. How does it work? 0.1 is about 6553 / 65536. Multiply 1 with 6553 and then divide by 65536 = SHR * 8. In this case the deviation is 6/65536, thus about 1/10000. In my case I use 7 words!
I have arrays for 0.1, 0.01, 0.001 up to 1 e -20. But what about values less than -20, should I expand the tables? Or something else? The Commodore 64 solved this by keeping on dividing by 10. But the C64 has a mantissa of only 2 words, so less to calculate. What I have to find out is if I can speed up things if I can still use my table, for example 1 e -30 which is 1 e-15 * 1 e -15. And even then I'm thinking of 1 e-10 * 1 e -10 * 1 e -10 for the simple reason that is that the deviation for 1 e -10 is much less then for 1 e -15.

We just have to try.....
 
At the moment I'm not hindered at all to expand it to 16 bits. I'll do you a favor and will do just that. OK? :)
 
Just an update:
I'm able to convert ASCII into FP using 96 bits: 16 bits for the exponent, 80 for the mantissa. I'm not able to handle the exponent notation (like: 123.456 e 234) yet but I'm busy with it. I'm also busy with sine, cosine, tangens, e^X, (natural) logarithms, etc. . using polynomial evaluation, in particular Horner's method. The idea is to create table for the various values of a0, a1, a2, etc so only one calculation is needed. These tables will take space so for small machines I'm thinking about calculating these values as well (as for example the Commodore 64's BASIC does) but that is something for later.
 
Back
Top