Sunday, October 13, 2024
A benchmark of three different floating point packages for the 6809
I recently came across another floating point package for the 6809
(written by Lennart Benschop)
and I wanted to see how it stacked up against IEEE-754 and BASIC floating point math.
To do this,
I wanted to add support to my 6809 assembler,
but it required some work.
There was no support to switch floating point formats—if you picked the rsdos output format,
you got the Microsoft floating point,
and for the other output formats,
you got IEEE-754 support.
The other issue, the format used by the new floating point package I found is ever-so-slightly different from the Microsoft format. It's just a single bit difference—Microsoft uses an exponential bias of 129, whereas this package uses a bias of 128 (and why do floating point packages use an exponential bias? I'm not entirely sure why). But other than this one small difference, they are basially the same.
It turned out not to be that hard to support all three floating point formats.
The output formats still select a default format like before,
but now,
you can use the .OPT directive to select the floating point formats:
.opt * real ieee .float 3.14159265358979323846 .opt * real msfp .float 3.14159265358979323846 .opt * real lbfp .float 3.14159265358979323846
And you get three different formats as output:
| FILE p.asm
1 | .opt * real ieee
0000: 40490FDB 2 | .float 3.14159265358979323846
3 | .opt * real msfp
0004: 82490FDAA2 4 | .float 3.14159265358979323846
5 | .opt * real lbfp
0009: 81490FDAA2 6 | .float 3.14159265358979323846
I added some code to my floating point benchmark program, which now uses all three formats to calculate -2π3/3! and times each one. The new code:
.opt * real lbfp
.tron timing
lb_fp ldu #lb_fp.fpstack
ldx #.tau
jsr fplod ; t0 = .tau
ldx #.tau
jsr fplod ; t1 = .tau
jsr fpmul ; t2 = .t0 * t1
ldx #.tau
jsr fplod ; t3 = .tau
jsr fpmul ; t4 = .t2 * t3
ldx #.fact3
jsr fplod
jsr fpdiv
jsr fpneg
ldx #.answer
jsr fpsto
.troff
rts
.tau .float 6.283185307
.fact3 .float 3!
.answer .float 0
.float -(6.283185307 ** 3 / 3!)
.fpstack rmb 4 * 10
The results are interesting (the IEEE-754 results are from the same package which support both single and double formats):
| format | cycles | instructions |
|---|---|---|
| Microsoft | 8752 | 2124 |
| Lennart | 7465 | 1326 |
| IEEE-754 single | 14204 | 2932 |
| IEEE-754 double | 31613 | 6865 |
The new code is the fastest so far. I think the reason it's faster than Microsoft's is (I think) because Microsoft uses a single codebase for all their various BASIC interpreters, so it's not really “written in 6809 assembler” as much as it is “written in 8080 assembler and semi-automatically converted to 6809 assembly,” which explains why Microsoft BASIC was so ubiquitous for 80s machines.
It's also smaller than the IEEE-754 package, a bit over 2K vs. the 8K for the IEEE-754 package. It's hard to tell how much bigger it is than Microsoft's, because Microsoft's is buried inside a BASIC interpreter, but it wouldn't surprise me it's smaller given the number of instructions executed.
