[WP34s] XROM routines



#25

I just saw this in the new SVN:

XLBL"MAX"
STO L
x< Y
x[<->] Y
DROP
RTN
I guess this gives the MIN and not the MAX of X and Y.

(same for XLBL"MIN", it's also wrong)

Just wanted to mention it before we really get a new build which then again doesn't work correctly anymore. ;-)

Franz


#26

It's very likely that the recent build(s) are completely broken because we are doing a major overhaul of the code base.

Your analysis of MAX seems to be right. The code isn't included yet so no harm is done.


#27

Quote:
It's very likely that the recent build(s) are completely broken because we are doing a major overhaul of the code base.

Oje oje, so what you're doing currently is rather a program demolition than a program development, correct? ;-)

#28

It's more of a metamorphosis. Kind of transforming a caterpillar into a butterfly. This takes its time. :-)

#29

Franz, great catch. I threw that code together late last night and hadn't tested it :-( Luckily, it wasn't being included.


The current development effort is to move a lot of the C functions into the XROM (keystroke) portion of ROM. This should reclaim a lot of space which we can then either provide to the user as additional library space or use to add new functions and capabilities.

We've done a lot of working making XROM quickly callable and expanding and modifying the relative addressing the assembler can generate. We're also currently working on providing double precision support so the converted routines can work without introducing any additional error in the results and in providing some utility routine entry/exit routines to greatly simplify stack and last X management.

Exciting times for the project but also a huge amount of effort will be required. So if anyone wants to volunteer to help code some of the mathematical routines, drop any of us a line. The only skill you need is being able to write mathematical FOCAL programs.


- Pauli


#30

Is it intended that since a few versions manually entering a RTN (or END) is now displaying "true"?

(and RTN+1 shows "false")

Franz


#31

A manual RTN should simply set the PC to the beginning of the program area in RAM and clear the return stack. There was a bug which prevented RTN to behave correctly in certain circumstances. I suppose that my fix did break the manual RTN function.

Edit: It was just a missing "else". Fixed now.


Edited: 6 Jan 2012, 9:15 a.m.

#32

No, RTN and RTN+1 shouldn't display true or false. If they are it is a bug.

Conversely, the built in quadratic solver will now display true for real roots and false for complex -- a function of the rewrite using double precision mode and the new XROM prelude / epilogue -- these handle all the stack and last X management and allocate local registers, switch to an eight level stack and change to double precision mode. Porting code to XROM is now a matter of putting xIN at the start and using xOUT instead of RTN.


- Pauli


#33

The manual RTN case is fixed. The quadratic solver should not display true/false when called manually. If it does I need to look at the reason why. A neat "C" in the display should suffice for the complex case.

(Edit: C is shown as intended, not true or false)

We have many unused special flags, namely X, Y, Z, T, L, I, J and K which might play a role here. A to D already have a meaning, C is the binary carry bit, but may be redefined here. This would make the 'skip next step on complex result' mechanism obsolete. Any suggestions?

Edited: 7 Jan 2012, 3:50 a.m.

#34

BTW, there's still another thing that would interest me: execution time!

Have you made any tests on a real calc of the execution times of these new (now XROM) functions? I could imagine that there might be a quite big difference between running these functions as either builtin or XROM code (maybe comparable to interpreted or compiled BASIC programs in the beginning of the computer aera)!?

Certainly not if you just use such a function once (i.e. manually), but what if these XROM functions are called within a program loop?

Franz


#35

No we've not looked at execution time. The 34S guide has always been correctness then functionality then speed. That won't change unless the speed becomes unmanageably slow.

The keystroke program interpreter is fairly efficient and floating point operations are very slow on this device -- some very much so (logarithms). Most of what I've converted so far is pretty esoteric or fairly trivial -- i.e. speed isn't a big issue.

I'm not planning on ever converting the core functions (trig, exponential, log, arithmetic, square root). I doubt I'll convert gamma and a few other more advanced functions. I'm thinking about doing the statistical distributions where a slight slow down will hardly be noticed and more of the easy functions.


There is only one of me and there is a lot to do :-(


- Pauli


#36

Quote:
There is only one of me

No cloning allowed in Australia? ;-)

#37

Unfortunately, no. If it were allowed my world domination plans would be very much advanced.

At least there is an avid tester and reviewer of the code I commit who catches mistakes for me :)


- Pauli

#38

Quote:
I just saw this in the new SVN:

Well, since a few SVN versions I even see lots of (still undocumented) new commands in the XROM routines and also in wp34s.op, for example:

xIN, xOUT, xMSET, xMCLR, CNVG?, SHFL, iRCL, sRCL, dRCL, BSRF, BSRB ...

Now I'm curious: are these commands only for creating XROM routines (i.e. to compile for the developer team), or do they also have any use for the end-user in writing programs for the WP34s?

In the second case it would be very helpful if we could get at least a minimum description of what these commands do and how to use them.

Franz

Edited: 9 Jan 2012, 7:07 a.m.


#39

Those commands that are only eligible for XROM will show up with an "xrom" attribute in the wp34s.op file. These will behave as unrecognized instructions if attempted to be used via the assembler in the user area of the calculator (RAM or flash).

Since they are not available to the user, they will not appear in any catalogues in the calculator itself.


#40

Aha, so that still leaves CNVG?, SHFL, iRCL/sRCL/dRCL, BSRF/BSRB for usual programming ...

But how to use these commands?

Edited: 9 Jan 2012, 10:06 a.m.


#41

Franz,

here you are:

CNVG? - A convergence test. Ask Pauli for details.

SHFL - A generic 4 level stack shuffler. The argument is bit encoded, so not really useful for casual programming.

BSRF/BSRB - Branch SubRoutine Forward/Backward: SKIP and BACK for subroutine calls.

iRCL/sRCL/dRCL - These are mine :-). They are "alien" RCL instructions which allow the access to data stored in the "wrong" format.

iRCL - takes an integer value stored in one of the integer modes and recalls it to X, properly converted.

sRCL - takes a single precision value in a register and recalls it to X, properly converted.

dRCL - takes a double precision value (register numbers match those for DBLON mode) and converts it to single precision or integer if required.

DBLON mode creates a double precision environment. The named registers are converted automatically. The necessary room is taken away from the high numbered registers. Register access is double precision, too. For example, STO 01 will access the space otherwise occupied by single precision registers 02 and 03.

xIN/xOUT are only available to XROM code. They create a private double precision stack and return stack (for RTN addresses and local registers and flags), not interfering with the user's data.


#42

Quote:
iRCL/sRCL/dRCL - These are mine :-). They are "alien" RCL instructions

Well Marcus, as you described these functions they are indeed 'alien' and would probably better fit into 'Area 51' than into the WP34s. ;-)

As for BSRF/BSRB: I've no clue how they could differ from the usual BACK/SKIP? If they should return after going to a subroutine, then what's the difference to a simple XEQ ?

And I guess SHFL can arrange the stack in any order!? Well, with the 4 available stack exchange commands (x/y/z/t<->..) I don't really see any use for this exotic command.

In short words: now I know just as much as before. ;-)

Nevertheless thanks!


#43

In XROM, the relative branches are very fast because there is no search, the offset is directly added to the current program address. XEQ and GTO need to search for the label which is less efficient. For user code, the advantage is smaller because the relative branches make a search in order to detect the long instructions (such as LBL'ABC') and count them only as a single step. For XROM, all the 'dirty work' is done by the assembler during compile.

The "alien" RCL instructions are interesting for those who regularly switch between modes and need access to data stored in another mode than the one they are currently working in. Maybe I'll add the corresponding STO instructions one day.

SHFL simplifies some operations for XROM commands (look at xrom/quadratic.wp34s).


#44

Quote:
In XROM, the relative branches are very fast because there is no search, the offset is directly added to the current program address. XEQ and GTO need to search for the label which is less efficient. For user code, the advantage is smaller because the relative branches make a search in order to detect the long instructions (such as LBL'ABC') and count them only as a single step. For XROM, all the 'dirty work' is done by the assembler during compile.

So the command BSRF/BSRB nnn is equivalent to SKIP/BACK nnn, but returns to the following step at the next RTN!? Or in other words it works like a subroutine call XEQ (current linenumber +/- nnn), but with the advantage that you don't need a LBL for it and so the WP34s doesn't have to search for a LBL first!?

I hope I got it know ... ;-)


#45

Franz, you got it.

#46

Quote:
And I guess SHFL can arrange the stack in any order!? Well, with the 4 available stack exchange commands (x/y/z/t<->..) I don't really see any use for this exotic command.

SHFL doesn't just allow rearrangements of the stack. It can also duplicate stack levels. So e.g. you can rearrange [ X Y Z T ] into [ Z Y Y X ] using a single instruction (not that I can think of a use for that particular operation).

I added it back again because I noticed that the quadratic solver had a series of three consecutive stack manipulations and wanted to streamline that. I've also wanted a DROPY instruction on quite a few occasions and SHFL gives you this too [ X Y Z T ] -> [ X Z T T ].

I've not gone back an reworked all the existing code to use this instruction yet but will eventually.


- Pauli

#47

Quote:
CNVG? - A convergence test. Ask Pauli for details.

Better to look at the comment above the cmdconverged() function in xeq.c

The command allows you to check for the convergence of a series approximation. It permits a check for relative error, absolute error or complex distance against one of three threshold tolerances (or optionally, one of these three chosen base on the current mode settings).

It is proving to be quite a step saver in xrom, although the argument is a bit cryptic.


- Pauli


#48

Quote:
Better to look at the comment above the cmdconverged() function in xeq.c

Thanks, this CNVG? is indeed quite well documented there (but of course hard to remember for practical use).

The SHFL parameter is still not clear to me, but it seems to use a 8-bit structure (2 bits for each register)!? What I've not found out yet is the order (XXYYZZTT ?) and which value means to put which register content into which destination.

I'll have to read xrom.wp34s and xeq.c a bit more carefully ...

Franz

Edited: 9 Jan 2012, 3:43 p.m.


#49

Registers are numbered 0 for X through to 3 for T.

The argument is of the form (in binary):

          ttzzyyxx

where tt is the register to be placed into T, zz for Z etc.

Thus my earlier example of [ X Y Z T ] into [ Z Y Y X ] would require this binary pattern as the argument:

          00 01 01 10

I.e. SHFL 022

And DROP Y is SHFL 248.


In the xrom.wp34s file, a number of macros are defined to make accessing these commands easier from xrom. Not useful for user programs though, but they do indicate what goes where.


- Pauli


#50

Ahhh thanks, now everything is clear - again a very powerful command!

It's a pity that 2 bits can only hold 4 numbers, otherwise you could have included the value 0 for putting into any register (something like CLy or CLz).

BTW, this CNVG? would have been very useful in my polynomial rootsolver.

Franz


#51

Quote:
It's a pity that 2 bits can only hold 4 numbers, otherwise you could have included the value 0 for putting into any register (something like CLy or CLz).

I had an even more power version of this ages ago that got lost along the way. It included L as well and I did contemplate 0 as well. Still, it should be a useful if cryptic command.


Quote:
BTW, this CNVG? would have been very useful in my polynomial rootsolver.

Don't you mean "will be" :-)


- Pauli


#52

Quote:
Don't you mean "will be" :-)

Well, I've already thought about rewriting my PRS program (and even made a few subroutines for the new version), but it would be much work and I'm not sure if it would still fit into about 500 steps.

The problem is that I've written it in the old V2 style and used the top registers R80-99 for the main variables (like the old statistic functions). Moving down these registers to R00-19 isn't a problem, but moving up the polynomial coefficients 20 registers makes many commands (or better their parameters) much more complicated and would need some additional steps for these commands (like R-COPY/SWAP, loops etc.).

It would be great if there would be a mechanism in WP34s to define somewhere a special register, and this value should be automatically used as an offset to all other (or only to specified) register calls. Or something like defining a second register set Sxx starting with a special register number Rnn, but being addressed as S00.

Maybe I could solve my problem also with local registers (but 16 are not enough, would require using also A-D), but so far I'm not familiar with this 'local' stuff.

Franz

