Good stuff! HP-LX docs call Run-In-Place code "XIP", for Execute-In-Place.
Although RIP seems appropriate enough for my code... On 6/1/18, Stephen Adolph <[email protected]> wrote: > this is quite useful; it applies specifically to (a) running code that is > buried in BASIC string variables and (b) running code that is buried in > DATA structures, because in those cases you really don't know where the > code is (easily), and the code can't adapt to being moved around (easily). > Now it can. Very useful! > > Regarding .DO files - the contents of the .DO file survives being loaded > into M100 memory intact. One has to avoid EOF and 0A. One does not need > quotes either. So this is quite dense, and > > > On Fri, Jun 1, 2018 at 3:15 AM, Ken Pettit <[email protected]> wrote: > >> Hi John, >> >> So based on Ron's research, the WHEREAMI function in ROM can be used as >> another way to perform a relative branch without the need for a fixed >> location in RAM: >> >> LXI D, branch_offset ; Calculated relative to the DAD D opcode >> below >> CALL WHEREAMI ; 31E9H or 3F3DH. HL now contains address >> of >> DAD D opcode on next line >> DAD D ; Perform relative address calculation >> POP D ; Pop old HL value from Stack >> PCHL ; Jump to new relative location >> >> And if you need a conditional relative jump, you can do: >> >> LXI D, branch_offset ; Calculated relative to the DAD D opcode >> below >> CALL WHEREAMI ; 31E9H or 3F3DH. HL now contains address >> of >> DAD D opcode on next line >> DAD D ; Perform relative address calculation >> POP D ; Pop old HL value from Stack >> JZ (or JNZ, etc.) 0ED7H ; Conditional jump to a PCHL opcode >> >> ; Fall though if condition not met >> >> >> Ken >> >> >> On 5/31/18 12:49 PM, John R. Hogerhuis wrote: >> >> Self-locating code. >> >> Ron Wiesen did some research a long time ago to figure out code in the >> ROM >> that could tell you where you are calling from. >> >> This is a critical part of code that can efficiently relocate itself to >> run-in-place or at a specific location. >> >> -- John. >> >> ---------- Forwarded message ---------- >> From: Ron Wiesen <[email protected]> >> Date: Thu, Nov 9, 2006 at 2:25 AM >> Subject: Reporting Breakthrough for "Run In Place" Operation -- Was Re: >> Remem : relocatable ML codes. >> To: Model 100 Listserve <[email protected]> >> >> >> Previously I wrote: >> > But your "relocatable ML codes" message has reminded me of some >> > progress >> I >> > recently made on a mission that was placed on the "back burner" a long >> time >> > ago. So I'll review my mission notes and report my progress to this >> list. >> > >> > The mission was to develop the means for software, operating in a M10x >> > or >> > M200 laptop, to discovered the memory address of "Where I am Now". >> > I've >> > found four methods to do it, tested all four of them, and believe I've >> > determined which is the "best" method of the four. Having the means to >> > ascertain "Where I am Now" is a long sought after breakthrough. It's >> > something that's essential in obtaining a substantial improvement in >> > the >> > "Run In Place" operation of binary objects; the improvement eliminates >> need >> > for the separate utility that launches said binary objects. "Run In >> Place" >> > operation of binary objects avoids need for a HIMEM area and avoids the >> > double-consumption penalty that ordinary invocation of binary objects. >> >> The "Self-Locate" snippet shown below is my report, which details the >> "best" >> method of the four methods that I found and tested. Details are given >> for >> both the Model 10x laptop (CALL 31E9H and JMP 14EDH) and for the Model >> 200 >> laptop (CALL 3F3DH and JMP 1604H). >> >> ===== Self-Locate -- major milestone for run-in-place laptop executables >> ===== >> WHEREAMI: EQU $ >> CALL 31E9H ;XTHL PCHL stacks HL, HL=rtn. Model 10x. >> ; CALL 3F3DH ;XTHL PCHL stacks HL, HL=rtn. Model 200. >> IAMHERE: EQU $ ;I am HERE at this discovered return address >> ;which now is in HL >> PUSH D >> PUSH B >> PUSH PSW >> ;All reg content stacked. JMP 14EDH is a handy unstack exit. >> JMP 14EDH ;Pops PSW,B,D,H and then RET exit. Model >> 10x. >> ; JMP 1604H ;Pops PSW,B,D,H and then RET exit. Model >> 200. >> >> Once it's discovered "Where I am Now" then inspection of "Where I was >> Before" is done. The difference is the needed adjustment of wordAdrs. >> Note, if difference is 0, adjustment isn't needed and time is saved -- >> often the case for code held within BASIC program files. >> >> Via link-lists, locales of wordAdrs are found. Each is adjusted >> according to the adjustment difference. If there are locales for >> byteAdrs (unlikely), they have their own link-lists and also are >> adjusted. Two link-list structures are considered: ByteAdvance and >> BitsOfNext. In some cases a mix of both may minimize overhead cost. >> >> ByteAdvance was done before in type .CE development and for ERL >> development. It presumes all locales are adjacent in series by no more >> than 256-spans. Worst case is two wordAdrs locales displaced by 256. >> Example: locales of ?000h and ?100h are linked by link value of FFh >> (255). Adjustment to ?000h increments beyond it to ?0001h (the >> Hi-part), and relative to ?001h going further by FFh arrives at locale >> ?100h. Example: locale of ?000h and ?002h are linked by link value of >> 01h (1). Relative to ?001h going further by only 01h arrives at the >> directly adjacent locale ?003h. Note that link value of 00h (0) can be >> used as the delimiter of a link-list, although it could be used to >> increase the maximum displacement for 257-spans. The overhead cost is >> 1 ByteAdvance link per wordAdrs locale. This can be a lot for code >> with much internal reference and little Rom reference. >> >> BitsOfNext has not been developed yet. <SNIP> >> ============================================================ >> ================ >> == >> >> The method detailed above might also might be of particular interest to >> John >> Hoger and to Wilson Van Alst. In the November 8, 2006 in the "Re: Remem >> : >> relocatable ML codes." message thread, John wrote: >> > Wilson and I hashed out something similar: you can do this without >> > much special other than taking back one of the traps. >> > >> > In your code you put a trap swi followed by a 16-bit signed offset. >> > When the trap runs it looks at the stack to figure out where it jumped >> > from, and patches up the trap and 16-bit offset to an absolute >> > address. >> > >> > The flaws are that >> > >> > a) you need a trap (remem allows us to take back a trap, potentially) >> > and >> > b) everything gets fixed on the first run and the code can't be moved >> > without reload >> > c) Also it won't work for code to run from read-only memory. But who >> > cares since if you're running from ROM you won't be relocating anyway. >> > >> > There are slow techniques for truly position independent code that >> > depend on some special thunk located somewhere. We should at least >> > patch the rom to include the special thunk. I have a doc from Ron >> > Balonis that shows how to do this. >> > >> > -- John. >> >> Note: the operational constraint that John lists in flaw item b (.... >> code >> can't be moved) might be overcome by use of the "Self-Locate" method that >> I've reported herein. >> >> -= Ron =- >> >> >> >> >
