6502.org

Hi all. qus brought up the question here, and it occurred to me that I haven't seen a comprehensive comparison of the different single-precision floating point formats which have been coded and used for the 65xx family over the last 40+ years. Off the top of my head, there's Woz 32-bit, Microsoft 32-bit, Microsoft 40-bit and Acorn 40-bit. I'm certain that there are more. I even have my own unique 32-bit (and related 36-bit) formats that are stalled on the back-burner with my many other unfinished projects, but that's another story ...

There are forum members here with experience using more than one of these formats, and it would interest me to know what they feel about the detailed pros and cons of each. I'm talking about the storage format and the (code) size and speed of the elementary functions + - * / ... the implementations of the more advanced functions are interesting as well, but of secondary importance for this particular discussion.

Would anyone like to share?

Good idea! There are also Atari's 6 byte BCD floats. (Edit: try also here)

Michael's universal build of MS Basic describes the 4 byte floats as 6 digit and the 5 byte floats as 9 digit. That's an approximation, of course, but a user-friendly indication of the difference. Matching an 8-digit calculator would have become a good thing to do.

This post and thread might be a useful reference too.

Notably, although Acorn's 6502 Basics all use the same floating point format, they have varying performance, either due to algorithmic improvements or due to having a 'C02 with a bigger instruction set. See

• More BASIC ASCII Mandelbrots ...

There were minor advances in accuracy too, and one bug in the final fastest version, subsequently found and fixed.

• A disassembly of BBC Basic 4r32 (github, by hoglet)
  BBC Micro Compendium by Jeremy Ruston (stardot thread)

...which brings up the matter of guard digits, which I didn't think of until you said that. Without changing the storage format of floating-point numbers, rounding errors can be reduced by keeping higher precisions in the registers (probably ZP variables or ZP data stack space?), particularly for chained operations that can be carried out before a result is stored in memory.

Quite so! You can find some interesting reading by searching for 6502 "guard byte".

(Edit: in the BBC Micro Compendium's disassembly of an early Acorn Basic, "rounding byte" is used. The two floating point accumulators have an extra byte of mantissa. See for example the multiplication routine here starting at $A613.)

Oh, and this previous thread has some relevant commentary:

• OT: Binary or decimal for floating point?

There's a hybrid format called Dec64 that uses a signed binary mantissa along with a base10 exponent. There are some disadvantages to this (e.g, you cannot compare values as integers, as you can for the IEEE-754 formats), but there are some interesting advantages, too. It might be possible to adapt this to 32 bits?

Funnily enough I've had a tab open on that page for ages, but I'm not sure what led me to it. The commentary on HN is generally negative about the proposal: it's not a proposal from an expert, and it's probably not as good as it would need to be to become a standard.
https://news.ycombinator.com/item?id=16513717

Edit: from within that commentary, a page all about decimal arithmetic:
http://speleotrove.com/decimal/

Yeah, a wide divten on a 65xx can be somewhat "expensive", relatively speaking. Of the four implementations I mentioned in my original post, there seems to be little doubt that the Acorn floats have received the most care and attention to performance, but I'm the most intrigued by the Woz floats. Studying his code is a bit entertaining ... he worked some Woz magic to make it as compact as possible, and the result is wound up tighter than an eight-day clock. He is clearly burning a lot of cycles to reduce the code footprint ... nothing inherently wrong with that, but ... I am not sure if the performance hit from that strategy is significant or not, so I am unrolling his x-loops and combing out some of the spaghetti to attempt a timed comparison.

More to come, but in the meantime can any of you think up a good torture test that burns some measurable time and checks typical accuracy but uses only + - * / ? Something like pi/(1/(1/(1/(1/pi))))*pi-pi ?

Maybe cook up a loop or a nested expression based on something like the following? (Edit: P. is an abbreviation for PRINT)

While combing through Woz' brilliant little ball of twine, I was inspired to briefly revisit my own 32-bit format which uses $80000000 for its only NaN, $00000000 for its only 0.0, $40000000 for +1.0, $c0000000 for -1.0, etc. (1.0 is about halfway between zero and infinity, right?) The advantage of this format is that integer negation and signed-integer comparison (after special-casing NaN) work perfectly on the floats as well. Briefly, I was also excited that I could get reciprocals very quickly by subtracting from $80000000, but it turns out that it only seems to work for integer powers of two, which is of limited usefulness. Oh well, experimentation proceeds ...

> (1.0 is about halfway between zero and infinity, right?)
Sounds about right to me!

> combing through Woz' brilliant little ball of twine
It would be great to hear about what you've learned. It's very little code, but I don't doubt there's a lot to learn from it!

Oh, I'm still trying to steal a few moments here and there to study and fully dissect the Woz routines. As many of you may already know, his programs have an eccentric and intricate style (which some might frankly and explicitly call an unstructured mess) involving multiple subroutine entry- and exit-points, zp wraparound, subtle register and flag side-effects, extreme code re-use ... seemingly all in the interest of minimizing the code footprint, which was a legitimate incentive at that time. It's certainly an acquired taste, but one that I admire and attempt to understand, although I haven't the skilz to operate creatively at that high level. I definitely think it's a form of art, but I'm not yet prepared to share my critique.

Fair enough - hopefully one day!

I got some slightly surprising results from this test program, which does some divisions and multiplications and sums up the absolute errors: The oddity is that an older version of Acorn's BBC Basic gets a smaller result, and therefore seems to be more accurate than the newer: