HP 48 Series -- interseries compatibility?

[johnb]

(11-27-2023 11:17 AM)DavidM Wrote:  

(11-26-2023 11:44 PM)johnb Wrote:  ...I can go to LIBRARY and then to GX and use the routines directly, but after I (attempt to?) attach it to HOME, and then load other routines that use these functions, the other routines seem to be tripping all over themselves... and they worked correctly with the Meyers functions.

Are the "other routines" you refer to being restored onto the calculator as binary objects? There could be a subtlety here that is creating this confusing scenario.

First, bear in mind that numbers, programs, lists, arrays, etc. are always stored as compiled objects on your calculator (unless you specifically enclose the commands in "..." quotes). The calculator goes out of its way to hide this fact from you. [...more elided...]

This was EXACTLY the information I needed, thanks!

Actually, the "other routines" are my own routines, written in UserRPL on the 48g, saved as ASCII, then downloaded onto the 48s, also as ASCII. But the library is binary!

BTW, this is something I have trouble explaining to nontechnical people when troubleshooting minor technical issues: the more adequately accurate and detailed your mental model is of what is going on behind the scenes, the easier it is to have a go at it! Clearly, my mental model has some gaps and in some places is just plain wrong.

The surprising thing was learning when the calculator chooses to compile program objects and fix up references. Apparently, if the "bottommost" routines are loaded as ASCII objects (such as Meyers' UserRPL implementations of some of the GX-only LIST routines for the SX), when you load your own UserRPL objects (also as ASCII), it does a text-based lookup when it doesn't recognize a program name as a built-in. It does this on every run, so it's a little slower than it could be.

But, in this new case, the "bottommost" routines were loaded as binary objects in a library... then stored to Port-0 (the only port for me, this is a 48s, not an SX). Then, even though my own routines were loaded on top as ASCII objects just as before, the loading process did NOT cause a compilation of the code -- as I'd previously thought would happen.

I did a little reading in Wickes' book, and saw that for binary libraries, the compilation process replaces the name of the subroutine with a pointer to the library routines and/or built-in routines. This is why calls to binary libraries run faster: no lookups at runtime.

The simple fix-up for me was a bit tedious but quick enough. Just go through each of my directories off HOME (including it), and one-by-one, recall a program onto the stack, recall its name onto the stack, then STO. Voilá! Recompiled!