HP 50g Programming Methods???

[DavidM]

(11-05-2017 06:07 AM)Carsen Wrote:  One last question. Is Assembly different from System RPL?

Yes, very different. There's two different types of assembly on a 50g (Saturn and ARM), but when you see the term tossed about it is usually referencing the Saturn variety. That's what I'll focus on here.

Assembly programs are the closest representation of code to what the CPU actually processes at its lowest level (which is sometimes called "machine code"). In the case of Saturn assembly on a 50g, the O/S of the calculator emulates an enhanced Saturn CPU; the physical CPU is an ARM processor, but the Saturn machine code is interpreted and processed by the O/S as if it were an enhanced Saturn CPU instead.

Writing assembly programs requires a detailed understanding of many important aspects of the targeted environment. Exact data formats, addresses of important subroutines and O/S variables, standards for how "upper level" processes work and their protocols, etc. are all critically important.

Each UserRPL command you use in a program can be "traced" to a subroutine of some kind, which is usually a SysRPL subroutine. Each SysRPL command can be similarly traced to either more SysRPL commands or, ultimately, to Saturn code. And sometimes, these "levels" are skipped or restarted in the chain of commands.

To get a taste of how this works, consider the User RPL command "DROP" (which internally goes by the name of "xDROP"). It's a relatively simple function, right? All it does is to remove the object in stack level 1, and all other objects shift down in position to "fill the void" left by that action.

The UserRPL DROP command is actually a call to a SysRPL subroutine:

Code:

xDROP
::
  CK1
  DROP
;

The :: and ; are similar in function to the « and » you use in UserRPL. CK1 actually does quite a bit, but for now I'll just highlight that it makes sure there's already something to drop before proceeding. This is critical for the reasons mentioned in previous posts. Without that check, the following SysRPL DROP command would charge ahead making the required low-level changes to the RPL environment assuming that it was OK to do so. If that SysRPL DROP was executed with nothing on stack, it would set up a pending failure that shows up as soon as you (or more specifically some other command) tries to add something else to the stack. And it's a major, data-loss-assured crash.

So if something is on the stack to be dropped, what happens then? Well, the SysRPL DROP immediately jumps to a series of Saturn steps:

Code:

D1+5
D=D+1  A 
A=DAT0  A 
D0+5
PC=(A)

Knowing exactly what those steps are doing isn't important here, but suffice it to say that the only reason they achieve the intended purpose is because of how the RPL environment is designed to operate. The CPU doesn't "know" anything at all about the user stack -- none of those steps actually destroy stack data or move all of the other stack objects into new positions. They work only because of how the RPL environment is designed to operate, and the programmer who wrote them could only do it from knowing the low-level aspects of how stack data is organized in memory and processed, and the proper way to jump back to "regular RPL stream processing". Those are meaningless concepts to the CPU, and are simply designed by convention into the RPL operating environment.

Those 5 Saturn steps operate at the lowest level achievable for the emulated Saturn processor on the 50g. As such, they are very fast. DROP is actually one of the fastest commands you can execute on the calculator. It's difficult to time just those steps, but you can measure the UserRPL DROP command fairly easily -- it's about 8ms on my 50g.

Finally, assembly programs take up a lot of space. While the above example is actually fairly small, that's not the norm. It's not so much that the individual steps take more memory than individual steps in higher-level languages, but rather that it takes many more individual steps to do even simple things in assembly.

An analogy that may help to clarify this: imagine that you (as the programmer) are giving instructions to a programmable robot to move a box from one spot to another. Using a "high level language" (such as UserRPL), you might say "move the blue box from point A to point B". The robot will ultimately translate that statement into a myriad of individual steps that will achieve the goal. That translation will take some time, but it's easy and simple to deliver such a short message.

Now imagine that you want to achieve the same goal, but instead of the short message above you have to deliver each and every detailed step of how to perform that function to the robot:
- set orientation change to -12 degrees
- activate rotational position motors
- set distance counter to 6 feet
- activate forward motion motors
- raise left arm 12 inches
- raise right arm 12 inches
- set distance counter to 1 foot
- activate forward motion motors
...

The robot wouldn't need to do much translating of those steps, so it could execute them quickly after receiving them. But the quantity of steps needed to achieve the same goal goes up exponentially. That's why assembly programs tend to be larger -- there's a lot more highly detailed steps to be done at that level.

Once again, a long answer. But the salient points here:
- All code executed on the 50g is ultimately machine code, but there's multiple "layers" to go through before it gets to that point.
- There exists a hierarchy of code environments, and assembly is at the bottom (or more accurately "just above the bottom").
- Writing assembly code requires detailed knowledge (and access to a wealth of technical documentation) about the targeted environment.
- Assembly programs will generally be the fastest available for a given CPU.
- Assembly programs are usually larger than their higher-level counterparts.

My intent here is not to scare you away from any of this, but rather to give you an idea of the scope of what's ahead of you. Many people have successfully gone through this learning process, and the early adopters didn't even have the benefit of the wealth of information which now exists for doing this sort of thing. Your decision to start with UserRPL is a wise one, and will pay off in the long run.