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

[BarryMead]

(02-20-2015 09:42 AM)matthiaspaul Wrote:  

(02-19-2015 01:51 PM)Bit Wrote:  I'd expect trouble with library and user programs. If they change the RPN mode and get paused or interrupted, it'd be a major source of confusion for the user if the ENTER key suddenly works differently, especially as it may not be noticed right away. If the mode change only affects the program (e.g. it's stored as a local flag), then what should happen if you single step a program? I can't think of a good solution other than rewriting all library routines so they work correctly in both RPN modes and warn users that their programs will break unless they pay attention to this.

Let's assume that the behavioural changes effect ENTER (and perhaps a few other functions), we could introduce a new opcode for it. Thereby, existing code would continue to function as is (interpreted in Classical RPN mode), without any necessary preconditions to be met or modes to be preserved and enforced for specific routines. If the calculator is in Classical RPN mode, it would store the old opcode in program memory, if it is in Entry RPN mode, it would use the new opcode instead. Programming outside the calculator, different mnemotics would have to be used for the two flavours, f.e. ENTER↑ and ENTER or something along that line, or the same mnemotic would translate to different opcodes depending on the mode of the assembler.

Greetings,

Matthias

The deeper one gets into this proposed feature the more one realizes that it ISN'T TRIVIAL. A detailed specification of how the stack and it's lifting operations work is ESSENTIAL before any REAL progress can be made in implementing the code. Specifically every key on the keyboard, every shifted key on the keyboard, and every catalog accessed operation has a potential affect on the numbers in the stack and weather or not the next numeric key pressed should lift, or (not lift) the stack. These all need to be spelled out EXPLICITLY, and it isn't simple or trivial to evaluate and choose the correct behavior for each case. And asking the developers of all library and XROM functions to include special compatibility checks so that the new Entry modes won't break their existing programs is a big ASK.