HP-71 BASIC funny quirks

[J-F Garnier]

(01-28-2023 12:39 PM)Albert Chan Wrote:  If I understand correctly, the process of tokenizing HP71B program, we lose the source.
That's why de-compiler was needed, to reconstruct the source, as close as possible.
This save memory, at the cost of slower program listing. (reconstruction takes time)

The delays in line editing are the main drawback of this approach.
Actually, the 71B is quite efficient, the delay is noticeable but not too long.
Series 80 machines and the HP-75C, despite their faster 8-bit CPU, were less efficient, and delays of one second or so were not unusual for a moderately complex line.

Quote:

(01-27-2023 04:21 PM)J-F Garnier Wrote:  The initial intent was very likely to have a constant value embedded in program lines looks exactly as the STD output for the same number ...

If the goal is STD mode for all numbers, why is the test necessary?
No test, no bug?

For STD mode, a test has to be done somewhere to choose between FIX format (w/o exponent) and SCI.
What may be surprising is that the decompile code duplicates the STD formatting process, that is already existing for DISP and PRINT statements.
I guess the reason is that the input number is in a different format so a conversion was anyway needed, and the choice was not to convert the embedded constants to the internal standard form used by all math code then apply the STD string formatting code, but instead directly convert from the embedded constant format to STD string format.

J-F