Floating point for HP 2000F TSB port to MSP430FR5994

Question

The HP 2000F TSB system doesn't (could not, as it didn't yet exist) support IEEE 754 formats. HP's early design extends from the range of 2^{−(255−127)−1} to 2^{+(255−127)−1}. The (−1) shown there is because they also don't support hidden bit notation.

I currently don't see a good reason to support denormals or infinities or sNaNs or qNaNs. Slower code would result from handling them and I don't see a good benefit, right now. The old TSB didn't support them, either. So it won't break any existing TSB BASIC code to avoid supporting those extra features.

I do feel okay with supporting hidden bit notation, though. I don't see a problem with that. But I'm unsure on that point, as well.

The question is this:

What may I be I failing to see where it may be important to either (1) drop the idea of supporting hidden bit notation, or (2) add support for denormals or infinities or xNaNs?

In answering, keep in mind that I want to (a) support old HP source code fairly well (but not to the Nth extreme, necessarily), and (b) I'm hoping that extensions (where requested) to support embedded applications will have a solid FP library base to rely upon. So I don't want to build a poor foundation.

P.S. I already know that I'll need to make modifications to the Chebyshev functions they developed – I can't just copy and paste from them. So that may be a price to pay for adding hidden-bit notation. I haven't firmly decided yet whether or not to include hidden bit notation. But I'm looking for reasons, other than having to re-adapt Chebyshev/minimax transcendentals, right now. Any other reasons to consider dropping hidden-bit notation are welcome!

---

Added

Direct from HP's overview of the 2116 processor:

And SIMH emulating source code.

For those interested in seeing approximately how I'd achieve an FP DIV emulation, I'm providing two cases. Both use a calling convention more aligned with a C compiler than how I will actually write them and they hew closer to IEEE 754 than to HP 2116. They are a single-precision 'loop' MSP430 FP DIV and single-precision 'unrolled loop' MSP430 FP DIV. And they are hereby placed into the public domain.

Answer 1

I've arrived at a conclusion. If interested, this is a PDF that points up my questions and my considerations and final conclusions. But the content is replicated below, as well:

---

Floating Point

I'm fairly comfortable with most of the elements of developing a BASIC interpreter such as the HP 2000F TSB. The MSP430 doesn't have any hardware specifically dedicated for floating-point computations and so it must all be done in software.

So far as I'm aware there isn't any open-source floating point library for the MSP430. Such code appears to be notoriously absent.

I've already decided that I'd be writing that code.

Conclusion: Writing a floating point support library is the first step along the solution path ahead.

The essential details of IEEE 754-1985 standard had already become the de facto standard years before it was finally approved. Much effort and thought has gone into it. The subject of denormals (subnormals) was perhaps its most contentious facet. But I felt I needed to thoroughly explore the questions and answers that this standard entails before proceeding.

Note that when HP's 2000F TSB system was being written, no such standard existed. And their 32-bit format didn't use the concept of hidden-bit notation for the mantissa.

I spent a long time considering the ideas of qNaN, sNaN, INF, and denormals (subnormals.) I studied many reasons and motivations behind them, written out by those who were directly involved in the deliberative processes behind them. (UCB's Professor Kahan figuring more significantly in that study.) But the HP 2000F TSB system wasn't designed to handle these and doesn't support the additional language features that would likely be needed to make better use of them. So I've decided not to support any of qNaN, sNaN, INF, and denormals (subnormals.)

This left me with just two much simpler questions to answer:

1. Should I stay with a 32-bit floating-point format?
2. What about hidden-bit notation, which adds an additional bit of precision? Should I modify HP's 32-bit format to support it?

32-bit Format

In the first case, it was fairly easy to make the decision to stay with a 32-bit floating-point format. The impact of any changes would be too significant. And I'm not ready to consider those impacts.

Conclusion: Retain the HP 32-bit floating-point format.

Hidden-bit Notation

In the latter case, my thoughts are more nuanced. Here, there is only one single advantage in staying with the old HP format: the non-linear minimax constants they developed for their Chebyshev polynomials used for their transcendental functions could be retained without change. To counter this, the use of hidden-bit notation adds value in the sense of effectively supporting another precision bit in computations.

Conclusion: Abandon the increased precision offered by hidden-bit notation.

As a final note, it isn't difficult to modify the basic floating-point operations of addition, subtraction, multiplication and division to incorporate hidden-bit notation, should I later decide it is worth its costs. The change will be little more than adding the hidden-bit prior to performing the function. And that's not a difficult transition. So I can readily defer this issue to a later time. The focus, for now, can remain in the direction of compatibility.