Translating Code: (Hp50g)

[dant...@yahoo.com]

Hi Guys!
I need to have the equivalent code in System-RPL for the following:


I enter 2 Arguments on the stack:

2: 'Y=2*X-5'
1: 'X=3'
__________
then, this is the code I need translated into System-RPL language.
«
SUBST EVAL
»
__________
Finally get the result:
y=1

can somebody help me? please!

Thank you.

[DavidM]

If you're just needing to perform these functions from within a SysRPL secondary, you could always use the SysRPL equivalents of the UserRPL functions (xSUBST, xEVAL).

Is there some other functionality that you're needing that only SysRPL would provide? It's not clear from your question.

[dant...@yahoo.com]

Basically the functionality I´m looking for is: SPEED!
I need to insert the command SUBST(in System-RPL) into a User-RPL program, so it runs faster. maybe some kind of SYSEVAL, FLASEVAL or something like that. I'm not a System Programmer but I know that commands written in System run much faster than User's, that's why I asking for help.

[dant...@yahoo.com]

Besides... I Entered my 2 arguments, then xSUBST and nothing happens! how do I use these equivalents?

[Jacob Wall]

The only significant way to improve speed is to program this in a more
efficient way. What is the program used for? What are the expected
inputs and outputs, and could you provide a sample use?

> 2: 'Y=2*X-5'
> 1: 'X=3'

Well, for example to solve for 'Y', assuming that 'X' is a global variable

::
%2 ID X %* %5 %-
;

This is obviously very fast but may not be of any help because I don't
know if it fits into your intended usage.

Are you familiar with Nosy? http://www.hpcalc.org/details.php?id=7133
Amazing way to find out what the UserRPL commands are actually doing...

Jacob Wall

[dant...@yahoo.com]

this:

::
%2 ID X %* %5 %-
;

looks like chinese to me, I know is system code, I just don't understand it.
and "NOSY"... sorry I'm not familiar with it.
my program is very large and it does several evaluations like the one I mentioned before, trying to find intercepts for linear equations, these evaluations are pretty much recursive by other sub-programs, and the whole process gets quite slow. I was wondering maybe inserting a piece of System code would improve speed! perhaps not?

[DavidM]

There are several reasons that SysRPL programs can run faster than UserRPL, but a lot depends on where the actual bottlenecks are in your code. If the slowdowns result from your own data manipulations, then SysRPL may provide some noticeable improvements. If the most time-consuming parts are when the calc is running built-in functions and ROM routines, then you may not actually see much in the way of speed improvements since those will still execute at essentially the same speed.

One of the benefits of SysRPL is that you can bypass the inherent type-checking that most functions do when run at the UserRPL level. If you're certain that the stack arguments will always be of a specific type, you can bypass the type checking by jumping directly to the appropriate internal function to process the variables. Some of those functions are in fixed locations, and some aren't. It just depends on the specifics of what you're doing. This can be dangerous, though, if the vars end up being a different type than you expect. Unexpected results (at best) or system crashes can occur if this happens.

Jacob mentioned Nosy because that's a great way to determine what you may need to do on your specific calculator to jump directly into ROM routines for a given var type. But you have to know a bit about the way SysRPL works (especially the dispatch routines) for any of it to make sense.

I'm just guessing here, but it seems to me that you wouldn't see a significant speed increase in this application simply from bypassing the type dispatching that occurs with SUBST and EVAL. Other parts of your UserRPL code might benefit from a rewrite in SysRPL, though.

Given that the SysRPL secondary Jacob showed you didn't make much sense to you, I'd suggest that you might need to spend some time with a document such as this one to see what it's all about: http://www.hpcalc.org/details.php?id=5142 . That's a great place to start learning about SysRPL.

[dant...@yahoo.com]

My program is already finished. I was just wondering if I could speed it up a little bit, I'm not feeling like to learning a whole new and complicated language just to improve the speed aspect. I respect the System-RPL language, in fact I'd like to learn it. I've already tried to learn it a couple of times, and no success! specially when you're on your own. I'm not a formal programmer, I'm just a very passionate HP calculators Fan, I've done many programs(User-RPL only). some times mixed with some FLASHEVALS & SYSEVALS, and they have worked just fine!
So, I appreciate your help. but all I want is the equivalent of the SUBST command in System-RPL, assuming that there is 2 arguments on the stack, those arguments use only global variables and they will always do.

[John H Meyers]

On 12/4/2013 10:39 AM:

> My program is already finished.
> I was just wondering if I could speed it up a little bit

If your program is currently in UserRPL,
you can't "insert" SysRPL into it; you could
only insert some SYSEVAL, LIBEVAL, or FLASHEVAL commands,
all of which are themselves UserRPL commands which check arguments,
hence you won't even gain "argument checking time" from this.

It is also a misunderstanding to think that any command
which takes a long time to execute could be "speeded up"
by using its "supported" SysRPL entry point (if it has any)
in place of its UserRPL entry point -- all that you would
thereby save would be the argument checking time,
not the execution time for all the rest of the command.

The most significant savings for SysRPL programming
comes from using otherwise inaccessible internal functions
and structures which have no UserRPL analog,
plus some optimization of looping/branching
and local variable usage.

Within a pure SysRPL program, you can also call
user functions in such a manner as to suppress
saving their arguments (and name), which is another
very minor saving, and also necessary if the SysRPL program,
upon any error, wishes to back completely out
and to return to the stack
the original arguments which were passed to it,
rather than to stop where it called another function internally
and return those additional arguments to the stack
as of the middle of the SysRPL program.

> all I want is the equivalent of the SUBST command in System-RPL

So here is the entire SUBST command (for 49/50 series),
in SysRPL, from ROM, thanks to the "Nosy" library:

( ~xSUBST ROMPTR 314 2)
::
CK2&Dispatch
BINT4
FPTR 6 1D9=^FLAGLISTEXEC
BINT9
FPTR 6 1DA=^FLAGSYMBEXEC
BINT6
FPTR 6 1DB=^FLAGIDNTEXEC
BINT7
FPTR 6 1DB=^FLAGIDNTEXEC
;

Does that help you?

> assuming that there are 2 arguments on the stack,

> those arguments use only global variables

> and they will always [be on the stack, with correct type]

Let's be very careful -- "those arguments use only global variables"
does not mean that the last argument (level 1) is absolutely guaranteed
to be ONLY be a global variable NAME, does it?

If not, then you really need to use that entire function,
which invokes different FPTRs for different last argument type,
not just the last "flash pointer" (#1DB006h FLASHEVAL) for _only_
a global (type 6) or local (type 7) variable name on level 1.

For good measure, let's quote the AUR:

WARNING: Use extreme care when executing this function.
Using FLASHEVAL with random addresses [or arguments?]
will almost always cause a memory loss.
Do not use this function unless you know what you are doing.
[and back up your entire memory before even trying]

[r->] [OFF]

[dant...@yahoo.com]

Thanks for taking the time for answering my question!
You just made me realized about lots of things regarding to System-RPL code.
So, if SYSEVAL, LIBEVAL, and FLASHEVAL are User-RPL commands, that is what I really meant. I need one of those to insert into my User-RPL code.( I thought I needed the System code itself, but I realized I'm not!)

Checking out the (#1DB006h FLASHEVAL) pointer for global (type 6) and local (type 7) variable names , knowing that my 2 arguments are (type 9)... it just returns the message "No Solution Found".

by the way how can I built those SYSEVALS, LIBEVALS, and FLASHEVALS?

Dante,

[John H Meyers]

Let's first repeat the complete SysRPL ROM code
for xSUBST (the UserRPL SUBST command):

( ~xSUBST ROMPTR 314 2)
::
CK2&Dispatch
BINT4
FPTR 6 1D9=^FLAGLISTEXEC
BINT9
FPTR 6 1DA=^FLAGSYMBEXEC
BINT6
FPTR 6 1DB=^FLAGIDNTEXEC
BINT7
FPTR 6 1DB=^FLAGIDNTEXEC
;

On 12/4/2013 3:26 PM, Dante wrote:

> Checking out the (#1DB006h FLASHEVAL) pointer
> for global (type 6) and local (type 7) variable names,
> knowing that my 2 arguments are (type 9)...

STOP! -- a "type 9" (algebraic) object may _contain_
some local and/or global variable names,
as well as a bunch of other stuff,
but it is NOT the same type of object
as just _one isolated variable name_ (a/k/a ID),
so if you have called the function intended for
ID objects when the actual object was an algebraic
(composite) object, and your memory didn't get wiped out,
then count yourself lucky!

Although the CK2&Dispatch in the above
is making sure that at least two stack arguments exist,
it also matches object types against those BINTs
in the code above, which happen to be matched against
the type of only the level 1 argument,
to decide which "deeper" internal function to call.

A very compressed chart of those "object dispatch type codes"
(which need not match the return values of the UserRPL TYPE command,
although, by coincidence, some of them do) appears below,
in a program that I keep in my HOME directory
to display this chart on my own calculator (this fixed-width text,
exactly 33 characters per line, will look right only when displayed
in a fixed-width font, such as on the calc screen itself):

\<<
" Object Dispatch Type Codes

1 % 7 LAM D TAG 4F C%% AF LDT
2 C% 8 ::; E UNIT 5F L[] BF ACP
3 $ 9 ALG 0F ROMP 6F CHR CF FON
4 [] A SYC 1F # 7F COD DF MFO
5 {} B HXS 2F RRP 8F LIB EF EX4
6 ID C GRO 3F %% 9F BKP FF INT"
SCROLL \>> HOME 'TYC' STO

So we see that if your level 1 argument is type 9
(algebraic object), regardless of the type of level 2,
you should be invoking #1DA006h FLASHEVAL (^FLAGSYMBEXEC)
rather than #1DB006h FLASHEVAL (^FLAGIDNTEXEC)

If there is any chance that the type of level 1 argument
upon which you want SUBST to act is not absolutely always
guaranteed to be the same exact object type, then you should
abandon any thought of trying to replace SUBST by a single FLASHEVAL,
and just let the UserRPL SUBST command do its job, which is
to call the right inner function for each different object type,
as well as to abort on either too few arguments
or an unallowed object type on level 1 (CKn&Dispatch
also handles "automatic list processing," although this
is slightly outside the scope of our main lesson here).

> BTW, how can I build those SYSEVALS, LIBEVALS, and FLASHEVALS?

(SysRPL <-> UserRPL)
PTR <-> #address(h) SYSEVAL
ROMPTR <-> #LLLnnn(h) LIBEVAL
FPTR <-> #nnnbbb(h) FLASHEVAL

The Advanced User's Reference Manual (AUR)
is of course a bit more detailed than this,
and of course you also need to know
the argument values (ROM address, library#,
function#, flash bank#) for each command,
which you have to discover either in ROM,
or in a table of entry points such as
Joe Horn's cross-reference lists,
or in some book about SysRPL programming, etc.,
and if you publish or share anything, it had better
be "supported" or absolutely "stable" (i.e.
no variations whatsoever between ROM versions).

One past hero, however, whom we might think of
as "Admiral" (rather than Prof. Wolfgang) Rautenberg
was famous for saying "Damn the non-supported entry points,
full speed ahead!" -- and his resulting world-record setting
code has crashed in many a later ROM, but there's always been
someone around to update his libraries again for each new ROM,
so be thankful that there won't be any more of those ;-)

[r->] [OFF]

[dant...@yahoo.com]

That was amazing!
thanks for answering...
I better not to mess with stuff I don't really know!
I think I will just leave my program as it is right now. and start giving a try
learning this language(System-RPL). the thing is... that I don't know if its worth it, because of the launching of the New Hp Prime Graphing Calculator. perhaps HP will discontinue the HP50G, perhaps not! I've already started learning the "HP-PPL" and it seems to me it is a little easier than System though.

Dante,

[Virgil]

In article <e4f1ed72-382f-471e...@googlegroups.com>,

And http://www.hpcalc.org is a place from which you cha downnlaod "NosY"
and a whole raft of other HP 48/49/50 programs.

http://www.hpcalc.org is worthwhile browsing though at some length just
to see what it offers.
--