A design rule for WP34s library software? - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: A design rule for WP34s library software? (/thread-190612.html) |
A design rule for WP34s library software? - Dieter - 08-14-2011 The recent discussions on various software to be included in the WP34s library show that there are certain rules and limitations that need to (or at least should) be concerned. So I think it's a good idea if there was something like a standard for such software, a kind of programmer's guide. This might include the following topics and more:
I am sure this is not a complete list. ;-)
Dieter
Re: A design rule for WP34s library software? - Walter B - 08-14-2011 Thanks for raising this topic. There are no standards yet, but the following may form the base for a discussion here: Quote:All of them have a specific use: please see the first page about "Memory" in the manual. So I don't recommend using these nor the ones employed for statistics if you want to avoid interfering with such commands. Beyond those, feel free to chose whatever registers you like. I think it's good practice to document them in the program header. Quote:No user flags but the lettered ones have a specified meaning so far. So here the door is wide open for you. Enjoy (but document)! Quote:Depends. I'd vote for some cleanup at the end of a routine. E.g. if a routine uses X, Y, and Z for input and X and Y for output, then it shall work in a 4-level stack like shown below: Stack level Content at start ... at endI leave it as an exercise to transfer this to an 8-level stack ;-) Remember the commands STOS and RCLS. Quote:I concur. STOM and RCLM will help in hosekeeping. Quote:I can't force anybody to document what (s)he does in his/her routine, but I'd welcome documenting registers and flags used as well as input and output. With the housekeeping suggested above, nothing more will be necessary IMHO. What do you think?
Walter
Re: A design rule for WP34s library software? - fhub - 08-14-2011 Quote:At least for register "J" I haven't seen any usage yet, so this should be safe as scratch register. Edited: 14 Aug 2011, 3:51 p.m.
Re: A design rule for WP34s library software? - Walter B - 08-14-2011 Quote:Not my fault ;-) Please read said page again 8-) Re: A design rule for WP34s library software? - fhub - 08-14-2011 Quote:Well dear Walter, I'm quite sure that register J was NOT mentioned as being used for statistical calculations in former manual versions - that's the 1st point.
And the 2nd point is that you yourself suggest "Unless required for the purposes just mentioned, A-D,I,J and K are available as additional general purpose registers." If I'm sure to be in SSIZE4 mode (or switch to this mode) in a program, I absolutely see no reason to NOT use any of these 'upperstack' registers A-D - they can be perfectly used e.g. as a backup of the usual X-T stack.
Waiting for your next disagreement ... ;-)
Re: A design rule for WP34s library software? - Walter B - 08-14-2011 Franz, Quote:You're right: J wasn't mentioned this way before v1.11. Who gets the first point now? ;-) Quote:May I quote myself? I wrote in message #2 above: I don't recommend using these nor the ones employed for statistics if you want to avoid interfering with such commands. So if you want to interfere feel free to use them. But don't expect me appreciating that. Re: A design rule for WP34s library software? - fhub - 08-14-2011 Quote:Well, I also have quoted you - with exactly the words you use in your manual.
So do we have 2 Walters here, a 'forum Walter' and a 'manual Walter'?
Re: A design rule for WP34s library software? - Walter B - 08-14-2011 IMHO both statements are not contradicting each other :-)
(I'm willing to explain this on request, but am confident you won't need it after reading carefully.)
Re: A design rule for WP34s library software? - Paul Dale - 08-14-2011 The recent discussions were for code in xrom which is a very different beast to a library. Code there cannot touch the user's state and must preserve modes and stack -- xrom exists to implement commands that, to the user, appear exactly like internal ones. Libraries, on the other hand, are far less restricted. Basically, so long as what the function does and what resources it uses is documented I don't see a problem. Still, it would be nice to avoid using the lettered registers and flags and the statistical registers -- you as a library writer don't know what the user is doing.
Re: A design rule for WP34s library software? - Marcus von Cube, Germany - 08-15-2011 I think losing the stack isn't an issue for some 'large scale' applications. If you just create a useful subroutine of sorts it should more or less look like an internal command, even if it needs additional registers to do its work. Stack size is very much a matter of user preference and a routine or application should only change it if absolutely necessary. The user interface of the VEC application starts with a SSIZE8 command for good reasons and a matrix program may opt for inputing the rows or columns of a matrix via the stack which makes an appropriate stack size mandatory. I don't see a way to restore the user preference because an interactive application does not have complete control all of the time.
OTH, a library routine that needs a specific stack size to operate should make use of STOM and RCLM. The latter routines are designed to directly transfer the state from and to a register and don't interfere with the stack contents.
Re: A design rule for WP34s library software? - Paul Dale - 08-15-2011 I can't disagree with any of this. A library is a library and can do anything. However, XROM isn't a library, it must look exactly like internal commands.
|