HP-41CX Compiled GTO's and XEQ's


Recently while thumbing through the PPC Journal, I have come accross several programs to compile these GTO's and XEQ's. Once they are compiled what is the best method to get them from X to the specific location in program memory? "Synthetic Programming Made Easy' has the program 'LBX' but I think that once you delete all of the '+' in the program it will uncompile the GTO correct? Please assist me if you can.


You must have your program ready and tested that for sure you will not need to do any changes in future. Next print it out and delete all local labels you do not need for manual start of a routine. Pack it. Calculate the new distances for GTO and XEQ. Take care of 2- or 3-byte GTOs according to the distance. Due to the deletion of labels there may be some GTOs that change from long form to the short form, others may need to be the long (3 byte) form.
Now "compile" all GTO and XEQ manualy. Take meassures that your program will never be decompiled (make it PRIVATE).

Now re-think the process: How long will this procedure take? How often was your program de-compiled and how long did it take the HP-41 compiled all GTO and XEQ? Now compare the time spent and the time gained (but don't forgett the "fun-factor" for the time you'll spend)

Ciao.....Mike ;-)


Hi, Mike;

I read Jeff's post and wondered about it. I read yours and I think I did not understand the doubt.

Is there a way to "compile" a program, i.e., to compute and record the distances from GTO's and XEQ's to their respective LBL's and keep this information? I know taht if you execute a [GTO][.][.] and the program is packed as a consequence of it, all of this information is erased. If the program already has an END as the last instruction (say, if you put it there manualy with a [XEQ][ALPHA] END [ALPHA] instead of a [GTO][.][.]) and you execute it, all EXECUTED GTO's and LBL's are compiled. But if you pack memory for any reason, this information is lost.

My doubt goes further when I think of those GTO's or XEQ's that are executed only in certain conditions and these conditions are not reached when running the program. Two questions:
- it seems that 'LBX' program mentioned by Jeff will compile thess not-executed jumps, what is an important fact, indeed
- manualy positioning the calculator on each not-executed GTO or XEQ and executing a single [SST] in RUN mode would also compile that specific GTO or XEQ? I think it will, but I'd like to know if it is a fact or a simple guess.

I would like to know more about the fact a PRIVATE program is not decompiled. Even if it is read form a card or X-Memory? I was not aware about that... Interesting!

All of the compilation process is lost when a program is changed or recorded somewhere and brought back to main memory, say, if it stays in main memory and it's unchanged, the compilation data is kept untouched. Or if it is recorded in ROM'what demands the compilation of all GTO's and XEQ's, isn't it?

Best regards.

Luiz C. Vieira - Brazil


Thank you for your responses. I have been trying to figure out the programs "EN", "XQ", "G3", "G2" from the PPC Journal V14N2. When these programs are executed, they need the required # of bytes for the jump, negative if reverse direction, and the suffix to the label, ie.. 1 for 01 etc..
What is returned to the X register is the actual bytes needed to make the compiled GTO, XEQ or END. But how do I get those bytes to the program efficiently in order to avoid decompiling the previous GTO I just inserted. I tried using the "LBX" but I think that this would not work so well as the deletion of the "+", XEQ LBX and LBL "++" will decompile the just compiled GTO. Is this thinking correct? I also tried using the STO Q and Q-Load option and this again just entered jibberish. Am I using these programs above wrong? Is there another program that can be used to transfer the bytes from the X register to the specific location in Program memory? Is "CODE" the program that will do this for me?


First: I write here by heart, so it may be wrong.
There is a flag in the END of a program to show if it was changed and if it needs "de-compiling". Early HP-41 had an bug (no. ?) where you could avoid that by going OFF when still in PRGM-mode, when going ON your _out_ of PRGM mode and run your routine with wrong distances in GTO and XEQ.

But your question is how to alter a program without decompiling: Just combine a whole register (7 byte) of your routine as an "Not Normalized Number" (NNN) and store it at the proper location. But never do a RCL on that location, it will alter (normalize) the contents to what typicaly looks like a number.

Which program to use for that? It depends. On a bare HP-41C read "Synthetic Programming" by Wickes and try his suggestions. With a PPC-ROM and it's manual you have all you need. I prefere the ZEN-ROM for such stuff as it's RAMED is so comfortable.



Is there some way to get the "Ramed" program from the ZenRom and have it put onto mag cards or a cassete tape?
I used to use the ZenRom to do these tasks but sold it years ago and reget it now.


Definitly NO. RAMED, and other ML programs,
have to reside in 10-bit word wide RAM or ROM.
For the HP-41, only ROM simulators or ROM's provide that format.



Hi Luiz! :-)

You are correct, my answer was much too short to cover all aspects of the matter. I only wanted to point to the fact that you will loose lot of time you'll never gain it again.

Yes, correct, not only changing a program, PACK too causes de-compiling - irrespective if the program is PRIVATE or not. But PACK de-compiles only once, a second PACK will _not_. When I adviced to make a program PRIVATE I had synthetic means in mind - w/o card reader, just to avoid accidentally changing the program.

If you write a compiled prgm to card (or bar code) and read it back to the HP-41, the first PACK will decompile it. Doing GTO.. adds an END - what is a change that triggers decompiling. There is a way to PACK w/o decompiling: Just destroy the "global chain" in the permanent .END. and XEQ

There are some ROMs with routines to compile user programs (in Skwids Bar Code ROM for example) but AFAIK they all need local labels to know where to jump.

BTW, if you have GTOs and XEQs in your code that is never reached, just re-think your routine.

Anyway, you will spend hours to speed up your program some mili seconds.


Possibly Related Threads...
Thread Author Replies Views Last Post
  41-MCODE: Auto XEQ+ALPHA possible? Ángel Martin 5 1,395 05-29-2013, 06:15 AM
Last Post: Ángel Martin
  50G and Compiled Local Variables Matt Agajanian 6 1,586 05-22-2012, 12:40 PM
Last Post: Matt Agajanian
  XEQ vs GSB - what am I missing? Thomas Radtke 9 1,992 11-30-2011, 10:25 AM
Last Post: Gerson W. Barbosa
  HP32s Relative GTO Mike T. 4 1,065 04-04-2011, 07:33 PM
Last Post: Don Shepherd
  compiled local variable DK2ZA 5 1,164 10-08-2009, 01:10 PM
Last Post: Vieira, Luiz C. (Brazil)
  41 RPN LBL GTO rules Egan Ford 8 1,593 03-08-2009, 06:12 PM
Last Post: Egan Ford
  XEQ vs. GSB Antonio Maschio (Italy) 2 856 06-05-2008, 04:57 AM
Last Post: Karl Schneider
  35s GTO . label issue sjthomas 1 612 08-07-2007, 12:20 AM
Last Post: Les Wright
  35s, Global Labels, and GTO a program line from RUN mode Les Wright 12 2,439 07-18-2007, 04:06 AM
Last Post: Werner
  50 G compiled local variables RON ALLEN 1 638 10-30-2006, 12:49 PM
Last Post: Ron Allen

Forum Jump: