Detect when Advantage Module solver is running?

[Dave Britten]

Does the 41C Advantage Module SOLVE program set any flags when it's running, similar to flag 45 on the 42S? I'm trying to figure out if it's possible for a program to detect that it's being run by SOLVE, and I don't see any mention of this in the Advantage manual.

[rprosperi]

(10-08-2020 08:48 PM)Dave Britten Wrote:  Does the 41C Advantage Module SOLVE program set any flags when it's running, similar to flag 45 on the 42S? I'm trying to figure out if it's possible for a program to detect that it's being run by SOLVE, and I don't see any mention of this in the Advantage manual.

I can give you a firm "I don't know", BUT, if it did, it almost certainly would have been documented, so likely not.

That said, there was talk back in the day, that some modules used some FLAGS for their own reasons in their own code, but current status was saved on entry and restored on exit, under the assumption that doing so would not affect user code expectations. But I don't recall the details, or even if it was HP modules that were being discussed.

Look in the PPC ROM manual under the programs related to flags, it's a likely place this would have been discussed.

[Valentin Albillo]

(10-08-2020 08:48 PM)Dave Britten Wrote:  Does the 41C Advantage Module SOLVE program set any flags when it's running, similar to flag 45 on the 42S? I'm trying to figure out if it's possible for a program to detect that it's being run by SOLVE, and I don't see any mention of this in the Advantage manual.

If anybody knows for sure, that'll be Ángel Martín, who knows 41c assembler programming inside out and can disassemble the Advantage ROM to have a look.

Me, I think that no flags are set that the user can test, but if no one else posts a solution I'll give you a workable one tomorrow (too late now, almost 7 am, I must sleep).

Also, indulge me: why does your function need to know who's calling it ?

V.

[Ángel Martin]

I'm far from being the kind of expert Valentín suggests, but the SOLVE/INTEG is familiar territory ;-)

My first thought and probably the easiest way is to check for buffer 14 existence within your program. This is easy if you use the appropriate function, like B? in the OSX module and others (the response is yes/no, skip next program line if false rule).

There are other approaches but they're iffier and more complicated, so I'd stick with the one described above.

I remember using this trick to do some troubleshooting, adding the buffer catalog function BCAT in the program called by SOLVE/INTEG in order to verify the number of registers allocated in the said buffer in different cases.

Cheers,
ÁM

[Dave Britten]

(10-09-2020 04:46 AM)Valentin Albillo Wrote:  Also, indulge me: why does your function need to know who's calling it ?

For saving a global label. The usual trick is have your program SOLVE itself, and at the beginning of the program, test for the solver currently running and branch to the actual calculation routine. Thus you can XEQ the program and have some input prompts, and then kick off the solver.

Thanks to everyone confirming that I didn't simply miss something in the documentation. I'll probably just SF 0 before calling SOLVE, then CF 0 after it's finished. The lingering 0 annunciator will make it obvious that I need to clear the flag if SOLVE is interrupted for some reason.

[Valentin Albillo]

(10-09-2020 11:57 AM)Dave Britten Wrote:  Thanks to everyone confirming that I didn't simply miss something in the documentation. I'll probably just SF 0 before calling SOLVE, then CF 0 after it's finished. The lingering 0 annunciator will make it obvious that I need to clear the flag if SOLVE is interrupted for some reason.

Yes, that's the easiest way, though it has two caveats: (1) you must be aware of the status of flag 0 and clear it manually in some circumstances, and (2) it uses a flag.

When I saw your post, I was 99.9% sure than SOLVE didn't set any flags which the user could test, and the only particular thing that SOLVE did was to fill up the stack with the same value, so I thought that your function or program could check this and if X = Y = Z = T it would then decide it was being run by the Solver, provided that when running it otherwise you'd ensure that this condition wouldn't be met. Something like this:

        LBL "FUNCT"
        X#Y?
        GTO 00
        X<>Z
        X<>Y
        X#Y?
        GTO 00
        X<>T
        X<>Y
        X#Y?
        GTO 00
        (we're being executed by the solver, the stack holds now X = Y = Z = T)
            ...
        LBL 00
        (we're not being executed by the solver, X holds now the original X value)
            ...

This doesn't use any flags and executes fast but to call it not from the solver you must ensure that the stack doesn't hold the same value in all registers at the time of the call. If necessary, this can be forced by calling it like this:

        0, non-zero value, XEQ "FUNCT"
or
        non-zero value, 0, XEQ "FUNCT"

or something like that.

V.

[Dave Britten]

(10-09-2020 04:32 PM)Valentin Albillo Wrote:  Yes, that's the easiest way, though it has two caveats: (1) you must be aware of the status of flag 0 and clear it manually in some circumstances, and (2) it uses a flag.

In this case, I'm the one writing the program, so I shouldn't have any trouble there.

(10-09-2020 04:32 PM)Valentin Albillo Wrote:  When I saw your post, I was 99.9% sure than SOLVE didn't set any flags which the user could test, and the only particular thing that SOLVE did was to fill up the stack with the same value, so I thought that your function or program could check this and if X = Y = Z = T it would then decide it was being run by the Solver, provided that when running it otherwise you'd ensure that this condition wouldn't be met. Something like this:

That's a very clever idea too!