Post Reply 
[34S] Proposal for Entry RPN mode with dynamic stack
02-19-2015, 10:10 AM
Post: #43
RE: [34S] Proposal for Entry RPN mode with dynamic stack
(02-19-2015 02:50 AM)Bit Wrote:  You wrote that stack-relative addressing would use the [R/S] key. But that's already assigned to the letter Y. [...] Alternatively, you could use [XEQ] instead of [R/S] for this purpose.
Thanks for pointing this out, Bit! I overlooked that letter Y is assigned to R/S in the current keyboard layout.

However, some calculators support power operations on registers like RCL-arrow-^ and STO-arrow-^. It might be a good idea to reserve the key currently assigned to XEQ for this purpose (as it is in the same row as all those power functions and also above the ^ key, so it seems mnemo-technically the best choice).

(I am using arrow-v and arrow-^ here in order to distinguish them from ^ and v, which are already in use for maximum and minimum.)

I guess, the ideal candidate for stack-relative addressing would be the R-arrow-v key (like in RCL R-arrow-v n). However, in the current layout, this key is also assigned to "I". If we couldn't live with that, we might use the RCL key instead (as in RCL RCL n), but name the function RCL-arrow-v. (In my work-in-progress proposal for an improved keyboard layout, R-arrow-v has been moved to where the RCL key is now, so the conflict no longer exists.)

Quote:Maybe it would be sufficient to only allow stack-relative addressing with some commands: e.g. RCL, STO, x<->, RCL/STO combined with basic operations, and their complex variants, but even then, it's very many new code points.
I'm open on this. [c]RCL, [c]STO and [c]x<> were the commands I had in mind to allow some basic stack addressing. If the scheme can be generalized without code overhead, even better. I haven't looked at how commands are encoded and how it would best fit in there, yet.
Quote:You're making extensive use of the [CPX] key in your proposals. Why is that? Is it simply that more key combinations are needed and [CPX] is available, or is there some logical reason behind it?
cRCL, cSTO and cx<> were meant as double-register operations, as used for complex numbers (but not restricted to them). Otherwise, I just used CPX because it was available (in the tradition that the CPX key is also used for a limited number of other "more complex" functions already). (However, in my work-in-progress proposal for an improved future keyboard layout, there is even some more logic behind this, but this should better be subject to another thread -- later.)

Alternatively, we might think about implementing some kind of "smart" switch between the current functions of the up/down keys and a stack roll function.

Quote:There's no unallocated persistent RAM available, so what should be sacrificed to store the stack depth?
Good point.

One possible solution, although not ideal, would be to store this and other necessary values in the first re-purposed register, so that the initial allocation for the dynamic stack would have to allocate two registers instead of one. We would
still need a single bit flag to indicate the existance of the dynamic stack then.

I will have to think about a better solution.

In either case, any such implementation details should be transparent for the stack-relative addressing, of course.
Quote:Marcus hinted that restoring the stack after an error could be a challenge. Have you had a look at the code (xeq() in trunk/xeq.c) already? That part may need to be completely rewritten if the stack is allowed to become very large.
I definitely will, but haven't found any time for it so far. Right now I am trying to utilize my limited time to write down a number of ideas before hopefully finding the time to help implement them somewhen in the future.
Quote:I understand that these ideas are a work in progress
Yes, and I very much value any constructive input on this idea.
Quote:but once the dust has settled down a bit, could you provide a single list of all proposed stack rotate and similar operations, each with a short explanation of what they do, how they'd be entered from the keyboard, and why they're useful?
I certainly can do that if necessary.

Greetings,

Matthias


--
"Programs are poems for computers."
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: [34S] Proposal for Entry RPN mode with dynamic stack - matthiaspaul - 02-19-2015 10:10 AM



User(s) browsing this thread: 2 Guest(s)