A harmless, but beneficial, change to the LBL command

[MickM]

I have a request to make regarding the operation of Free42/Plus42 that I believe is utterly inconsequential to everybody's operation of the calculator. It does, however, represent a departure from the "normal" operation of HP's calculator but that's likely because I believe HP paid no attention to the possibility of what I'm suggesting. I'm making a skin for Free42/Plus42 that includes a menu of physical constants and properties. In essence, a screen menu is put up where each button trivially has a program behind it that looks like:
LBL 01
1234
RTN
Pretty harmless, right? Obviously the returned constant can be anything (speed of light, the gravitational constant, the Plank constant etc.). The calculator itself only has one built in constant, namely pi, and I wanted to expand on that.

The problem relates to CLX and it's temporary inhibiting of a stack raise (signified by setting FLAG 30). If I do a CLX followed by entering a new number then the 0 in X is not pushed into Y but instead directly feeds X. Likewise, CLX followed by pi also leaves Y unaffected. The temporary stack raise inhibit initiated by CLX is reset by just about everything except only for a very small set of operations. Indeed, even manually doing:
CLX
STO 01
PI
pushes 0 into the Y-register (presumably the STO operation was something consequential (it effectively defined X at that point) so STO reset the stack raise inhibit flag 30.

Now some operations generate no consequence at all, so you could do:
CLX
BASE  # bring up the BASE conversion menu
EXIT  # immediately exit, i.e. nothing of consequence done
PI
and the 0.00 in X is therefore NOT pushed into Y.

Which brings me to my dilemma. Again consider:
LBL 01
1234
RTN
As it turns out, simply executing the fully inconsequential LBL command resets FLAG 30 even though nothing has officially happened yet! If I invoke my constants program and have my first menu button labeled as "g" for the standard constant of gravity (9.80665 m/s^2) and behind that button all I have is:
LBL 01
9.80665
RTN
then if I do a CLX before pushing the menu button for "g" the 0 in X is unexpectedly pushed into the Y-register. I fully believe HP should have left FLAG 30 alone when passing through a harmless LBL command i.e. it was either a bug or simply an oversight. FLAG 30 should be subsequently reset only when something of consequence happened within the program itself (and again, that pretty much most operations).

So all of the above is a plea for Thomas Okken to change the LBL command to NOT reset FLAG 30 and let just about anything else you do afterwards in the program take care of that in the usual way. I don't see anybody else noticing anything different as a result of this i.e. it'll be fully backwards compatible and harmless. I also suspect it's a small and straightforward change to make. That's it, I've done my very best to promote this :-).

[Didier Lachieze]

The change you propose is not harmless, it will break any program that includes a CLX instruction before a LBL. This is something I use very often to initialise X to 0 before entering a loop.

[MickM]

So that's a fair point, however I'm willing to bet that the very next instruction you execute after the CLX to initialize your loop would clear FLAG 30 and you wouldn't see any change in operation. Again, the VAST majority of commands do clear FLAG 30. Would you mind please confirming? 

[Didier Lachieze]

With your change a simple RCL as the first instruction in the loop after LBL would overwrite the 0 in X  instead of pushing it to Y as expected. So this is a significant change in operation.

[MickM]

Rats - you're right! :-(

I guess that changes the flavor of my request to how can I determine if a CLX was done right before executing a program? 

[MickM]

Sorry - I can't figure out how to edit my post. I meant to say "how can I determine if a CLX's stack lift inhibit (FLAG 30 set) is in force when my program is invoked"

[Thomas Okken]

Sorry - I can't figure out how to edit my post.

Somewhere along the line, it appears that Google, in their infinite wisdom, have removed the capability of editing messages after they've been posted. Very annoying. I'm still debating whether this is bad enough to warrant running my own phpBB server for this board. :-/

[MickM]

Still trying to figure out how a program can determine if the result it returns should lift the stack or not based on a CLX's stack raise inhibit (i.e. FLAG 30 set) being in force when the program is called. I'm currently assuming there is no way to do this normally (which is a shame). Given that my original proposal was successfully shot down, how about the following. Would it be possible for a LBL command to be modified to copy FLAG 30 (before it gets reset) into another FLAG that stays sticky but is reset when control is returned to the user i.e. it's effectively only available inside a running program. I'm open to any ideas that achieve what I want - this idea is simply a suggestion...

[Thomas Okken]

Yes, that would be a good approach. Easy to implement and no compatibility issues.

It will require a new function, to query the new flag, since the regular flags are all in use by now.

[Thomas Okken]

Or rather, copy flag 30 in XEQ, rather than LBL, because XEQ clears flag 30, too (almost everything clears flag 30, really).

[MickM]

Oh - that's a very good point! Flag 30 would be cleared even before you got to the LBL. 

[Thomas Okken]

Any ideas what the query function should be called? I'd go with CALLER_STACK_LIFT_DISABLED? but that's a bit more than 7 characters. :-)

