WP 34S and 31S bugs and fixes

[Bit]

While the best way to handle exponent entry is being elaborated, I've reworked the infrastructure that deals with it and introduced fine-grained compile time options to control what happens when exponents are entered.

Options available for negative exponents:

• Use a configurable fixed limit, e.g. -383.
• Don't allow denormal numbers but allow everything else: 100e-385, 1e-383, 0.1e-382 are legal, 0.1e-383 isn't.
• Allow denormal numbers only if all entered digits can be stored.
• Allow denormal numbers if at least one entered digit can be stored.
  

Options available for positive exponents:

• Use a configurable fixed limit, e.g. 384.
• Don't allow numbers that overflow to infinity: 10e383, 1e384, 0.1e385 are legal, 10e384 isn't.
  

A high or low absolute limit that further restricts exponents in addition to the above rules can be optionally set for negative exponents and separately for positive exponents.

A zero mantissa can be handled in these ways:

• Treat it as a number with one significant digit and apply normal rules.
• Allow any exponent, within the absolute limits configured if any, since zero will remain zero no matter the exponent.
• Allow any exponent even if absolute limits are configured.
  

Options available for changing the sign of the exponent:

• Limit exponents so that changing the sign is always allowed. E.g. if the permitted range without this rule is -383..384, only -383..383 will be allowed.
• Don't allow changing the sign if the resulting exponent would be out of the allowed range. Digits will be shifted or a warning will be produced.
• Changing the sign is always allowed, even if the resulting exponent violates other rules.
• Extend the range of exponents so changing the sign is always allowed. E.g. if the permitted range without this rule is -383..384, then -384..384 will be allowed.
  

All of the above can be configured independently for using the calculator with flag D cleared or set. There's also a debug option present that allows all of the above to be controlled at run-time using numbered registers and flags.

I've added the following optional new features:

• Produce a warning (too long, too big or too small) instead of shifting the digits in the exponent when the entered number would be out of range. With dynamic exponent limits I think this is more useful behavior.
• Warnings during number entry (bad digit, too long, too big, too small) occupy the upper line only and don't hide the number you're typing. Warnings are just as informative but less disruptive.
• Entered exponents aren't zero padded, instead they're displayed left justified. If digits are not shifted, some may prefer this.
• Entered exponents are padded with spaces instead of zeros. If digits are not shifted, some may prefer this.
  

I've fixed the following issues:

• The calculator could be tricked into accepting too large exponents.
  Try this: [EEX] [4] [0] [0] [9] [9] [9]
  It happened because leading zeros were not removed after digits were shifted.
• If a minus sign was followed immediately by a decimal mark, a zero was not inserted before the decimal mark.
  Try this: [0] [+/-] [<-] [.] [5]
  The display will show -5 but you'll be entering -0.5
  The same bug caused domain errors when entering fractions: [0] [+/-] [<-] [.] [1] [.] [2] [ENTER]
• If the command line was full, the digits in the exponent couldn't be shifted as expected:
  Enter this: [1] [.] [2] [3] [4] [5] [6] [7] [8] [9] [0] [1] [2] [+/-] [EEX] [+/-] [1] [2] [3] [4]
  You'll get a "too long" warning rather than the exponent -234.
  

The code is structured in such a way that the compiler can eliminate unused branches. Despite the extra features and fixes, if the new code is configured to mimic the old behavior (minus the bugs), the size of the compiled code is slightly smaller. That's the default configuration I've committed, considering that the decision about exponents is still pending. The same changes have been applied to both the 34S and the 31S.

I've attached a 34S flash image and a Windows binary to showcase the new functionality:
- With flag D cleared, denormal numbers and overflowing into infinity are not allowed, and additionally exponents are limited to the -383..384 range. E.g. 1e384 is OK, 10e384 isn't, 1e-383 is OK, 0.1-383 isn't.
- With flag D set, denormal numbers are allowed as long as all entered digits can be stored, overflowing into infinity still isn't allowed, but exponents aren't capped. All of these are OK: 0.01e386, 1000e-401, 0.12e-396, 0.1e-397.
- In both cases, changing the sign is only allowed if the resulting exponent is legal.
- Exponents are left justified, and digits aren't shifted, warnings are produced instead.
- Warnings appear in the upper line only, the entered number doesn't get hidden.

It's a relatively large number of changes and while I made an effort to test every code path and combination, it's possible that some bugs remained in the code, which I'll fix in subsequent updates. As usual, feedback would be welcome.

We can do basically anything we want with the exponents without a very big increase in firmware size. Q.E.D.

(Edited to add a third option to how a zero mantissa can be handled, as requested by Nigel.)