Calculator Community > ASM
[z80] Floating Point Routines
Xeda112358:
EDIT: I'm still not good with GitHub, so I'm going to try to get this to work, but I make no promises. z80float
Hopefully, this can evolve into a collection of floating point routines, with this first post edited to keep them in one easy place. I am working on some floating point routines for use in things like Grammer and I hope it will some day make its way into a community made OS, so I hope that people find these useful enough to use (and feel free to do so). I am still working on these routines, trying to optimise them, too.
edit: I removed the code because it was too much. Instead, I have made a public folder available here to keep these organised.
Tari, from Cemetech posted a link to some routines received from Scott Dial for BCD format (the same as the TI-OS). They can be found here.
Examples of use might be:
--- Code: --- ld hl,FP1
ld de,FP2
call FloatDiv
<<code>>
FP1:
.db 0,2, $c9,$0f,$da,$a2,$21,$68,$c2,$34 ;pi, not rounded up
FP2:
.db 0,2, $ad,$f8,$54,$58,$a2,$bb,$4a,$9A ;e, not rounded up
--- End code ---
The 80-bit division and multiplication routines do not handle overflow yet. On the to-do list:
[+] 80-bit Addition
[+] 80-bit Subtraction
[+] 80-bit Exponents
[+] 80-bit Logarithms
[+] 80-bit sin/cos/tan
[+] 80-bit arcsin/arccos/arctan
[+] 80-bit Complex Addition, Subtraction, Multiplication, Division, Exponents, Logs, Trig
[+] BCD Division
[+] BCD Exponents
[+] BCD Logarithms
[+] BCD sin/cos/tan
[+] BCD arcsin/arccos/arctan
[+] BCD Complex Addition, Subtraction, Multiplication, Division, Exponents, Logs, Trig
From these, routines such as those dealing with probability, statistics, and other similar routines should be easier to make. The advantage to using BCD is for displaying numbers or reading them during parsing. With the 80-bit format, most non-integers don't have an easy representation (like .1) and in order to parse a base-10 string of digits, you would have to do some very time consuming processes (probably a hundred times slower than with BCD). However, for compiled languages and where text output isn't necessary, 80-bit floats offer a much higher range of numbers, greater accuracy, and all for a decent speed.
Xeda112358:
I added the 80-bit Floating Point Addition routine which was friendlier than I expected. Also, for current timings, Division is a little under 60 000 t-states, multiplication is a little over 30 000 t-states, and addition is just under 1400 t-states. I need to make all of these faster x.x
EDIT: Oh, also, The floating point addition code includes a routine for setting a number to infinity, keeping its sign, among other things. It also has rounding implemented.
EDIT: In my test app, here are the sizes so far:
FloatAdd : 244 bytes (this includes the code for handling infinity and a few other subroutines that will be shared by others)
FloatDiv : 244 bytes
FloatMul: 205 (this includes a subroutine routine for 64-bit integer multiplication)
Xeda112358:
I modified the addition routine (I rewrote it from scratch) and it now handles adding negative numbers and whatnot. This means the subtraction routine only needed to toggle the sign of the second input, so multiplication, division, addition, and subtraction are working :)
I also put the code here because the first post was getting too cluttered for my liking. If you check it out, you will notice the yet-to-be-tested code for the CORDIC algorithm that should compute sine and cosine at the same time.
Xeda112358:
I added a few 24-bit floating point routines including a log2 routine. The advantage to the 24-bit floats is that it can all be done in the registers, giving them even better speed. The obvious downside is a much more limited range for accuracy (about 4 to 5 decimal digits), but it does provide a fast alternative to integer math. It could be used in languages like Axe or Grammer.
I haven't fully tested the log2 routine, but I did test a few key values that were more likely to have issues with accuracy. I am pleased to say, that the worst I got was about .0000763 away from the actual value (but I won't be surprised if there are values that yield as much as an error of 5 times that). The main issue is that it doesn't handle negative inputs.
By the way, for timing, the log2 routine is around 1200 to 3500 t-states, so it can do 1700 to 5000 computations per second at 6MHz. Graphing a log() equation should be pretty fast ;D
Eiyeron:
That's neat. i won't certainly use them, but keep up the good work!
Navigation
[0] Message Index
[#] Next page
Go to full version