# Self-relocation > Mediated Wiki article. Canonical URL: https://mediated.wiki/source/Self-relocation > Markdown URL: https://mediated.wiki/source/Self-relocation.md > Source: https://en.wikipedia.org/wiki/Self-relocation > Source revision: 1356555491 > License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/) {{Short description|Program that relocates its own address-dependent instructions and data when run}} {{Use dmy dates|date=April 2019|cs1-dates=y}} {{Use list-defined references|date=December 2021}} In [computer programming](/source/computer_programming), a '''self-relocating''' program is a program that [relocates](/source/relocation_(computing)) its own address-dependent instructions and data when run, and is therefore capable of being loaded into memory at any address. In many cases, self-relocating code is also a form of [self-modifying code](/source/self-modifying_code). ==Overview== Self-relocation is similar to the [relocation](/source/relocation_(computer_science)) process employed by the [linker](/source/linker_(computing))-[loader](/source/loader_(computing)) when a program is copied from external storage into main memory; the difference is that it is the loaded program itself rather than the loader in the [operating system](/source/operating_system) or [shell](/source/shell_(computing)) that performs the relocation. One form of self-relocation occurs when a program copies the code of its instructions from one sequence of locations to another sequence of locations within the main memory of a single computer, and then transfers processor control from the instructions found at the source locations of memory to the instructions found at the destination locations of memory. As such, the data operated upon by the algorithm of the program is the sequence of bytes which define the program. Static self-relocation typically happens at [load-time](/source/load-time) (after the operating system has loaded the software and passed control to it, but still before its initialization has finished), sometimes also when changing the program's configuration at a later stage during [runtime](/source/Run_time_(program_lifecycle_phase)). ==Examples== ==={{anchor|Bootloader}}Boot loaders=== As an example, self-relocation is often employed in the early stages of bootstrapping operating systems on architectures like [IBM PC compatible](/source/IBM_PC_compatible)s, where lower-level chain [boot loader](/source/boot_loader)s (like the [master boot record](/source/master_boot_record) (MBR), [volume boot record](/source/volume_boot_record) (VBR) and initial boot stages of operating systems such as [DOS](/source/DOS)) move themselves out of place in order to load the next stage into memory. ==={{anchor|CP/M}}CP/M extensions=== Under [CP/M](/source/CP%2FM), the debugger [Dynamic Debugging Tool](/source/Dynamic_Debugging_Tool) (DDT) [dynamically](/source/dynamic_relocation) relocated ''itself'' to the top of available memory through [page boundary relocation](/source/page_boundary_relocation) in order to maximize the [Transient Program Area](/source/Transient_Program_Area) (TPA) for programs to run in. In 1988, the alternative command line processor [ZCPR](/source/ZCPR) 3.4 for the [Z-System](/source/Z-System) introduced so called ''type-4'' programs which were self-relocatable through an embedded stub as well. ==={{anchor|DOS}}x86 DOS drivers=== Under [DOS](/source/DOS), self-relocation is sometimes also used by more advanced [driver](/source/device_driver)s and [resident system extension](/source/resident_system_extension)s (RSXs) or [terminate-and-stay-resident program](/source/terminate-and-stay-resident_program)s (TSRs) loading themselves "high" into [upper memory](/source/upper_memory) more effectively than possible for externally provided "high"-loaders (like [LOADHIGH](/source/LOADHIGH)/[HILOAD](/source/HILOAD), [INSTALLHIGH](/source/INSTALLHIGH)/[HIINSTALL](/source/HIINSTALL) or [DEVICEHIGH](/source/DEVICEHIGH)/[HIDEVICE](/source/HIDEVICE) etc. since DOS 5) in order to maximize the memory available for applications. This is down to the fact that the operating system has no knowledge of the inner workings of a driver to be loaded and thus has to load it into a free memory area large enough to hold the whole driver as a block including its initialization code, even if that would be freed after the initialization. For TSRs, the operating system also has to allocate a [Program Segment Prefix](/source/Program_Segment_Prefix) (PSP) and an [environment segment](/source/environment_segment). This might cause the driver not to be loaded into the most suitable free memory area or even prevent it from being loaded high at all. In contrast to this, a self-relocating driver can be loaded anywhere (including into [conventional memory](/source/conventional_memory)) and then relocate only its (typically much smaller) resident portion into a suitable free memory area in upper memory. In addition, advanced self-relocating TSRs (even if already loaded into upper memory by the operating system) can relocate over most of their own PSP segment and command line buffer and free their environment segment in order to further reduce the resulting [memory footprint](/source/memory_footprint) and avoid [fragmentation](/source/memory_fragmentation). Some self-relocating TSRs can also dynamically change their "nature" and morph into device drivers even if originally loaded as TSRs, thereby typically also freeing some memory. Finally, it is technically impossible for an external loader to relocate drivers into [expanded memory](/source/expanded_memory) (EMS), the [high memory area](/source/high_memory_area) (HMA) or [extended memory](/source/extended_memory) (via [DPMS](/source/DOS_Protected_Mode_Services) or [CLOAKING](/source/CLOAKING_(DOS_extender))), because these methods require small driver-specific [stub](/source/DOS_memory_stub)s to remain in conventional or upper memory in order to coordinate the access to the relocation target area, and in the case of device drivers also because the driver's header must always remain in the first megabyte. In order to achieve this, the drivers must be specially designed to support self-relocation into these areas. Some advanced DOS drivers also contain both a device driver (which would be loaded at offset +0000h by the operating system) and TSR (loaded at offset +0100h) sharing a common code portion internally as [fat binary](/source/fat_binary). If the shared code is not designed to be [position-independent](/source/position-independent), it requires some form of internal address fix-up similar to what would otherwise have been carried out by a [relocating loader](/source/relocating_loader) already; this is similar to the fix-up stage of self-relocation but with the code already being loaded at the target location by the operating system's loader (instead of done by the driver itself). ===IBM DOS/360 and OS/360 programs=== [IBM](/source/IBM) [DOS/360](/source/DOS%2F360) did not have the ability to relocate programs during loading. Sometimes multiple versions of a program were maintained, each built for a different load address ([partition](/source/Memory_management_(operating_systems))). A special class of programs, called self-relocating programs, were coded to relocate themselves after loading. IBM [OS/360](/source/OS%2F360) relocated executable programs when they were loaded into memory. Only one copy of the program was required, but once loaded the program could not be moved (so called [one-time position-independent code](/source/one-time_position-independent_code)). ===Other examples=== As an extreme example of (many-time) self-relocation, also called dynamic self-relocation, it is possible to construct a computer program so that it does not stay at a fixed address in memory, even as it executes, as for example used in [worm memory test](/source/worm_memory_test)s. The [Apple Worm](/source/Apple_Worm) is a dynamic self-relocator as well. ==See also== * [Dynamic dead-code elimination](/source/Dynamic_dead-code_elimination) * [RPLOADER](/source/RPLOADER) – a DR-DOS API to assist remote/network boot code in relocating itself while DOS boots * [Garbage collection](/source/Garbage_collection_(computing)) * [Self-replication](/source/Self-replication) * [Self-reference](/source/Self-reference) * [Quine (computing)](/source/Quine_(computing)) ==Notes== {{Reflist|group="nb"|refs= An exception to the requirement for a stub is when [expanded memory](/source/expanded_memory) is converted into [permanent upper memory](/source/permanent_upper_memory) by the memory manager via [EMSUMB](/source/EMSUMB), and thus it is effectively accessed as [upper memory](/source/upper_memory), not via [EMS](/source/Expanded_Memory_Specification). There are two exceptions to the stub requirement for a driver to load into the [HMA](/source/High_memory_area): A stub is not necessary when [high memory](/source/high_memory_(DOS)) is permanently enabled on machines without [gate A20](/source/gate_A20) logic, however, as this condition isn't met in general, generic DOS drivers cannot take advantage of it (unless they would explicitly test on this condition beforehand). Otherwise, a stub is also not necessary under [DR DOS 6.0](/source/DR_DOS_6.0) and higher, when resident system extensions (like [SHARE](/source/SHARE_(DOS_command)) and [NLSFUNC](/source/NLSFUNC_(DOS_command))) only hook the multiplex interrupt INT 2Fh, because they can then utilize a backdoor interface to hook into the interrupt chain in [kernel space](/source/kernel_space) so that the kernel's gate A20 handler will provide the functionality of the stub.{{citeref|ref=Ref-Paul-2002-Drivers|a}} Still, the driver has to perform self-relocation in order to function correctly in the HMA. }} ==References== {{Reflist|refs= {{cite book |author-last=Dhamdhere |author-first=Dhananjay M. |author-link=Dhananjay M. Dhamdhere |date=1999 |title=Systems Programming and Operating Systems |publisher=[Tata McGraw-Hill](/source/Tata_McGraw-Hill) |series=Education |publication-place=New Delhi, India |page=232 |isbn=0-07-463579-4 |id={{ISBN|978-0-07-463579-7}} |url=https://books.google.com/books?id=s7zgF7InxIgC&pg=PA232 |access-date=2011-11-08 |url-status=live |archive-url=https://web.archive.org/web/20200201095049/https://books.google.de/books?id=s7zgF7InxIgC&pg=PA232&redir_esc=y |archive-date=2020-02-01}} (658 pages) {{cite book |author-last=Dhamdhere |author-first=Dhananjay M. |author-link=Dhananjay M. Dhamdhere |date=2006 |title=Operating Systems: A Concept-based Approach |publisher=[Tata McGraw-Hill](/source/Tata_McGraw-Hill) |series=Education |publication-place=New Delhi, India |page=231 |isbn=0-07-061194-7 |id={{ISBN|978-0-07-061194-8}} |url=https://books.google.com/books?id=kbBn4X9x2mcC&pg=PA231 |access-date=2020-02-20 |url-status=live |archive-url=https://web.archive.org/web/20200220150719/https://books.google.de/books?id=kbBn4X9x2mcC&pg=PA231&lpg=PA231&redir_esc=y |archive-date=2020-02-20}} (799 pages) {{citation |title=FreeKEYB – Enhanced DOS keyboard and console driver |edition=6.5 |author-first1=Matthias R. |author-last1=Paul |author-first2=Axel C. |author-last2=Frinke |type=User Manual |date=1997-10-13 |orig-date=1991}} [https://web.archive.org/web/20190309194320/http://sta.c64.org/dosprg/fk657p1.zip] (NB. FreeKEYB is a [Unicode](/source/Unicode)-based dynamically configurable driver supporting most [keyboard layout](/source/keyboard_layout)s, [code page](/source/code_page)s, and [country code](/source/List_of_country_calling_codes)s. Utilizing an off-the-shelf [macro assembler](/source/macro_assembler) as well as a framework of automatic pre- and post-processing analysis tools to generate dependency and [code morphing](/source/code_morphing) [meta data](/source/meta_data) to be embedded into the [executable file](/source/executable_file) alongside the [binary code](/source/binary_code) and a self-discarding, [relaxing](/source/instruction_relaxation) and [relocating loader](/source/relocating_loader), the driver supports to be variously loaded and install itself as TSR or [device driver](/source/device_driver) and it implements advanced self-relocation techniques (including into normal [DOS memory](/source/DOS_memory), [UMB](/source/upper_memory_block)s, unused [video memory](/source/video_memory), or raw memory also utilizing [program segment prefix](/source/program_segment_prefix) overloading and [environment segment](/source/environment_segment) recombination) and byte-level granular [dynamic dead-code elimination](/source/dynamic_dead-code_elimination) at [load-time](/source/load-time) as well as [self-modifying code](/source/self-modifying_code) and reconfigurability at [run-time](/source/runtime_(computing)) to minimize its memory footprint depending on the hardware, operating system and driver configuration as well as the selected feature set and locale.) {{citation |title=FreeKEYB – Advanced international DOS keyboard and console driver |edition=7 (preliminary) |author-first1=Matthias R. |author-last1=Paul |author-first2=Axel C. |author-last2=Frinke |type=User Manual |date=2006-01-16}} {{cite journal |journal=[Scientific American](/source/Scientific_American) |title=Computer Recreations – A Core War bestiary of viruses, worms and other threats to computer memories |volume=285 |date=March 1985 |pages=38–39 |author-first=Alexander Keewatin |author-last=Dewdney |author-link=Alexander Keewatin Dewdney |url=http://www.koth.org/info/akdewdney/Second.htm |access-date=2017-07-04 |url-status=live |archive-url=https://web.archive.org/web/20170704155754/http://www.koth.org/info/akdewdney/Second.htm |archive-date=2017-07-04}} {{anchor|Ref-Paul-2002-Drivers}}{{cite newsgroup |title=Treiber dynamisch nachladen |trans-title=Loading drivers dynamically |author-first=Matthias R. |author-last=Paul |date=2002-02-02 |year=2002a |newsgroup=de.comp.os.msdos |language=de |url=https://groups.google.com/d/msg/de.comp.os.msdos/tdvpBoMVN6A/a_zqDxGk22IJ |access-date=2017-07-02 |url-status=live |archive-url=https://archive.today/20170909085006/https://groups.google.com/forum/%23!msg/de.comp.os.msdos/tdvpBoMVN6A/a_zqDxGk22IJ |archive-date=2017-09-09}} (NB. Gives an overview on load-high methods under DOS, including the usage of [LOADHIGH](/source/LOADHIGH) etc. commands and self-relocating methods into [UMB](/source/Upper_Memory_Blocks)s utilizing the [XMSUMB](/source/XMSUMB) API. It also discusses {{citeref|Kildall|1978|more sophisticated methods|style=plain}} necessary for TSRs to relocate into the [HMA](/source/High_Memory_Area) utilizing [intra-segment offset relocation](/source/intra-segment_offset_relocation).) {{cite book |title=Caldera DR-DOS 7.02 User Guide |publisher=[Caldera, Inc.](/source/Caldera%2C_Inc.) |date=1998 |orig-date=1993, 1997 |chapter=Chapter 10 Managing Memory |chapter-url=http://www.drdos.net/documentation/usergeng/10ugch10.htm |access-date=2017-08-30 |url-status=dead |archive-url=https://web.archive.org/web/20170830153325/http://www.drdos.net/documentation/usergeng/10ugch10.htm |archive-date=2017-08-30}} {{cite news |title=Throughput – Are you getting all you deserve? – DOSRELO |author=Boothe Management Systems |location=San Francisco, California, USA |type=advertisement |date=1972-11-01 |volume=VI |number=44 |newspaper=[Computerworld](/source/Computerworld) – The Newsweekly For The Computer Community |publisher=[Computerworld, Inc.](/source/Computerworld%2C_Inc.) |page=9 |url=https://books.google.com/books?id=trl_RJ8Yz4YC&pg=PT8 |access-date=2020-02-07 |url-status=live |archive-url=https://web.archive.org/web/20200206221854/https://books.google.com/books?id=trl_RJ8Yz4YC&pg=PT8&lpg=PT8 |archive-date=2020-02-06 |quote=[…] DOSRELO provides a method of making [DOS](/source/DOS%2F360) problem programs self-relocating. DOSRELO accomplishes the self-relocation capability for all programs, regardless of the language, by adding entry point logic to the [object code](/source/object_code) of the program before the [Linkage Editor](/source/Linkage_Editor) catalogs it on the [Core Image Library](/source/Core_Image_Library). […]}} {{cite web |title=Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1 |author-first=Matthias R. |author-last=Paul |work=freedos-dev |date=2002-04-06 |year=2002b |url=https://marc.info/?l=freedos-dev&m=101807226917577 |access-date=2020-02-07 |url-status=live |archive-url=https://web.archive.org/web/20200207130948/https://marc.info/?l=freedos-dev&m=101807226917577&w=2 |archive-date=2020-02-07 |quote=[…] Add a SYS device driver header to the driver, so that CTMOUSE could be [both in one](/source/Fat_binary), a normal [TSR](/source/Terminate-and-stay-resident_program) and a device driver – similar to our FreeKEYB advanced keyboard driver. […] This is not really needed under [DR DOS](/source/DR%26nbsp%3BDOS) because [INSTALL](/source/INSTALL_(CONFIG.SYS_directive))= is supported since DR DOS 3.41+ and DR DOS preserves the order of [[D]CONFIG.SYS](/source/CONFIG.SYS) directives […] but it would […] improve the […] flexibility on [MS-DOS](/source/MS-DOS)/[PC DOS](/source/PC%26nbsp%3BDOS) systems, which […] always execute [DEVICE](/source/DEVICE_(CONFIG.SYS_directive))= directives prior to any INSTALL= statements, regardless of their order in the file. […] software may require the mouse driver to be present as a device driver, as mouse drivers have always been device drivers back in the old times. These mouse drivers have had specific device driver names depending on which protocol they used ("[PC$MOUSE](/source/PC%24MOUSE)" for [Mouse Systems Mode](/source/Mouse_Systems_Mode) for example), and some software may search for these drivers in order to find out the correct type of mouse to be used. […] Another advantage would be that device drivers usually consume less memory (no [environment](/source/environment_(computing)), no [PSP](/source/Program_Segment_Prefix)) […] It's basically a tricky file header, a different code to parse the command line, a different entry point and exit line, and some segment magics to overcome the ORG 0 / ORG 100h difference. Self-loadhighing a device driver is a bit more tricky as you have to leave the driver header where it is and only relocate the remainder of the driver […]}} {{cite web |title=Re: [fd-dev] On GRAFTABL and DISPLAY.SYS (Was: Changing codepages in FreeDOS) |author-first=Matthias R. |author-last=Paul |date=2001-08-18 |work=freedos-dev |url=https://marc.info/?l=freedos-dev&m=99816495921290&w=2 |access-date=2017-09-04 |url-status=live |archive-url=https://archive.today/20170904165516/https://marc.info/?l=freedos-dev&m=99816495921290&w=2 |archive-date=2017-09-04 |quote=[…] At least the [MS-DOS 6.0](/source/MS-DOS_6.0)+ [GRAFTABL](/source/GRAFTABL_(DOS_command)) relocates itself over parts of its [PSP](/source/Program_Segment_Prefix) segment (offset +60h and upwards) to minimize its resident size. […]}} (NB. A post-[DR-DOS 7.03](/source/DR-DOS_7.03) GRAFTABL 2.00+ supports dynamic self-relocation as well.) {{cite journal |author-first=Gary Arlen |author-last=Kildall |author-link=Gary Arlen Kildall |title=A simple technique for static relocation of absolute machine code |journal=[Dr. Dobb's Journal of Computer Calisthenics & Orthodontia](/source/Dr._Dobb's_Journal_of_Computer_Calisthenics_%26_Orthodontia) |publisher=[People's Computer Company](/source/People's_Computer_Company) |volume=3 |issue=2 |id=#22 ark:/13960/t8hf1g21p |date=February 1978 |orig-date=1976 |pages=10–13 (66–69) |isbn=0-8104-5490-4 |url=https://archive.org/details/dr_dobbs_journal_vol_03/page/n67/mode/1up |access-date=2017-08-19}} [https://web.archive.org/web/20170819141800/http://www.retrotechnology.com/dri/d_dri_refs.html][https://web.archive.org/web/20170819173516/http://archive.computerhistory.org/resources/access/text/2016/12/102762506-05-01-acc.pdf][https://archive.today/20170909091943/https://groups.google.com/forum/%23!msg/comp.os.cpm/TLHgIi16yTo/gupNB1ai8UQJ#!topic/comp.os.cpm/TLHgIi16yTo]. Originally presented at: {{cite conference |title=Conference Record: Tenth Annual Asilomar Conference on Circuits, Systems and Computers: Papers Presented November 22–24, 1976 |editor-first=Harold A. |editor-last=Titus |chapter=A Simple Technique for Static Relocation of Absolute Machine Code |author-first=Gary Arlen |author-last=Kildall |author-link=Gary Arlen Kildall |location=[Naval Postgraduate School](/source/Naval_Postgraduate_School), Monterey, California, USA |publisher=Western Periodicals Company |publication-place=Asilomar Hotel and Conference Grounds, Pacific Grove, California, USA |date=1977 |orig-date=22–24 November 1976 |issn=1058-6393 |pages=420–424 |url=https://books.google.com/books?id=cyBGAQAAIAAJ&q=relocation |access-date=2021-12-06}} (609 pages). (This "resize" method, named ''[page boundary relocation](/source/page_boundary_relocation)'', could be applied statically to a [CP/M-80](/source/CP%2FM-80) disk image using {{ill|MOVCPM|pl|MOVCPM (CP/M)}} in order to maximize the [TPA](/source/Transient_Program_Area) for programs to run. It was also utilized dynamically by the CP/M debugger [Dynamic Debugging Tool](/source/Dynamic_Debugging_Tool) (DDT) to relocate itself into higher memory. The same approach was independently developed by [Bruce H. Van Natta](/source/Bruce_H._Van_Natta) of [IMS Associates](/source/IMS_Associates) to produce relocatable [PL/M](/source/PL%2FM) code. As ''[paragraph boundary relocation](/source/paragraph_boundary_relocation)'' {{citeref|Paul|2002a|another variant|style=plain}} of this method was later utilized by dynamically [HMA](/source/High_Memory_Area) self-relocating TSRs like [KEYB](/source/KEYB_(DOS_command)), [SHARE](/source/SHARE_(DOS_command)), and [NLSFUNC](/source/NLSFUNC_(DOS_command)) under [DR DOS 6.0](/source/DR%26nbsp%3BDOS_6.0) and higher. A much more sophisticated and [byte-level granular](/source/byte_alignment) offset relocation method based on a somewhat similar approach was independently conceived and implemented by Matthias R. Paul and Axel C. Frinke for their [dynamic dead-code elimination](/source/dynamic_dead-code_elimination) to dynamically minimize the runtime footprint of resident drivers and TSRs (like FreeKEYB).) {{cite web |title=Legacy of Gary Kildall: The CP/M IEEE Milestone Dedication |author-first1=Robert |author-last1=Huitt |author-first2=Gordon |author-last2=Eubanks |author-link2=Gordon Eubanks |author-first3=Thomas "Tom" Alan |author-last3=Rolander |author-link3=Thomas Alan Rolander |author-first4=David |author-last4=Laws |author-first5=Howard E. |author-last5=Michel |author-first6=Brian |author-last6=Halla |author-first7=John Harrison |author-last7=Wharton |author-link7=John Harrison Wharton |author-first8=Brian |author-last8=Berg |author-first9=Weilian |author-last9=Su |author-first10=Scott |author-last10=Kildall |author-link10=Scott Kildall |author-first11=Bill |author-last11=Kampe |editor-first=David |editor-last=Laws |date=2014-04-25 |location=Pacific Grove, California, USA |type=video transscription |id=CHM Reference number: X7170.2014 |publisher=[Computer History Museum](/source/Computer_History_Museum) |url=https://archive.computerhistory.org/resources/access/text/2014/06/102746909-05-01-acc.pdf |access-date=2020-01-19 |url-status=live |archive-url=https://web.archive.org/web/20141227142045/http://archive.computerhistory.org/resources/access/text/2014/06/102746909-05-01-acc.pdf |archive-date=2014-12-27 |quote=[…] Laws: […] "[dynamic relocation](/source/dynamic_relocation)" of the OS. Can you tell us what that is and why it was important? […] [Eubanks](/source/Gordon_Eubanks): […] what [Gary](/source/Gary_Arlen_Kildall) did […] was […] mind boggling. […] I remember the day at the [school](/source/Naval_Postgraduate_School) he came bouncing into the lab and he said, I have figured out how to [relocate](/source/relocation_(computing)). He took advantage of the fact that the only byte was always going to be the [high order byte](/source/high_order_byte). And so he created a [bitmap](/source/bitmap). […] it didn't matter how much memory the computer had, the operating system could always be moved into the high memory. Therefore, you could commercialize this […] on machines of different amounts of memory. […] you couldn't be selling a 64K [CP/M](/source/CP%2FM) and a 47K CP/M. It'd just be ridiculous to have a hard compile in the addresses. So Gary figured this out one night, probably in the middle of the night thinking about some coding thing, and this really made CP/M possible to commercialize. I really think that without that relocation it would have been a very tough problem. To get people to buy it, it'd seem complicated to them, and if you added more memory you'd have to go get a different operating system. […] [Intel](/source/Intel) […] had the [bytes reversed](/source/little-endian), right, for the memory addresses. But they were always in the same place, so you could relocate it on a [256 byte boundary](/source/256_byte_boundary), to be precise. You could therefore always relocate it with just a bitmap of where those […] Laws: Certainly the most eloquent explanation I've ever had of dynamic relocation […]}} [https://ethw.org/Milestones:The_CP/M_Microcomputer_Operating_System,_1974][https://www.youtube.com/watch?v=HO6IPpL0y8g] (33 pages) {{cite journal |title=ZCPR 3.4 – Type-4 Programs |series=ZCPR3 Corner |author-first=Jay |author-last=Sage |journal=[The Computer Journal](/source/The_Computer_Journal_(US_journal)%3C!--_to_be_distinguished_from_the_identically_named_UK_journal_--%3E) (TCJ) – Programming, User Support, Applications |issn=0748-9331 |editor-first=Art |editor-last=Carlson |date=May–June 1988 |publication-place=Columbia Falls, Montana, USA |issue=32 |pages=[https://archive.org/details/the-computer-journal-32/page/n10/mode/1up 10]–17 |id=ark:/13960/t1wd4v943 |url=https://archive.org/details/the-computer-journal-32 |access-date=2021-11-29}} [https://archive.org/stream/the-computer-journal-32/tcj_32_May-June_1988_djvu.txt][https://archive.org/download/the-computer-journal-32/tcj_32_May-June_1988_text.pdf] {{cite journal |title=Z3PLUS & Relocation – Information on ZCPR3PLUS, and how to write self relocating Z80 code |series=Advanced CP/M |author-first=Bridger |author-last=Mitchell |journal=[The Computer Journal](/source/The_Computer_Journal_(US_journal)%3C!--_to_be_distinguished_from_the_identically_named_UK_journal_--%3E) (TCJ) – Programming, User Support, Applications |issn=0748-9331 |editor-first=Art |editor-last=Carlson |date=July–August 1988 |publication-place=Columbia Falls, Montana, USA |issue=33 |pages=[https://archive.org/details/the-computer-journal-33/page/n10/mode/1up 9]–15 |id=ark:/13960/t36121780 |url=https://archive.org/details/the-computer-journal-33 |access-date=2020-02-09}} [https://archive.org/stream/the-computer-journal-33/tcj_33_July-August_1988_djvu.txt][https://archive.org/download/the-computer-journal-33/tcj_33_July-August_1988_text.pdf] {{cite journal |title=More on relocatable code, PRL files, ZCPR34, and Type-4 programs |series=ZCPR3 Corner |author-first=Jay |author-last=Sage |journal=[The Computer Journal](/source/The_Computer_Journal_(US_journal)%3C!--_to_be_distinguished_from_the_identically_named_UK_journal_--%3E) (TCJ) – Programming, User Support, Applications |issn=0748-9331 |editor-first=Art |editor-last=Carlson |date=September–October 1988 |location=Columbia Falls, Montana, USA |issue=34 |pages=[https://archive.org/details/the-computer-journal-34/page/n20/mode/1up 20]–25 |id=ark:/13960/t0ks7pc39 |url=https://archive.org/details/the-computer-journal-34 |access-date=2020-02-09}} [https://archive.org/stream/the-computer-journal-34/tcj_34_September-October_1988_djvu.txt][https://archive.org/download/the-computer-journal-34/tcj_34_September-October_1988_text.pdf][https://web.archive.org/web/20170831184307/http://gaby.de/ftp/pub/cpm/znode51/articles/tcj/tcj34.ws] {{cite journal |title=Ten Years of ZCPR |series=Z-System Corner |author-first=Jay |author-last=Sage |journal=[The Computer Journal](/source/The_Computer_Journal_(US_journal)%3C!--_to_be_distinguished_from_the_identically_named_UK_journal_--%3E) (TCJ) – Programming, User Support, Applications |issn=0748-9331 |editor-first1=Art |editor-last1=Carlson |editor-first2=Chris |editor-last2=McEwen |date=January–February 1992 |publisher=Socrates Press |location=S. Plainfield, New Jersey, USA |issue=54 |pages=[https://archive.org/details/the-computer-journal-54/page/n4/mode/1up 3]–7 |id=ark:/13960/t89g6n689 |url=https://archive.org/details/the-computer-journal-54 |access-date=2021-11-29}} [https://archive.org/stream/the-computer-journal-54/tcj_54_January-February_1992_djvu.txt][https://archive.org/download/the-computer-journal-54/tcj_54_January-February_1992_text.pdf][https://web.archive.org/web/20170831184437/http://gaby.de/ftp/pub/cpm/znode51/articles/tcj/tcj54.ws] {{cite journal |title=Type-3 and Type-4 Programs |series=Z-System Corner – Some New Applications of Type-4 Programs |author-first=Jay |author-last=Sage |journal=[The Computer Journal](/source/The_Computer_Journal_(US_journal)%3C!--_to_be_distinguished_from_the_identically_named_UK_journal_--%3E) (TCJ) – Programming, User Support, Applications |issn=0748-9331 |editor-first1=Art |editor-last1=Carlson |editor-first2=Chris |editor-last2=McEwen |date=May–June 1992 |orig-date=March–June 1992 |publisher=Socrates Press |location=S. Plainfield, New Jersey, USA |issue=55 |pages=[https://archive.org/details/the-computer-journal-55/page/n14/mode/1up 13]–19 |id=ark:/13960/t4dn54d22 |url=https://archive.org/details/the-computer-journal-55 |access-date=2021-11-29}} [https://archive.org/stream/the-computer-journal-55/tcj_55_March-June_1992_djvu.txt][https://archive.org/download/the-computer-journal-55/tcj_55_March-June_1992_text.pdf] {{cite book |title=The Worm Memory Test |publisher=[Vector Graphic](/source/Vector_Graphic) |date=2015-10-21 |orig-date= |url=http://deramp.com/downloads/vector_graphic/software/manuals/Worm.pdf |access-date=2021-12-13 |url-status=live |archive-url=https://web.archive.org/web/20190515181617/http://deramp.com/downloads/vector_graphic/software/manuals/Worm.pdf |archive-date=2019-05-15}} (3 pages) (NB. From a [Vector Graphic 3](/source/Vector_Graphic_3) service manual.) {{cite web |title=The H89 Worm: Memory Testing the H89 |author-first=William "Bill" Albert |author-last=Wilkinson |date=2003 |orig-date=1996, 1984 |work=Bill Wilkinson's Heath Company Page |url=https://www.heco.wxwilki.com/h89worm.html |access-date=2021-12-13 |url-status=live |archive-url=https://web.archive.org/web/20211213130013/https://www.heco.wxwilki.com/h89worm.html |archive-date=2021-12-13 |quote=[…] Besides fetching an instruction, the [Z80](/source/Z80) uses half of the cycle to [refresh](/source/RAM_refresh) the [dynamic RAM](/source/dynamic_RAM). […] since the Z80 must spend half of each [instruction fetch](/source/instruction_fetch) cycle performing other chores, it doesn't have as much time to fetch an [instruction byte](/source/instruction_byte) as it does a data byte. If one of the [RAM chip](/source/RAM_chip)s at the memory location being accessed is a little slow, the Z80 may get the wrong bit pattern when it fetches an instruction, but get the right one when it reads data. […] the built-in memory test won't catch this type of problem […] it's strictly a data read/write test. During the test, all instruction fetches are from the [ROM](/source/ROM), not from RAM […] result[ing] in the [H89](/source/Heath_H89) passing the memory test but still operating erratically on some programs. […] This is a program that tests memory by relocating itself through RAM. As it does so, the CPU prints the current address of the program on the [CRT](/source/cathode-ray_tube) and then fetches the instruction at that address. If the RAM ICs are okay at that address, the CPU relocates the test program to the next memory location, prints the new address, and repeats the procedure. But, if one of the RAM ICs is slow enough to return an incorrect bit pattern, the CPU will misinterpret the instruction and behave unpredictably. However, it's likely that the display will lock up showing the address of faulty IC. This narrows the problem down eight ICs, which is an improvement over having to check as much as 32. […] The […] program will perform a [worm test](/source/worm_test) by pushing an RST 7 (RESTART 7) instruction from the low end of memory on up to the last working address. The rest of the program remains stationary and handles the display of the current location of the RST 7 command and its [relocation](/source/relocation_(computing)). Incidentally, the program is called a worm test because, as the RST 7 instruction moves up through memory, it leaves behind a [slime trail](/source/NOP_trail) of [NOP](/source/NOP_(code))s (NO OPERATION). […]}} {{cite journal |title=The Worm Memory Test |author-first=Jan W. |author-last=Steinman |location=West Linn, Oregon, USA |journal=[Dr. Dobb's Journal of Software Tools for the Professional Programmer](/source/Dr._Dobb's_Journal_of_Software_Tools_for_the_Professional_Programmer) |publisher=[M&T Publishing, Inc.](/source/M%26T_Publishing%2C_Inc.) / [The People's Computer Company](/source/The_People's_Computer_Company) |publication-place=Redwood City, California, USA |department=The Right to Assemble (TRTA) |volume=11 |issue=9 |id=#119. ark:/13960/t74v34p9p {{CODEN|DDJOEB}} |issn=1044-789X |date=1986-09-01 |pages=114–115 (662–663) |url=https://archive.org/details/dr_dobbs_journal_vol_11/page/662/mode/1up |access-date=2021-12-13}} [https://ia803109.us.archive.org/13/items/dr_dobbs_journal_vol_11/dr_dobbs_journal_vol_11.pdf] (2 pages) {{cite book |title=Dr. Dobb's Toolbook of 68000 Programming |chapter=III. Useful 68000 Routines and Techniques, 16. The Worm Memory Test |author-first=Jan W. |author-last=Steinman |location=West Linn, Oregon, USA |publisher=[Brady Book](/source/Brady_Book) / [Prentice Hall Press](/source/Prentice_Hall_Press) / [Simon & Schuster, Inc.](/source/Simon_%26_Schuster%2C_Inc.) |publication-place=New York, USA |date=1986 |pages=341–350 |lccn=86-25308 |isbn=0-13-216649-6 |chapter-url=http://www.bytesmiths.com/Publications/Worm%20Memory%20Test%20-%20Steinman_1986-01-01-1.pdf |access-date=2021-12-13 |url-status=live |archive-url=https://web.archive.org/web/20211213202006/http://www.bytesmiths.com/Publications/Worm%20Memory%20Test%20-%20Steinman_1986-01-01-1.pdf |archive-date=2021-12-13}} (1+5+10+1 pages) }} == Further reading == * {{cite journal |title=DOSPLUS 3.5 |series=Review |author-first=John B. |author-last=Harrell III |journal=[80 Micro](/source/80_Micro) |publisher=[1001001, Inc.](/source/1001001%2C_Inc.) |issn=0744-7868 |issue=45 |date=October 1983 |pages=160, 162, 164–168, 170 |id=ark:/13960/t8z906r42 |url=https://archive.org/details/80-microcomputing-magazine-1983-10 |access-date=2020-02-06 }} [https://archive.org/stream/80-microcomputing-magazine-1983-10/80Microcomputing_1083_djvu.txt][https://archive.org/download/80-microcomputing-magazine-1983-10/80Microcomputing_1083_text.pdf] * {{cite book |title=RISC OS Application Image Format (previously Arthur Image Format) |type=Technical Memorandum |author-first1=Lee |author-last1=Smith |author-first2=Lionel |author-last2=Haines |publisher=[Acorn Computers Limited](/source/Acorn_Computers_Limited), Programming Languages Group |location=Cambridge, UK |date=1989-02-02 |orig-date=1987-08-14 |edition=1.00 |id=PLG-AIF |url=http://www.chiark.greenend.org.uk/~theom/riscos/docs/CodeStds/AIF-1989.txt |access-date=2017-08-30 |url-status=live |archive-url=https://web.archive.org/web/20170830204120/http://www.chiark.greenend.org.uk/~theom/riscos/docs/CodeStds/AIF-1989.txt |archive-date=2017-08-30}} * {{cite book |title=Properties of ARM Image Format |date=1993 |url=http://www.chiark.greenend.org.uk/~theom/riscos/docs/CodeStds/AIF-1993.txt |access-date=2017-08-31 |url-status=live |archive-url=https://web.archive.org/web/20170831031012/http://www.chiark.greenend.org.uk/~theom/riscos/docs/CodeStds/AIF-1993.txt |archive-date=2017-08-31}} * {{cite web |title=Nachladbare Treiber unter CP/M – PRL2COM |language=de |date=2016-08-14 |author-first=Alex |author-last=Huck |work=Homecomputer DDR |url=http://hc-ddr.hucki.net/wiki/doku.php/cpm/rsm#prl2com |access-date=2020-02-21 |url-status=live |archive-url=https://web.archive.org/web/20200221030347/http://hc-ddr.hucki.net/wiki/doku.php/cpm/rsm#prl2com |archive-date=2020-02-21 |postscript=;}} {{cite web |title=PRL2COM |language=de |date=2017-04-24 |orig-date=2012-02-20, 2009, 2002, 1988-07-26, 1987-10-11 |author-first=Volker |author-last=Pohlers |work=Homecomputer DDR |url=http://hc-ddr.hucki.net/wiki/lib/exe/fetch.php/cpm/prl2com.zip |access-date=2020-02-21 |url-status=live |archive-url=https://web.archive.org/web/20200221030941/http://hc-ddr.hucki.net/wiki/lib/exe/fetch.php/cpm/prl2com.zip |archive-date=2020-02-21}} Category:Computer programming --- Adapted from the Wikipedia article [Self-relocation](https://en.wikipedia.org/wiki/Self-relocation) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/Self-relocation?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.