[MickM]

I'm fine with long descriptive names. Just spit-balling a bunch of other candidate names:

INHERITED_CLX
USER_CLX
EXT_CLX_STATE
CLX_ACTIVE

Maybe the above will inspire some other useful name. Is this name anything the user will ever see? I assume in the end a user will simply interrogate a flag number, right? Say e.g. flag 99 held the state of the external CLX, then my constants program would do something like:

LBL 01
FS?C 99
CLX
12345
RTN

Regards,
Mick

[Thomas Okken]

No, you're misunderstanding... Function names must be 7 characters or less.

[MickM]

Oh, I assumed all this was going to end up in a FLAG - guess not. In that case you might want to be even more generic and make two functions like:
  →CLX (reads the external state of CLX's flag 32)
  CLX→ (Sets flag 32 on the outside so the program itself can inhibit a stack raise)
That last function is outside the scope of what I was personally looking for, but it does have mertis.
I'm still not 100% sure how the function will operate i.e. will it skip an instruction and clear it's state like the FS?C operation I originally thought? Perhaps if I knew the intended operation I could come up with a clever name :-). Maybe a third function named:
  CLX?

[Thomas Okken]

Oh, I assumed all this was going to end up in a FLAG - guess not.

No. As I wrote a few posts ago in this thread:

It will require a new function, to query the new flag, since the regular flags are all in use by now.

 

And...

In that case you might want to be even more generic and make two functions like:
  →CLX (reads the external state of CLX's flag 32)

You lost me there. Or are you suggesting that XEQ should preserve the state of all flags? If so, why?

[MickM]

Sorry for the confusion, although I'm unclear why you thought I was after storing ALL the flags.
As I understand it (after your reiterated clarification), you're copying Flag 32 into a new, internal flag and creating a new function or command specifically to test that flag.
The simplest name I can think of for that function would be CLX? (given that the functionally is so specific)
What I'm still confused about is how that function would work. If it returns a value in the X-register then all of a sudden I have to save off the T-register beforehand and restore it as needed for each of my constant menu buttons. My hope would be the function/command behaves like DSE or ISG in that it skips an instruction if true i.e.

LBL 01
CLX?
CLX
12345 # my random constant
RTN
 
The program either raises the stack when putting 12345 in the X-register, or it replaces the X-register with 12345 if the external CLX was detected.
I'm still fuzzy on when the new internal flag get cleared. I'd be happy if it did that at the same time as executing "CLX?". Perhaps the function/command might then be better named "CLX?C".

I hope I haven't made things muddier. I guess I know what I want, but am getting lost on implementation details. 

[Thomas Okken]

I was thinking that CLX? (don't like that name because CLX isn't the only function that disables stack lift) (also, we're talking about flag 30, not 32) would be a conditional, so it would skip the next line if stack lift had been enabled before the last XEQ, and execute the next line if stack lift had been disabled.

Adding a function that would allow a user-defined function to disable stack lift... Hmm... I can't escape the feeling that this is all just taking a really minor issue and turning it into something too complicated...

[MickM]

Sometimes I reckon if I had half a brain I'd be a half-wit :-/.Yes, it's flag 30, not 32 (and I knew that too...). Good point about CLX not being the only thing that disables a stack lift so, yes, the name CLX? is therefore misleading. In case you're still hunting for a better 7-letter name, and given that CALLER_STACK_LIFT_DISABLED is out, maybe something like STKLFD? or STLFTD?. Not sure what characters are usable in the name, but STK↑ D? would also work (although being an EE I'd also be OK with STK↑B? where the B stands for "bar"). Or maybe STAK↑D? gets you to 7 characters. You could also prefix it with a C for caller (or E for external) if you abbreviate it some more. Or I could let you sweat the name and I'd just be delighted with the new capability ;-).

I also agree that adding a function to disable a stack lift can certainly wait until a need arises (if ever).

[Thomas Okken]

I'm going with CSLD?, as in "caller stack lift disabled."

I just implemented it, except for the changes to FUNC to make recall-type functions (FUNC 01) respect the stack lift state as well. I'll do those along with the FUNC overhaul I'm currently working on.

[MickM]

This is just great!!! Thank you very much :-) 

[Vincent Weber]

I can see the CSLD? function exists, but is nowhere to be found in the various catalogs. Is it planned to be under the "stack" or "prgm" catalog ? 

[Thomas Okken]

Good question. CATALOG -> PRGM would be the logical place, I guess.