functions vs. programs (and modules)

Programs for HP-41

functions vs. programs (and modules)

Postby Jordan Orlando » Tue Apr 13, 2021 5:55 pm

I'm a new 41C owner, and I have a basic question about HP's general programming scheme.

As I understand the evolution of HP calculators:

1) The HP 9100A onward had functions, available via dedicated keys (or with shift keys)

2) User-written programs were built from sequences of those functions (and other actions, including branching logic; conditionals; flags etc.) and then stored in memory or on magnetic media — the larger cards for the 9100A; the smaller cards for the HP 65, HP 67 and HP 97

3) The interchangeable card format allowed HP to release "pacs" of various programs (of different levels of sophistication) so the calculators could perform specialized routines.

Here's where the taxonomy gets tricky. As far as I understand, the early programmable HP calculators of this era allowed several user programs to occupy memory — you executed the one you wanted by knowing where it was in the numbered series of all registers. But running the program you had loaded from a card, just meant pressing "execute" — once you'd loaded (say) a surveying program off a single card, you didn't have to tell an HP 67 which program to run; you just said "XEQ" (or whatever the key is on that machine) and it ran the loaded program from the card, right?

Anyway with the 41C, the scheme changes, because of two technical innovations:

4) First, because of the alphanumeric interface, programs (and functions) are retrievable by name — the keyboard no longer has to show every function; there are now dozens of them, available by means of their names (and you get a convenient catalog).

5) Second, replacing the card reader with Atari-like ROM cartridges means that, rather than buying a "pac" of dozens of cards, you buy a single "module" with many programs on it, accessible by name, just like the functions on the calculator.

And here's where I get fundamentally confused, unfortunately. Because the distinction between "functions" — built-in actions that manipulate data in single steps, executed by name — and "programs" — sequences of those steps, including functions — is suddenly confusing.

With the 67/97, you would get a card, and load the program into memory. Then you could single-step it, and (presumably) edit it, creating your own version that you'd save on your own card, or rewriting over the card version (if you were running your own, user-authored program from a non-copy-protected card). But there was one program; there was no ambiguity about what you meant when you went into "PROGRAM" mode and said "SST" or whatever: you were referring to "the" program that you'd loaded. (I apologize for my fuzzy understanding of how the cards worked; I don't have one of those machines.)

But suppose there's a specific program on a module, and you want to see how it works, or re-write it, or just read its lines (as you could in the days when those programs were sold by HP as text in books that you'd enter yourself). As far as I can tell, the only action you can perform on a program running from a ROM module is to "XEQ" it — exactly as if it was a function. In fact, with the exception of the user-created programs in the machine's non-volatile memory, the programs for the 41C seem to be totally opaque and impenetrable: they may as well be functions, since all you can do is "XEQ" them, like functions.

So — unless I'm misunderstanding something — the 41C doesn't distinguish, functionally, between built-in "functions" and module-based programs. Whether they're some internal microcode-based routine (like SIN or LOG) or a series of CORDIS-based steps and logic, from the user perspective it's all the same: just "XEQ" and provide the name of the function/program. You can't do anything else.

(I realize you can interrupt a program and go through it step by step, or even see the steps...but you can't do that unless you're executing the program; you can't see or edit the steps of an arbitary module-based program unless the program is executing.)

Obviously you can't edit a program that's running off a ROM cartridge...but can you read it? Can you load it into "your own" RAM (on the machine or in a memory module), creating an editable copy — even if it's just so you can go into "program" mode and see what makes that program tick?*

Apologies if I'm being long-winded, or obtuse. Thanks in advance for the patience to address this, if anyone's kind enough to clear up my "newbie" confusion.

Jordan
Jordan Orlando
......
......
 
Posts: 28
Joined: Sun Apr 04, 2021 11:16 am

Re: functions vs. programs (and modules)

Postby mike-stgt » Thu Apr 15, 2021 10:24 am

i) tl;dr
ii) by glance through I guess your question, my answer: the HP41 is not a von Neumann architecture machine. RAM is built by bytes, firmware (in ROM only) has 10-bit words.
For more details see the ZENROM Usr Mnl on Warren's free archive DVD.

AFAIK, only the HP41 CR may use cards from HP67/97, no interchange between other models possible -- but I am not too sure.
If you have no ancient models at hand there are plenty to use virtually from http://teenix.org/

M.
mike-stgt
.........
.........
 
Posts: 179
Joined: Tue Dec 24, 2019 12:12 pm

Re: functions vs. programs (and modules)

Postby Jordan Orlando » Thu Apr 15, 2021 10:33 am

mike-stgt wrote:i) tl;dr
ii) by glance through I guess your question, my answer: the HP41 is not a von Neumann architecture machine. RAM is built by bytes, firmware (in ROM only) has 10-bit words.
For more details see the ZENROM Usr Mnl on Warren's free archive DVD.

AFAIK, only the HP41 CR may use cards from HP67/97, no interchange between other models possible -- but I am not too sure.
If you have no ancient models at hand there are plenty to use virtually from http://teenix.org/

M.


