Floating Point arithmetic in 68000
Hassink Brian John
I'm doing some work with fractals, specifically the Mandelbrot set, and
I'd like to convert some of the iteration calculations to assembler to
optimize the speed a bit. Sadly, unlike the IBM 370 family, the 68000
does not provide floating point registers or instructions. If anybody has
gone through this before and has come up with their own routines to
accomplish floating point multiplication/division/etc I'd really
appreciate it if they would explain it to me. Thanks in advance.
Brian Hassink
has...@manning.cs.ualberta.ca
Tod Ihde
Check in your libs: dir... Just a thought.
Malachai.
UUCP: {crash, kksys, petrus, quest}!orbit!pnet51!malachai
ARPA: crash!orbit!pnet51!mala...@nosc.mil
INET: mala...@pnet51.cts.com
Robert Andrew Knop
>Umm... Correct me if I'm wrong, but don't most Amigas come with FP libs?
> Check in your libs: dir... Just a thought.
> Malachai.
Yes, they do. There are actually a number of them. If you want precision, or
compatability with the "standard," you can use the IEEE doulbe precision
library. However, of you are after speed, you are probably better off with
the "MFFP" (Motorola Fast Floating Point) library. The MFFP library only
supports single precision (4 byte) floats, and in addition these floats
have... 1 bit?... less precision than do IEEE single precision floats, as well
as a smaller range to play around in. However, they are _much_ faster. I
converted a program I was writing from the SAS/C math library over to the MFFP
library in C, and gained almost a factor of 2 improvement in speed (I have a
68000 with no FPU). A subsequent conversion to assembly language of course
helped as well, although I was calling the same floating pont routines.
The MFFP routines are documented in the "Libraries and Devices" RKM (I used
the 1.3 RKM). Note that the MFFP routines do not use any putative math
co-processor; so, if you want your program to run on an Amiga without an FPU
but still take advantage of an FPU if there is one, you should use the IEEE
routines.
Stephen John McGerty
>I'm doing some work with fractals, specifically the Mandelbrot set, and
>I'd like to convert some of the iteration calculations to assembler to
>optimize the speed a bit.
I believe that the Fast Floating Point routines in the standard
math library (used within C by 'float') are very efficient.
They store the floating point number in a single longword as follows:
MMMMMMMM MMMMMMMM MMMMMMMM SEEEEEEE
31 0
And no doubt the assembly has been optimised quite a bit.
The sad truth about floating point maths on a 68000 is that
it will never get close to the speed of a maths co-processor.
If you want to do fast mandelbrots, then perhaps the best method
is to try and use integer arithmetic, using the bottom few bits
as the fraction part. In other words, store every value *128,
or something like that.
I've written a short 68000 program to draw a 256x256 16 colour
mandelbrot, with a loop limit of 40, in about 21 seconds using
this method.
>Brian Hassink
>has...@manning.cs.ualberta.ca
Stephen McGerty
.........................................................................
: / T | / Stephen John McGerty (C.Sci) "Theory must never Amiga // :
: / | |/ smcg...@unix1.tcd.ie precede creation" \\// :
:.......................................................................:
Chris Green
Best of all is to avoid the floating point entirely. Except when you
get to 1000000x zooms, 32 bit fixed point numbers work pretty well.
The FFP libraries in the rom are pretty efficient. Here's some code I wrote
to square an FFP number (something you'll need in a mandelbrot generator). It
is both faster and more accurate than using the ROM multiply routine.
square_d7:
; d7=d7*d7 (d7 ffp)
; trashes: d0/d1/d2/d3/d4
move.l d7,d0
beq.s 2$
add.w d0,d0
clr.b d7
move.l d7,d1
swap d1
move.w d1,d2
mulu d7,d2
moveq #0,d4
move.w d2,d4
move.l d2,d3
clr.w d3
swap d3
add.l d4,d4
addx.l d3,d3
moveq #0,d2
mulu d7,d7
add.l d7,d4
addx.l d2,d3
mulu d1,d1
add.l d1,d3
bmi.s 1$
add.l d4,d4
addx.l d3,d3
subq #1,d0
1$: sub #$40,d0
add.l #$00000080,d3
move.b d0,d3
bmi.s 3$
move.l d3,d7
2$: rts
3$: moveq #0,d7
rts
--
*-------------------------------------------*---------------------------*
|Chris Green - Graphics Software Engineer - chr...@commodore.COM f
| Commodore-Amiga - uunet!cbmvax!chrisg n
|My opinions are my own, and do not - icantforgettheimpression o
|necessarily represent those of my employer.- youmadeyouleftaholeinthe r
| - backofmyhead d
*-------------------------------------------*---------------------------*