cancel
Teacher
Teacher
89 62 1 5
Message 1 of 3
316
Flag Post
HP Recommended

For what It's used Compiled Local Variables in HP 50g graphing calculator ?

HP 50g graphing calculator
Unknown

Hello dear HP Community , 

Here is one question that bothers me a lot --> For what situations , and how exactly I must use compiled local variables .

I made a simple program which calculates perimeter and area of triangle , and local variables , exactly compiled ones that i used was each of side in that triangle .

 

So , In order to understand how this program i read a book in which stands that compiles local variables are exactly gap between local and global variables , but i did not find any of use with compiled local variables .

 

This is a part from HP 50g Advanced User Manual which describes what exactly are compiled local variables , but I'm not agree with that text because in the text wrote that I can access compiled local variables from other program , but I don't realize how exactly i must make my program(s) for this purpose .

 

You can find text below ...HP_Support_Forum_Chapter_part.PNGThis is an explanation of compiled local variables ...

 

You can clearly see what is written in this text . 

So , I made programs which i described in the beginning .  This is my programs which i make ...

picture down below shows program which i realized 

Programs_whit_Compiled_Variables.PNG

Programs_whit_Compiled_Variables_Rounded.PNG

And i don't understand a purpose of compiled local variables because same thing , but much easier i get with (just) local variables . Ant altough i can't access compiled local variables from other program . I know that because When I enter code like that ( down below ) in the picture ...

Succesfull_code.PNGThis is an successful example ... of my code which used compile local variables

but when i type this code below , In expectation that it should work nice and easy like code above , i get some sort of error .

Let me explain you better , but first look at the code below ( picture ) 

Picture_second_code.pngthis is a second code

but when i type numbers , and when i use this code i get this ,

my numbers ...

Code_numbers_second_code.pngmy numbers

when i used code before last picture ( upper picture with numbers  ) , i get this ...

Code_numbers_second_code_error.png

but when i used same numbers 8 , 6 and 10 with code described down below 

Code_numbers_first_code.png

When i enter my numbers i got exact answer ....

like this ...

Code_numbers_first_code_successful.png 

 

That sounds , for me , that compiled local variables are more like standard local variables in HP 50g graphing calculator , not else or more . 

If someone had a better example in which i can clearly made a distinction between local variables and compiled local variables , I'll be very grateful , because I don't get it , which is the difference between these two .variables types , because i expected that my code will works nice and easy with both examples which i shown in this forum 🤔

 

Thanks for your help ,

 

Best regards ,

 

Josip Kova 

 

2 REPLIES 2
Grad Student
Grad Student
124 118 22 45
Message 2 of 3
279
Flag Post
HP Recommended

For what It's used Compiled Local Variables in HP 50g graphing calculator ?

Short Answer:

 

You use compiled local variables in both the calling and called programs any time you need to use locals in the called program that were originally instantiated in the calling program.

 

Simple, right? 🙂

 

Uhm, Longer Answer:

 

This is definitely an advanced topic, and it tends to cause a lot of confusion. To better understand compiled local variables, it helps to have a basic understanding of what happens when you create or edit a UserRPL program after you press the ENTER key.

 

Whenever you edit a UserRPL program on your 50g, you are essentially manipulating the code as a string of characters (similar to a text file on a computer). You add or delete characters as needed, and sometimes the editor helps you by spelling out command names and adding spaces around commands automatically. Once you are done editing, you generally press the ENTER key to place the completed program on the stack.

 

It appears that pressing the ENTER key simply puts that long string of characters on the stack more-or-less as you entered it, but that's not what actually happens. Pressing ENTER sends the temporary string that you are editing off to a special routine in ROM that parses it and compiles it into an executable code object. The program looks much the same on the stack, but only because there's also a reverse process that converts the compiled code into a readable string for display. There's an easy way to show this compilation/decompilation in action: enter the following simple program on your calculator and watch what happens when you press the ENTER key:

 

« 123 @ FOO BAR »

 

(the '@' symbol can be typed on the 50g keyboard by first being in alpha mode and then pressing right-shift followed by ENTER)

 

