[34S] Proposal for Entry RPN mode with dynamic stack
|
02-16-2015, 01:26 AM
(This post was last modified: 02-18-2015 03:04 AM by matthiaspaul.)
Post: #10
|
|||
|
|||
RE: [34S] Proposal for Entry RPN mode with dynamic stack
(02-15-2015 11:01 PM)Bit Wrote:The user would have to take care of this, possibly by enforcing the correct runtime environment in the init portion of the program. A program may generally depend on quite a number of mode settings (f.e. number of available registers, stack-size 4 vs. 8, float vs. integer, etc.), so this would be no exception.(02-15-2015 10:28 PM)matthiaspaul Wrote:What should happen if a program was written in one mode and then started in the other? Quote:Without some extra rules, some programs would work correctly, others would be obviously broken, yet others would be broken in ways that may be very hard to notice. The user could be made responsible for dealing with the first two cases... but probably not with the third.A valid point, but for as long as a program does not use stack-wise relative addressing of higher than base-level stack levels (via the proposed R/S addressing extension), register usage should be completely transparent for programs within the limits of what was allocated via REGS, originally. Recalling a value from an allocated R- but meanwhile re-purposed stack register will return 0 (the original value it had before being re-purposed). Attempting to store a value in such a register will make the R register available again immediately and shrink the dynamic stack accordingly. (The alternative solution would be to throw a hard error to make the user aware of the condition, but it might also confuse people, when an originally allocated register would happen to be no longer available out of a sudden. It would also be possible to subdivide the register area into two static areas, one for actual registers and the other for the stack, however, it would give up some flexibility and might be more cumbersome to set up for the user.) So, for as long as a program does not depend on a particular stack depth beyond the 4- or 8-level base stack (which, in contrast to RPL, is always guaranteed to exist in this dynamic RPN stack model), the program shouldn't notice a difference, and programs depending on it should know of the preconditions to be met. If higher-numbered registers are not used, it can be assumed that the stack can grow into them without problems (this is basically the same as sub-dividing this area into registers and stack statically, just easier to set up and more flexible). So, in many (if not most) cases, the user can take care of the necessary conditions. Still, you are making a valid point, since the stack depth needed to solve a problem may not always be known beforehand. Well, the stack depth available isn't known in RPL as well, the difference is that it can be assumed to be "deep enough" in virtually all cases, and also much larger than the possible 0..100 extra levels in this proposed dynamic RPN stack mode -- and if not, you'd get an error message instead of stack contents being silently dropped. If not a hard error message, at least some visual clue might be desirable to indicate a soft stack overflow. Such states could also be made software-detectable by some means. Greetings, Matthias -- "Programs are poems for computers." |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)