Edited: 9 Jan 2012, 5:07 p.m.


#53

It does sound like local registers are what you require here. Put a "LocR 16" at the start of the solver and then freely use registers .00 - .15 plus A - D throughout.

Leave the polynomial coefficients and order in exactly the same place they are now (i.e. registers 00 - 79) and there will be no conflict. You'd even gain another 20 registers for coefficients if the program was run from flash :-)


- Pauli


#54

Local registers are best suited to non interactive routines. As soon as you do an XEQ (or use a hot key) from the keyboard, the return stack is initialized and the local registers are gone. R/S is fine, though. So you should keep all data entered by the user in global registers and use locals for all the intermediate stuff which is used during the computation.


#55

Quote:
As soon as you do an XEQ (or use a hot key) from the keyboard, the return stack is initialized and the local registers are gone.

Yep, that's exactly another problem I already found when I thought about a new version - just forgot about it at the moment. :-(

There's in fact a problem because the PRS program uses XEQ 11/12/13 to edit/recalculate or display the solution again, and then the local regs are removed - damned, it's all not so easy ...

#56

Quote:
It does sound like local registers are what you require here. Put a "LocR 16" at the start of the solver and then freely use registers .00 - .15 plus A - D throughout.

Yes, that's what I was thinking about. And "LocR 16" does not reduce the user RAM (i.e. the registers R00-99) like loading a bigger program does?

I could even use this LocR twice, first in the main program and then again in the Laguerre subroutine, because they only share some of my 20 registers, so I could avoid using A-D.

Ok, let's see if I still have enough energy to rewrite my program, because I've already worked almost one month on it (reading certainly more than 30 articles and studying programs about efficient polynomial root solving methods, especially for multiple roots).

Franz


#57

Quote:
Yes, that's what I was thinking about. And "LocR 16" does not reduce the user RAM (i.e. the registers R00-99) like loading a bigger program does?

User RAM is divided in roughly 3 areas: Program/local data, global registers, and state.

You can shift the boundary between program/local data and the registers by executing a REGS command. If you have a long program in RAM and all global regs allocated then there will not be much headroom for local registers. For testing your program you should do a REGS 49 or something alike. When everything works, copy the program to the backup area or to the library and clear the RAM program to make room for more local registers. REGS can then be reset to 99.

Quote:
Ok, let's see if I still have enough energy to rewrite my program, because I've already worked almost one month on it (reading certainly more than 30 articles and studying programs about efficient polynomial root solving methods, especially for multiple roots).

Life long learning is the best method to keep your gray matter in good shape. :-)


Possibly Related Threads…
Thread Author Replies Views Last Post
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 1,248 10-04-2012, 04:59 PM
Last Post: Paul Dale
  CLUTILS for XROM #31 YFNS instead of YFNZ? Kerem Kapkin (Silicon Valley, CA) 4 1,734 06-05-2012, 01:43 PM
Last Post: Monte Dalrymple
  HP-35A/21 D.MS<-->Decimal degrees routines Matt Agajanian 9 2,998 03-29-2012, 11:03 AM
Last Post: Matt Agajanian
  accuracy of integration and solve routines HP 15C LE Jan 3 1,441 02-02-2012, 01:03 PM
Last Post: Marcus von Cube, Germany
  [wp34s] Incomplete Gamma on the wp34s Les Wright 18 5,350 12-06-2011, 11:07 AM
Last Post: Namir
  [wp34s] Romberg Integration on the wp34s Les Wright 2 1,520 12-04-2011, 10:49 PM
Last Post: Les Wright
  HP 34s: Three financial routines Miguel Toro 3 1,499 11-13-2011, 03:56 PM
Last Post: Miguel Toro
  Some 30b routines, revisited Harry Jacobson 4 1,704 10-11-2011, 08:20 PM
Last Post: Jeff O.
  Simple TVM Routines for HP-15C Chris McCormack 1 976 09-16-2011, 11:26 AM
Last Post: gene wright
  HP-41C Time Module: Calendar Routines Thomas Klemm 0 801 12-09-2010, 01:58 PM
Last Post: Thomas Klemm

Forum Jump: