RPN-PRGM: New Windows console application emulating HP calculators

[Aacini]

I solved part of the mystery:

Code:


RPN: FPUPC:3
-1.#UND

RPN: 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
1.0000000000000000E+016 = 10.0000000000000000E+0015 = 4034_8E1B_C9BF_03FF_FFF9

RPN: FPUPC:2
4034_8E1B_C9BF_03FF_FFF9

RPN: 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
9.9999999999999820E+015 = 9.22337203685477580E+0015 = 4034_8E1B_C9BF_03FF_B800

RPN: FPUPC:0
4034_8E1B_C9BF_03FF_B800

RPN: 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
9.9999916826296320E+015 = 9.22337203685477580E+0015 = 4034_8E1B_C200_0000_0000

RPN: FPUPC:3
4034_8E1B_C200_0000_0000

RPN: 1e16 sci:16 out out:" = " eng:17 out out:" = " hex:3 out
1.0000000000000000E+016 = 10.0000000000000000E+0015 = 4034_8E1B_C9BF_03FF_FFF9

RPN.exe first parses the whole input line (using the current Precision Control). After that, the whole line is executed. This means that when the next line is parsed, the parse routine uses the same Precision Control set by the last executed line. Of course, this introduces differences...

As I said several times, my ENG:p method is not reliable. You should conclude nothing about the FPU/RPN.exe operation based on the results displayed by ENG:p. I am looking for a more reliable method to show an 80-bits floating point number.

Antonio