Post Reply 
41C ROMs: LBL linkages
09-04-2019, 09:45 PM (This post was last modified: 09-04-2019 09:47 PM by hth.)
Post: #6
RE: 41C ROMs: LBL linkages
(09-04-2019 08:41 PM)RobertM Wrote:  
(09-01-2019 04:42 AM)hth Wrote:  The global label links are the same as in RAM and they are fully deterministic in a ROM stored program.

...
In other words, the link from the first global alpha should point to the preceding END (which was the .END. before COPY), and given the algorithm, its location is known and always the same relative to the copied program.

I think we are talking about different things. I don't believe the global links in ROM are deterministic from just the source...they depend on how they were copied from RAM when put into a ROM. What I mean by this is that just having the source to the printer ROM, I can not generate a ROM file that will match exactly the original printer ROM, because I can't know what values to use in the Cx yz positions for ANY first LBL after a two word UCODE intro. (Examples are the Cx yz values for PRPLOT in the printer ROM, or MK, LF, ML, or LB for the PPCL.ROM).

Also, as Ángel said, you can move these UCODE blocks around in the ROM (e.g. put some MCODE before one) without changing the Cx yz values in the first LBL and things still work.

Curious if you disagree and if so, how you can determine those values from just the source. Smile

Eh, what? Smile

Well, we probably talk past each other, but I will try to make my point of view again then.

I determine the values by means of the 'rpncomp' tool I have. It takes an RPN source file (or .raw) and turns it into an RPN program represented by an internal data structure (on the host computer). It was a long time ago I stopped fiddling with putting together ROMs on the HP-41 itself. The tool compiles local branches (GTO/XEQ) as well as build the global chain.

Take a look at the COPY routine in mainframe (HP-41 firmware) and how it works. It uses the old .END. to become a new local (plain ordinary) END. Then program bytes are copied into registers. The two extra words serve two purposes, to tell how many registers are needed (for PACKING - TRY AGAIN) and to tell how many NOPs go into the first register to fill up registers evenly. No new .END. is created by the COPY code, it is the END if the RPN program in ROM that becomes the new permanent .END..

The .END. must be right aligned in the register (by design), which is the reason why it pads with initial NULLs.

If you look at the source of COPY, you will see that the only thing it really does with the ENDs and global labels is to change the old .END. to be a new END. Nothing else is done with global chain instructions. Thus, I conclude that the END from ROM is the new .END. and as no global label is modified in any way, the global chain has to come from the ROM image. As it is a chain, it has to be chained all the way from the .END. and up. There can be previous programs in memory already, but we only need connect to the nearest global chain instruction, and that is the previous .END. which we just turned into an ordinary END. Furthermore, we know the distance to it, as we know it is right aligned in the previous register (as it was an .END.) and we know the number of pad NULLs. So we can put that distance in the first global label of the ROM stored program.

The global label chain does not matter at all as long as the program is in ROM, where we use XROM and the FAT, but it is crucial when the program is in RAM. As the COPY routine does nothing with them, they have be correct (and deterministic) when stored in ROM for COPY to work properly.

If you think about it, the COPY routine is remarkably short for what it does and it can only be this short because the original developers of the HP-41 were a group of very clever people that probably spent quite some time designing and fitting all this functionality into the small space available.

So I stand on my island and say the global chain matters and that there can only be one link value in global LBLs to make it all work properly.

On the other hand, you can of course represent a program from a source listing in different ways, as you can insert dummy NULLs and use alternative short/long forms of some instructions, such as RCL, STO, LBL, GTO. Which means that a printed program may not be identical if it is compiled to ROM again. That is a different story and it is perhaps here I misunderstood the question?
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
41C ROMs: LBL linkages - RobertM - 08-28-2019, 12:21 AM
RE: 41C ROMs: LBL linkages - Ángel Martin - 08-28-2019, 04:56 AM
RE: 41C ROMs: LBL linkages - RobertM - 08-28-2019, 01:57 PM
RE: 41C ROMs: LBL linkages - hth - 09-01-2019, 04:42 AM
RE: 41C ROMs: LBL linkages - RobertM - 09-04-2019, 08:41 PM
RE: 41C ROMs: LBL linkages - hth - 09-04-2019 09:45 PM
RE: 41C ROMs: LBL linkages - RobertM - 09-05-2019, 12:10 AM
RE: 41C ROMs: LBL linkages - hth - 09-05-2019, 01:27 AM
RE: 41C ROMs: LBL linkages - Ángel Martin - 09-05-2019, 07:50 AM
RE: 41C ROMs: LBL linkages - hth - 09-05-2019, 04:32 PM



User(s) browsing this thread: 1 Guest(s)