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 =- > > > >
