akcs.scotty@hpcvbbs.UUCP (SCOTTY THOMPSON) (05/13/91)
A painstaking attempt was made to convert my ECHR library from user RPL to internal RPL. I spent over a week and went through two bottles of MOTRIN! Needless to say, just when I was about to give-up (my last attempt), the screen popped-up and the damn thing worked! Were all of those hours and headaches worth it? NO, NO, NO! A couple of notes for those trying to hack with internal routines instead: 1> I didn't want to change the code from its tested and beaten path (a program that worked...) so my attempt was to simply (ha) convert to the internal routines. I ran into major problems with the IF, THEN, ELSE, etc. statements. I was trying to use the internal routines (even saving the tokens), but it would never work. Impossible to debug with SST because all ya see are "External, External..." I think my biggest problem is that I didn't put the ML token save routine with the internal then routine inside D9D20...B2130. If using if...THEN...ELSE, then the portions of code (unless 1 token) between the THEN...ELSE and/or ELSE...END must be enclosed in D9D20...B2130 to work properly. E.g., 3CE22 [IF] 9C2A2 [1] AFE22 [THEN] D9D20 [;Program] 88130 [DUP] 339201000000000000550 [55] B2130 [;End Program] 5BF22 [ELSE] B9F06 [;Drop Level 2 Object] 5DF22 [END] 2> CASE statements should be blocked like: D8732 [CASE] D9D20 [;Program] ..... [CASE TESTS...] 8A732 [THEN] D9D20 ..... [THEN COMMANDS...] B2130 5DF22 [END] ..... [CASE TESTS...] 8A732 [THEN] D9D20 ..... [THEN COMMANDS] B2130 5DF22 [END B2130 [CASE OTHERWISE TERMINATION] 5DF22 [END] Brass tacks are brass tacks...My problems were I wasn't putting the D9D20...B2130 program delimiters to identify each "chunk" as a token. I guess these are equivalent to IFT/IFTE statements... Again, was it worth it? NO. I see no super-noticable speed increases when using the internal routines or just plain vanilla RPL (what do you think I prefer now?). Maybe 5-10% increase. It would appear to me that M/L is the only way to really speed-up programs, that internal routines should only be called when a function is available internally not otherwise accessible or for simple header routines, and that I will never do that again...
Jake-S@cup.portal.com (Jake G Schwartz) (05/18/91)
Scotty Thompson comments on experiences converting user code to internal RPL: > Again, was it worth it? NO. I see no super-noticable speed increases > when using the internal routines or just plain vanilla RPL (what do you > think I prefer now?). Maybe 5-10% increase. > It would appear to me that M/L is the only way to really speed-up > programs, that internal routines should only be called when a function is > available internally not otherwise accessible or for simple header > routines, and that I will never do that again... That's funny, because when I converted some of my stuff, not only was the resulting code HALF as large, it ran FIVE TIMES as fast. I manipulated many numerical integers as System Binaries as opposed to reals, and utilized the True/False "externals" in place of the 1/0 reals as well. In addition, single-stepping the stuff was okay when using Rick Grevelle's HACKIT material, since you can convert any token in stack level one immediately to it's ASCII equivalent with ->ASCI and back again with ASCI->. All the speed increase seems to be gained when using those internal data types. And machine code would probably have speeded it up perhaps another five times, but manual stack manipulation is a bit too much for me yet. Jake Schwartz