[wp34s] Is it possible to call an XROM from another one?

[emece67]

The tittle says it all. I'm trying to insert some code as a new XROM. This code, when in a library, works OK, but when modified to be an XROM reports an "Illegal operation". The culprit seems to the be a call to W[sub-p], which is another XROM function.

Is it possible to call an XROM function from another one? If so, how?

Thanks & regards.

[Marcus von Cube]

(05-12-2015 07:24 PM)emece67 Wrote:  Is it possible to call an XROM function from another one? If so, how?

Not through a command that's implemented in XROM. You can, of course, XEQ code within XROM but keep in mind that there is only a single XROM environment which is separate from the standard user environment (DP, private stack and subroutine return stack).

So if you need to call a function that is implemented in XROM and is using XIN, and if your function is using XIN, too, then you need to use subroutines for the common code. Look at the statistical distributions for examples.

[Paul Dale]

Marcus got it right. The key point is xIN. These cannot ever nest. The routines in XROM that don't use xIN are all fine to nest -- there aren't many of these.

That said, there are plenty of examples of XROM subroutines that are shared. The statistical distributions are one.


- Pauli

[emece67]

Thanks a lot for the insight.

I was not aware of that "un-nestability" of xIN environments. Both my code and also that of W[sub-p] have xIN inside.

I'll follow your advice and try to use the W[sub-p] code in a different way.

Regards.

[emece67]

Well, now I have a working inverse Gamma in XROM (not very tidy, as I also have modified the lambert_w code to place some hooks there). But I still have some doubts about xIN/xOUT workings.

I've read that executing xIN creates a "local" 8 levels stack, a "local" return stack & changes to DP. But, does it also create a set of 16 local flags? If so, will a subsequent LocR "hide" such flags? (I think the answers are {YES, NO}, but not sure.)

Suppose also that an XROM function executes xIN, then, inside such function, there's a LocR and a GSB, and this second subroutine ends with RTN. Will such RTN "free" the LocR'ed registers? (I think {NO}, they are freed by POPLR or xOUT in the calling XROM function.)

In an XROM function calling (via GSB) other subroutines, can LocR be nested? (I have no idea.)

Thanks.

[Marcus von Cube]

(05-13-2015 03:03 PM)emece67 Wrote:  I've read that executing xIN creates a "local" 8 levels stack, a "local" return stack & changes to DP. But, does it also create a set of 16 local flags? If so, will a subsequent LocR "hide" such flags? (I think the answers are {YES, NO}, but not sure.)

Not quite 16 because some of them (8 to 15) are reserved for system use. They hide the local flags in the same range. xIN does the equivalent of a call to LocR 0. If you call LocR again from the same subroutine level, that is not within code called by XEQ, the number of registers is adjusted and no new frame on top of the active one is created. If you call LocR from within a subroutine, it will get its own set of flags. But the system flags are still the same. They hide the local flags just created.

(05-13-2015 03:03 PM)emece67 Wrote:  Suppose also that an XROM function executes xIN, then, inside such function, there's a LocR and a GSB, and this second subroutine ends with RTN. Will such RTN "free" the LocR'ed registers? (I think {NO}, they are freed by POPLR or xOUT in the calling XROM function.)

RTN frees local data that has been created at the same subroutine level. Local data is allocated on the subroutine return stack. XROM code with an active xIN uses a special area in volatile memory for this purpose. So LocR inside a subroutine works in the same way as for user code but in a different memory area.

(05-13-2015 03:03 PM)emece67 Wrote:  In an XROM function calling (via GSB) other subroutines, can LocR be nested? (I have no idea.)

You should have got the idea now.

Yes LocR can be nested but the reserved area is limited in size. Cf. XROM_RET_STACK_SIZE in data.h.

[emece67]

Thanks a lot Marcus. Now, knowing the internal workings, I am sure (well, almost) that my XROM code(*) will work.

Regards.

(*) if fact it is not my code, I have only adapted code from the library.