Sluggish behaviour whilst in USR mode (specific test case)

Please report issues with the DM41X Beta Firmware in this sub-forum
jonmoore
Posts: 106
Joined: Mon Apr 13, 2020 4:18 pm

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by jonmoore »

I've been experiencing sluggish stack behaviour at various points of my daily workflow since CST has been introduced. My initial suspicion was that it's connected to XEQ+ but once Ángel and I got that out of contention, I started to strip my setup to lessen the variables and honed in on PFCT as I'm home schooling the kids at the moment and prime factorisation is part of most problems we're working through.

They have to make do with i41cvx on iOS backed up by the 35s and 40gs (whilst jealously waiting for my DM hardware to become a hand-me-down the can argue over). They'll have a very long wait! 8-)
Last edited by jonmoore on Tue May 19, 2020 8:10 am, edited 1 time in total.
Ángel Martin
Posts: 109
Joined: Mon Apr 24, 2017 8:19 pm

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by Ángel Martin »

rprosperi wrote:
Mon May 18, 2020 10:38 pm

But your example gives me a hint. Using CK in the PPC ROM leaves the program counter in ROM, which could be the common issue here. Seeing the PC in ROM could be why Angel was thinking it was below the curtain? Perhaps the Sandmath module does this as well (which is not a problem, but could be something which was not assumed.)
I was thinking that the PC was below the curtain because the PC was below the curtain: the differences are pretty obvious. When you stay in ROM you see the program steps listed, not the garbage characters resulting from the OS attempt to interpret the NNNs and other stuff in the status regs. Besides, you *can* delete those gibberish steps (not that you want to because it likely results in ML as soon as you touch the content of register c) using the back arrow, so the PC is clearly in RAM.

After the additional feedback provided to this thread it appears clearer to me that using CST after running a FOCAL program in ROM messes up with PC allocation - probably (or maybe) because the CST implementation does not check the status of CPU flag 10 at that stage - and it defaults to RAM even when it should stay in ROM.

This is not caused by the SandMath, the Libray#4 or what have you. And to answer a previous question the issue does not exist on V41, the CL, Clonix etc - that was duly verified before reporting it in the first place. So I understand the more advanced features tend to be frowned at as the suspect of misbehavior but usually what happens is they exercise non-trivial areas of the system that are frequently omitted by the other developers, nothing more sinister at play. The fact that the problem also manifests itself with CK in the PPC is a vindication of this fact big time.
rprosperi
Posts: 1029
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by rprosperi »

Thanks for confirming my conclusion. No one was blaming the Sandmath module, that it works fine on other platforms is pretty strong evidence that the problem is not there, however since it was initially reported that the problem was only seen using that, its reasonable to ask what that does which isn't typical. But the finding that other modules could bring out the problem as well is what lead to my conclusion about the PC being in ROM as the likely initial condition leading to the problem.

But in your initial post here, you noted "You can see that by switching to PRGM mode and SSTíng the listings (really the status registers and I/O buffer contents shown as program steps)." Can you please explain how to do that, I was unable to see this in PRGM mode.

Thanks
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Ángel Martin
Posts: 109
Joined: Mon Apr 24, 2017 8:19 pm

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by Ángel Martin »

rprosperi wrote:
Tue May 19, 2020 3:18 pm
But in your initial post here, you noted "You can see that by switching to PRGM mode and SSTíng the listings (really the status registers and I/O buffer contents shown as program steps)." Can you please explain how to do that, I was unable to see this in PRGM mode.
I switch to PRGM mode and use the down arrow (SST), no special wizardry involved... the garbage lines are displayed as an attempt by the OS to interpret the status regs contents.
rprosperi
Posts: 1029
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by rprosperi »

Thanks. I tried that, numerous times, but could not see that. I understand what you mean, the random contents look like jibberish FOCAL commands, but could never see that.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Ángel Martin
Posts: 109
Joined: Mon Apr 24, 2017 8:19 pm

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by Ángel Martin »

here's one example - the line is scrolled right, so it believes it is program step "01"
Maybe it's related to the Display screen?
Attachments
20200519-15491801.bmp
20200519-15491801.bmp (12.31 KiB) Viewed 312 times
rprosperi
Posts: 1029
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by rprosperi »

Thanks! I had no doubt at all that you could see it, I simply couldn't when I tried. It must be a matter of subtle timing and sequence...

I also note your highly descriptive program name... :lol:
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
rprosperi
Posts: 1029
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by rprosperi »

The problem has been found and fixed.

The cause is not quite what we speculated above, but close. And we were correct, that it only occurs when the PC is left in ROM (meaning in a FOCAL program) when using CST.

As this is a relatively small and non-destructive issue (as long as you don't go romping through RAM and delete stuff) a new build is not going to be released as some other work is in-progress.

If/when you encounter this sluggish stack behavior, simply doing [GTO] [.] [.] will restore order.

Thanks to all that tested, commented and opined!! :D

Detailed reports, test confirmations and exploring alternate scenarios help a huge amount in isolating the causes during BETA review, we appreciate it all and it helps to make it quick and easy(-er) to fix.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Dan Simpson
Posts: 63
Joined: Wed Mar 18, 2020 3:29 pm
Location: Arizona

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by Dan Simpson »

This may not be limited to the 41X...
A funny thing happened to me today.

I took my 41CL out of my briefcase today and attempted to take the square root of something.
It took about 5 seconds in TURBO5 mode. I was in USER mode at the time.
I switched out of USER mode and repeated the calculation. This time it completed instantly.
I switched back to USER mode and again the delay was there.

Remembering this thread, I switched to PRGM mode and found myself below the curtain.
GTO.. cured the problem and I can't reproduce it. And, I have no idea what I would have done the last time I used it to cause this.

Just another piece of the puzzle.
I hope it helps.
My Spirit animal is a Basset Hound.
My Collection: HP-55, HP-67 (Teenix Mod), HP-15C, HP-16C, HP-41CV, HP-41CX, SY41-CL (x2), DM41X (Beta), DM42, HP-42S, HP-48G, HP-71B (x2), HP-75C, HP-150.
rprosperi
Posts: 1029
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by rprosperi »

The symptoms are not unique to the 41X, they can happen on any 41 platform, however the reported issue was indeed triggered here when using the CST function, which had a bug, now fixed.

What modules do you have loaded on your 41CL? The PPC ROM uses lots of routines which move the curtain about hither and yon, and if not used carefully, you can end up this way. Most often it's caused by dabbling with Synthetics, but it could also result from some other modules.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Post Reply