After pressing ENTER, the "@ FOO BAR" part disappears. Why does this happen? As you're probably already aware, the "@" symbol in a UserRPL program signifies the start of a comment. When the edited program is passed to the compiler, the "@" symbol (and everything after it up to the closing bracket) is ignored, and thus generates no executable code in the final code object. This is basically what all compilers do with comments. An executable program is created by the compiler for everything other than the comment, which is then left as an object on the stack. After that compilation has completed, the O/S executes a decompiler to show the program in text form on the stack. Since the comment was stripped out by the compiler, there's no comment included when the program is decompiled for displaying on the stack.

 

By now you're thinking "ok, but what's all this got to do with compiled local variables?" The answer to that question is "a lot!". There's actually two completely different types of variable identifiers that UserRPL programs can use: global and local. While they may look similar when we edit our programs (strings of letters with or without single quotes depending on the situation), they are compiled into two completely different types of objects by the compiler. The compiler "knows" which type of identifier to use based on the context of where it is used in a program. If the identifier is one of the names listed in a previous local assignment structure (ie. immediately following the "" token), then the compiler knows to create a local identifier instead of a global one. If the identifier hasn't been used in a local structure yet in the current program, then it is compiled into a global identifier instead. The compiler only looks in the current program to make this determination, since different programs are free to use the same identifiers in whatever way they choose.

 

In a running program, the distinction between global and local identifiers is extremely important. The objects referenced by these identifiers reside in entirely different segments of memory, so the way they are tracked down by the O/S when encountered is very different. They are not interchangeable, and the O/S will not look in both places if it failed to find the object referenced by an ID in the assigned space. By default, identifiers are assumed to be global by the compiler unless they are explicitly designated as local by their context.

 

This finally brings us to compiled local variables. At some point in time, the RPL developers decided that it would be good to have a way to force the compiler to treat an ID as local, even if there was no local structure that designated it that way in the current program. The method they chose was to use a naming convention that signals the compiler to always generate a local ID reference whenever the name begins with the "←" character. That prefixed character essentially forces the compiler to treat that ID as a local variable, even if there is no apparent reason to do so in the current context.

 

Consider the following two programs:

 

« a b »
« a ←b »

 

 

Here's the decompiled versions for both (decompiled to SysRPL):

 

::
   x<<
   ID a
   ID b
   x>>
;

::
   x<<
   ID a
   LAM ←b
   x>>
;

 

 

Note that neither program has a local variable structure in it. By default, the two identifiers are compiled into global identifiers in the first version (ID a and ID b). Adding the "←" prefix to the second identifier in the second example forces the compiler to generate a local (LAM) reference instead of a global (ID) one. This means that, when executed, the second program will look in the locals area of memory for the variable instead of the globals.

 

So now let's put this to use:

 

CLV1
«
   1 → a
   «
      a
      1. →LIST

      2 → ←b
      «
         a ←b
         2. →LIST

         CLV2
         2. →LIST
      »
   »
»

CLV2
« a ←b »

 

 

Run the program CLV1 and note the output. You should see the following (assumes exact mode, and that no global named 'a' already exists):

 

3:    { 1 }
2:  { 1 2 }
1:  { a 2 }

 

 

The first list contains the value of a, which is a local which was assigned at the very beginning of the program. The second list contains both values assigned to the two locals a and ←b, since they are both "in scope" for that part of the code.

 

The third list is the most interesting one (IMHO). Both locals a and ←b are defined and "in scope" when that program is run, so why is there only one local variable available when CLV2 is run? Hint: it's a "trick" question.

 

The answer has already been given in the above description of the decompiled version of that exact same program. When the CLV2 program was originally created, there was no local named 'a' in the program. So the compiler created a reference for a global named 'a' instead. Presuming that you don't already have a global named 'a', the result of executing that code is to simply leave the global ID name ('a') on the stack, and then to dereference '←b' as a local (which is defined at that point).  That's why that last output happens the way it does.

 

As I mentioned above, this is a complicated concept. 🙂

Reply
0 Kudos
Tags (2)
Distinguished Professor
Distinguished Professor
3,671 3,396 171 517
Message 3 of 3
247
Flag Post
HP Recommended

For what It's used Compiled Local Variables in HP 50g graphing calculator ?

Hi!, @JKova :

You can only use complied local variables for call created global variables, without necessity of write in each step the total program of global variable, for call these.

Reply
0 Kudos
† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation