# Thread: Floating point info code for 8088 wanted

1. Floating point is a wonderful area to study if you're interested in numerical analysis, or "how to come up with garbage using generally accepted mathematics".

Floating-point should probably be referred to as "scientific notation", as the older definition simply meant a fixed-length field where the decimal point could be moved; e.g. 1.234 12.34 123.4. But things are what they are.

Some older computer systems allowed for selection of a "noise digit" that was shifted in when a value was normalized. For the 1620, this could be any decimal value; on the CDC mainframes it varied from one-half (i.e. every other bit set) on addition and subtraction and every third bit set for division instead of the usual zero. You could get a fair idea of how good your calculations were by selecting different values of this fill digit. I don't recall if IEEE 754 makes provision for this or not--I don't think so.

2. Senior Member
Join Date
Jan 2005
Location
Principality of Xeon W-2140B the Great State of Central New Jerky
Posts
1,741
So no one knows of a text or group of routines for the 80x86 to implement fp math? There are a few older assembler books that concentrate on subroutines for whatever. I'm suspecting they probably don't deal much with that sort of thng though. At least if such documentation existed for say C (preferably, as you're not likely to get any closer to assembler in the absence of actual assembler routines), it could be converted to assembler.

These days there are some good of mathematical software packages that deal with evaluating symbolic equations. Mathcad was around in the 80s. I'd have to suspect the treatment of fp values is very fine tuned and optimized at this point. How is it done in Python (interpreted). Or FARTRAN. Then there's calculayors themselves. Loads of resources I'd have to imagine, but you're likely going to habe to dig deep. Look up some of the authors who have written assembler books and maybe they'll offer suggestions. If not actual code.

LOL edit. I'm staring around the room and spot the C text I'm reading. I call to mind how in one early chapter it warns about comparing floating point variables. If a modern C compiler can't handle them, you sure got your work cut out for you. Fp is quite the mess.
Last edited by tipc; November 12th, 2019 at 06:27 PM.

3. Senior Member
Join Date
Oct 2017
Location
Kentucky USA
Posts
104
This was my experience, if it would be of any help:

Thirty+ years ago, I wrote a TSR program for a company that contained a four-function calculator as a "bonus" function (not the main purpose of the program) that would pop up when a certain key sequence was pressed (like Sidekick, which was popular). Then, like now, it was WAY over my skill set to write a floating point package in assembler. I could not find one, but I DID find a Motorola 6800 floating point package in a Motorola support document. Although I "sort of" understood its principles, I didn't take any chances and simply brute-forced it into working by mapping the Moto instructions and registers to the x86 with a few obvious touchups and macros. It wasn't the most efficient or fastest code, but it worked and was TSRRable, and I never optimized it. As I recall, it was "24-bit" accuracy, which wasn't great, but it was OK for most purposes. It had support for trig, but I didn't use it (and left the code because it really didn't take up that much space). Looking back, it's sad to see how much I've forgotten and how my skills morphed into something almost completely different.

I didn't feel bad about not writing it from dead scratch because Bill Gates and Paul Allen couldn't do it, either . The guy they got to do Altair Basic was pretty darned good, I've been surprised at how bad some 1970's floating point BASIC's are in comparison. The 6800 SWTPC BASIC (I've never found the source) used BCD math, it was slow, but great for working with money.

PS:

I don't believe that I found it!

http://test.dankohn.info/~myhome/pro...%20Group/UG050

My memory can't be THAT bad..., but I think I grafted on the trig functions later (see file 89), but still never used them.
Last edited by Slob; November 12th, 2019 at 07:02 PM. Reason: Addl Info

4. Senior Member
Join Date
May 2009
Location
Connecticut
Posts
4,633
Blog Entries
1
Group of routines: I know I had a book on it but I can't find it.

PC Tech Journal did a three part article on floating point math with code written in 8086 assembly. That would be OCT thru DEC 1984 issues. Only the first part is available online showing example code for handling floating point addition. See FLOATADD at http://annex.retroarchive.org/cdrom/...ASM/index.html Part two was multiply and divide and Part three did conversion of the non-standard format to ASCII decimal format. If I followed the code correctly, it uses a 24 bit mantissa and 8 bit exponent which seems of little real world use but using registers like this has to be a lot faster than larger structures stored in memory.

5. If you're going to do this just like Commodore BASIC, you will evaluate all numbers as floating point, so you need your floating point routines before you can do any maths. But there are other commands to implement that don't require any maths. I would get those working first.

As far as transcendental functions, I've always used look-up tables. I thought Commodore BASIC did this too. But it's been a very long time since I perused the code.

6. Senior Member
Join Date
Jan 2005
Location
Principality of Xeon W-2140B the Great State of Central New Jerky
Posts
1,741
As I've said, I can kind of understand wanting to write a mondo groovy basic interpreter. Because I am weird. But being this has been done, and I would assume M\$ basic is acceptably good (ducks), why not just modify that to suit your liking.

7. Senior Member
Join Date
Jan 2005
Location
Principality of Xeon W-2140B the Great State of Central New Jerky
Posts
1,741
Don't most trig and other functions reduce to infinite series? Am I remembering that right ...

Open Watcom 8087 emulator

There's probably a function library in the same archive, somewhere.

Yes, most trig and transcendental functions can be expressed as an infinite series. The problem with many is the speed of convergence. That's why all of the texts are written for derivations that shortcut the process.

Consider, for example, the series for arctangent:

arctan(x) = x - x³/3 + x⁵/5 - x⁷/7 + ...

This series involves a lot of computation and converges fairly slowly.

There are truncated series, range reductions, etc. that can improve this considerably.

(Why did I select arctangent? It's the easiest one to check: 4*atan(1) = pi)

9. Senior Member
Join Date
Oct 2017
Location
Kentucky USA
Posts
104
Looking at the Motorola code, it uses Taylor series (precalculated). All you need is SIN, you can derive COS and TAN from that. And the code shows why all these packages work by default in radians...it's just simpler. On lookup tables, its a trade-off of speed vs space. Neither is at much of a premium anymore.

10. Senior Member
Join Date
Jan 2005
Location
Principality of Xeon W-2140B the Great State of Central New Jerky
Posts
1,741
All the simple graphical tricks I used to write in BASICA that used trig functions evaluated to rectangular corrdinates. To think gee whiz basic had all that stuff beat ...

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•