[WP34S] Documentation for Advanced Programming Commands and Techniques

[Les Wright]

I have been taking a close look at the source code in the /xrom subdirectory at Sourceforge. It looks to me a lot like FOCAL code, but there is extra stuff in there that is documented neither in the main manual nor the assembler manual--things like #define, XLBL, MONADIC, DYADIC, etc. I see plenty of the JMP and GSB pseudo instructions that get handled by the preprocessor, as well as LBL-less targets. But there are other things that don't get recognized by the assembler when I try to compile this code (for example, integrate.wp34s) into user code. I also notice that there are a few xrom-based commands--XEQUSR, POPUSR, SLVQ--listed in the op-code file, and thus supposedly accessible to the end-user, but I can find no documentation on what they are or how to use them.

So I guess my questions are this: how does one assemble the source code in that /xrom directory for the end-user? Can they be compiled and used outside of XROM, and if so, how? And with the XROM commands found in the op-codes file, how does the end-user access them and is there documentation out there that to guide the advanced programmer?

Hopefully some of the development team can edify me in plain English, or French.

Peace,

Les

[Marcus von Cube, Germany]

These commands fall into three groups:

#include, #define and the words like MONADIC and such are commands for the C preprocessor. The build process for xrom.wp34s uses it as a tool to build a file that can be handled by Neil's preprocessor and assembler.

xIN, xOUT, XEQUSR, etc., all flagged als XROM only in the op-code file, need a special environment and just won't work (or even crash the calculator) if encountered in normal user code. XROM is a very special environment.

JMP and GSB are handled by wp34s-pp.pl and are available for user programs as well to save LBLs. OTH, this makes changing programs on the device hard because all jump distances are precomputed. XROM doesn't have the problem because it's immutable.

[Walter B]

... and therefore we didn't document those commands and most probably never will. Else fora would become crowded by users employing those and running into troubles.

[Les Wright]

Thanks, all, you have confirmed what I was learning--that the XROM code is interdependent with the C-code and does not stand alone with modification. I have to say that the use of #define to give register contents more transparent names makes the code much easier to read.

Les

[Paul Dale]

XROM uses almost standard keystroke programs. The big differences are three:

1. XLBL -- provides the entry point addresses for the C code to call without requiring a LBL search. This also means we're not going to run out of LBLs either. This is a pseudo command -- no code is generated, just an entry point in a table.

2. xIN -- a standard entry that preserves the stack & lettered registers & allocates some local flags. It does a pile more, checking for NaN arguments, switching to double precision mode and so forth.

3. xOUT -- a standard exit that does the required stack manipulations, sets last X and so on, finally returning to user code or the keyboard handler.
   

Slightly simplistically, you take a key stroke program and put XLBL & xIN at the start and use xOUT instead of RTN to exit and you've got XROM code that is indistinguishable from a built in command.

This is worlds better than the previous XROM code that was quite difficult to code for -- check the history of the quadratic solver e.g. or look at the solve or integrate routines that don't use these helpers.

- Pauli