[34S] Proposal for Entry RPN mode with dynamic stack

[matthiaspaul]

(02-18-2015 08:53 PM)BarryMead Wrote:  

(02-18-2015 07:13 PM)Thomas Radtke Wrote:  I have to agree with Walter (if I understood correctly) that a second, parallel implementation of an entry method makes things more complex and thus more prone to bugs. And as most users will likely use one method exclusively, it splits the set of potential beta testers ;-).

Having worked on Torsten Manz's HP-15C simulator, I can attest to the complexity and myriad of bugs that surround the deeply embedded issue of STACK LIFT (It is a nightmare). Adding additional stack lift modes would greatly increase the potential for bugs in hundreds of places in the calculator,

Can you explain where you see hundreds of places affected when we would, only in Entry RPN mode, change the conditional X into Y duplication behaviour of the ENTER key, so that it does no longer happen immediately, but only when ENTER is pressed multiple times in succession?

What I envision in regard to an Entry RPN mode should be doable by a few isolated changes to the existing state machine, not a "parallel" implementation of a second state machine or a complete rewrite (except, perhaps, for other reasons like saving space - however, that would be a major task, whereas implementing an Entry RPN mode isn't IMHO).

Apparently you see much more necessary changes in the behaviour model. Can you perhaps give some hints? I must be missing something obvious, but perhaps we are just talking about different things...

Quote:and would at least double the difficulty of testing and maintaining library functions or collections of user programs.

I think, framing routines with (the equivalent of) STOM and RCLM and enforcing the proper settings inside (or bailing out with an error) is about all that would be necessary. I don't think this is much different from other preconditions that need to be tested for by routines. It certainly needs to be taken care of, but I don't think that it must be feared.

For code entered on the calculator itself, it might be possible to even make such mode switches completely transparent for users as the calculator knows which mode was used while entering a program.
It might be possible to just use different opcodes - I will have to think about it...

Greetings,

Matthias