Thanks for responding. Apologies for the "wall of text."

Short version: if a program is on a module — not manually entered into registers — can I load it into RAM and edit it?
Jordan Orlando
......
......
 
Posts: 28
Joined: Sun Apr 04, 2021 11:16 am

Re: functions vs. programs (and modules)

Postby mike-stgt » Thu Apr 15, 2021 11:11 am

Short answer: yes.
Advice: RTFM
Hint: try COPY

/M.
mike-stgt
.........
.........
 
Posts: 179
Joined: Tue Dec 24, 2019 12:12 pm

Re: functions vs. programs (and modules)

Postby Jordan Orlando » Thu Apr 15, 2021 6:22 pm

mike-stgt wrote:Short answer: yes.
Advice: RTFM
Hint: try COPY

/M.


Thanks again.

I was scouring through the manual and somehow missed that part. (I was distracted by my understanding of the 65/67/97 and how they seem to always load programs into memory from storage — those programs obviously couldn't run off cards, the way the can run directly from ROM modules — especially the ones that took two or more card swipes to read.)

Next question: since "XEQ" doesn't distinguish between functions (built into the calculator's intrinsic logic) and programs (from user memory or from modules)*, can entire programs be called from within other programs, the way functions are called? (The equivalent of modern OOP calling of methods and other objects.) If I can write a program that includes (say) ARCTAN — a built-in function that I otherwise invoke by pressing "XEQ" [ALPHA] "ARCTAN," can I do the same thing with the name of a program from a module or from memory? (The manual discusses subroutines but isn't clear on this.)

*I assume that the only functions (meaning, one-step actions like "P->R" or "SIN") available are the ones intrinsic to the calculator itself — that an HP module can provide new programs — built from that limited number of existing functions — but not new functions, correct?

Thanks again for your help!
Jordan
Jordan Orlando
......
......
 
Posts: 28
Joined: Sun Apr 04, 2021 11:16 am

Re: functions vs. programs (and modules)

Postby Garth » Thu Apr 15, 2021 6:58 pm

Mike knows the innards much better than I, but I'll make this comment anyway. It's not clear whether you understand that modules contain new functions written in MCode, not just user-language programs. For example, if, in PRGM mode, I enter C/ which is the complex-number divide user-language subroutine in the Advantage module, the display will show XX XROM┬C/ (but raise the ┬ to be the tiny superscript "T," and replace the XX with the program step number); but if I enter the Z/ complex-number divide function written in MCode in Angel's 41z module, the display will show simply XX Z/. I don't think I've tested the speed of this one in particular, but the complex-number functions in Angel's module that replace the ones in the Advantage module seem to generally be about ten times as fast (and his module has far more functions than the Advantage module does). The Advantage module does have MCode functions too though, like the ROTXY (do a 32-bit bitwise rotate of the number in the Y register by the number of bits given in the X register, which is one of the Boolean functions in the module). If I enter this one in a program, the display will only show the ROTXY, without any mention of "XROM," because it's not a user-language subroutine.
Garth
Moderator
Moderator
 
Posts: 290
Joined: Tue Jan 20, 2009 1:31 am

Re: functions vs. programs (and modules)

Postby Jordan Orlando » Thu Apr 15, 2021 7:06 pm

Garth wrote:Mike knows the innards much better than I, but I'll make this comment anyway. It's not clear whether you understand that modules contain new functions written in MCode, not just user-language programs. For example, if, in PRGM mode, I enter C/ which is the complex-number divide user-language subroutine in the Advantage module, the display will show XX XROM┬C/ (but raise the ┬ to be the tiny superscript "T," and replace the XX with the program step number); but if I enter the Z/ complex-number divide function written in MCode in Angel's 41z module, the display will show simply XX Z/. I don't think I've tested the speed of this one in particular, but the complex-number functions in Angel's module that replace the ones in the Advantage module seem to generally be about ten times as fast (and his module has far more functions than the Advantage module does). The Advantage module does have MCode functions too though, like the ROTXY (do a 32-bit bitwise rotate of the number in the Y register by the number of bits given in the X register, which is one of the Boolean functions in the module). If I enter this one in a program, the display will only show the ROTXY, without any mention of "XROM," because it's not a user-language subroutine.


Yes, thank you — this is exactly the kind of fine distinction I was trying to understand (with my initial, long-winded post): distinguishing between functions and programs (as my subject line stated it out).

The manuals never mention MCode. (Why should they? You can use the machine to its fullest without knowing about it.) But I could immediately tell, once I'd gotten my own 41C and some modules and started experimenting, that the long lists of available "functions" (via dedicated keys or via "XEQ") and the "programs" (mine or HPs, or users' programs on distributed new modules or via other interface methods) that can be invoked by the same "XEQ" actions, were two very different things. The existence of MCode (this is, I'm embarrassed to admit, the first I've heard of it) clears up a great deal of this mystery. Thanks again.
Jordan Orlando
......
......
 
Posts: 28
Joined: Sun Apr 04, 2021 11:16 am


Return to HP-41 Software

Who is online

Users browsing this forum: No registered users and 1 guest

cron