Self-relocation

Last updated

In computer programming, a self-relocating program is a program that relocates its own address-dependent instructions and data when run, and is therefore capable of being loaded into memory at any address. [1] [2] In many cases, self-relocating code is also a form of self-modifying code.

Contents

Overview

Self-relocation is similar to the relocation process employed by the linker-loader 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 or shell 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 (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. [3] [4]

Examples

Boot loaders

As an example, self-relocation is often employed in the early stages of bootstrapping operating systems on architectures like IBM PC compatibles, where lower-level chain boot loaders (like the master boot record (MBR), volume boot record (VBR) and initial boot stages of operating systems such as DOS) move themselves out of place in order to load the next stage into memory.

CP/M extensions

Under CP/M, the debugger Dynamic Debugging Tool (DDT) dynamically relocated itself to the top of available memory through page boundary relocation in order to maximize the Transient Program Area (TPA) for programs to run in. [5] [6]

In 1988, the alternative command line processor ZCPR 3.4 for the Z-System introduced so called type-4 programs which were self-relocatable through an embedded stub as well. [7] [8] [9] [10] [11]

x86 DOS drivers

Under DOS, self-relocation is sometimes also used by more advanced drivers and resident system extensions (RSXs) or terminate-and-stay-resident programs (TSRs) loading themselves "high" into upper memory more effectively than possible for externally provided "high"-loaders (like LOADHIGH/HILOAD, INSTALLHIGH/HIINSTALL or DEVICEHIGH/HIDEVICE etc. [12] 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 (PSP) and an environment segment. [13] 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) 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 and avoid fragmentation. [14] 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. [4] Finally, it is technically impossible for an external loader to relocate drivers into expanded memory (EMS), the high memory area (HMA) or extended memory (via DPMS or CLOAKING), because these methods require small driver-specific stubs to remain in conventional or upper memory in order to coordinate the access to the relocation target area, [15] [nb 1] [nb 2] and in the case of device drivers also because the driver's header must always remain in the first megabyte. [15] [13] In order to achieve this, the drivers must be specially designed to support self-relocation into these areas. [15]

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. [13] If the shared code is not designed to be position-independent, it requires some form of internal address fix-up similar to what would otherwise have been carried out by a 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 DOS/360 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). A special class of programs, called self-relocating programs, were coded to relocate themselves after loading. [16] IBM OS/360 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).

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 tests. [17] [18] [19] [20] The Apple Worm is a dynamic self-relocator as well. [21]

See also

Notes

  1. ↑ An exception to the requirement for a stub is when expanded memory is converted into permanent upper memory by the memory manager via EMSUMB, and thus it is effectively accessed as upper memory, not via EMS.
  2. ↑ There are two exceptions to the stub requirement for a driver to load into the HMA: A stub is not necessary when high memory is permanently enabled on machines without 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 and higher, when resident system extensions (like SHARE and NLSFUNC) only hook the multiplex interrupt INT 2Fh, because they can then utilize a backdoor interface to hook into the interrupt chain in kernel space so that the kernel's gate A20 handler will provide the functionality of the stub. [a] Still, the driver has to perform self-relocation in order to function correctly in the HMA.

Related Research Articles

<span class="mw-page-title-main">Booting</span> Process of starting a computer

In computing, booting is the process of starting a computer as initiated via hardware such as a button or by a software command. After it is switched on, a computer's central processing unit (CPU) has no software in its main memory, so some process must load software into memory before it can be executed. This may be done by hardware or firmware in the CPU, or by a separate processor in the computer system.

A terminate-and-stay-resident program is a computer program running under DOS that uses a system call to return control to DOS as though it has finished, but remains in computer memory so it can be reactivated later. This technique partially overcame DOS's limitation of executing only one program, or task, at a time. TSRs are used only in DOS, not in Windows.

Bytecode is a form of instruction set designed for efficient execution by a software interpreter. Unlike human-readable source code, bytecodes are compact numeric codes, constants, and references that encode the result of compiler parsing and performing semantic analysis of things like type, scope, and nesting depths of program objects.

In computer science, dynamic recompilation is a feature of some emulators and virtual machines, where the system may recompile some part of a program during execution. By compiling during execution, the system can tailor the generated code to reflect the program's run-time environment, and potentially produce more efficient code by exploiting information that is not available to a traditional static compiler.

In computer science, self-modifying code is code that alters its own instructions while it is executing – usually to reduce the instruction path length and improve performance or simply to reduce otherwise repetitively similar code, thus simplifying maintenance. The term is usually only applied to code where the self-modification is intentional, not in situations where code accidentally modifies itself due to an error such as a buffer overflow.

<span class="mw-page-title-main">A20 line</span> Signal in the system bus of an x86-based computer system

The A20, or address line 20, is one of the electrical lines that make up the system bus of an x86-based computer system. The A20 line in particular is used to transmit the 21st bit on the address bus.

<span class="mw-page-title-main">DOS memory management</span> Techniques employed to give applications access to more than 640 kibibytes

In IBM PC compatible computing, DOS memory management refers to software and techniques employed to give applications access to more than 640 kibibytes (KiB) of "conventional memory". The 640 KiB limit was specific to the IBM PC and close compatibles; other machines running MS-DOS had different limits, for example the Apricot PC could have up to 768 KiB and the Sirius Victor 9000, 896 KiB. Memory management on the IBM family was made complex by the need to maintain backward compatibility to the original PC design and real-mode DOS, while allowing computer users to take advantage of large amounts of low-cost memory and new generations of processors. Since DOS has given way to Microsoft Windows and other 32-bit operating systems not restricted by the original arbitrary 640 KiB limit of the IBM PC, managing the memory of a personal computer no longer requires the user to manually manipulate internal settings and parameters of the system.

<span class="mw-page-title-main">Conventional memory</span> First 640K of RAM under DOS

In DOS memory management, conventional memory, also called base memory, is the first 640 kilobytes of the memory on IBM PC or compatible systems. It is the read-write memory directly addressable by the processor for use by the operating system and application programs. As memory prices rapidly declined, this design decision became a limitation in the use of large memory capacities until the introduction of operating systems and processors that made it irrelevant.

<span class="mw-page-title-main">High memory area</span>

In DOS memory management, the high memory area (HMA) is the RAM area consisting of the first 65520 bytes above the one megabyte in an IBM AT or compatible computer.

In compiler theory, dead-code elimination is a compiler optimization to remove dead code. Removing such code has several benefits: it shrinks program size, an important consideration in some contexts, and it allows the running program to avoid executing irrelevant operations, which reduces its running time. It can also enable further optimizations by simplifying program structure. Dead code includes code that can never be executed, and code that only affects dead variables, that is, irrelevant to the program.

In computer systems a loader is the part of an operating system that is responsible for loading programs and libraries. It is one of the essential stages in the process of starting a program, as it places programs into memory and prepares them for execution. Loading a program involves either memory-mapping or copying the contents of the executable file containing the program instructions into memory, and then carrying out other required preparatory tasks to prepare the executable for running. Once loading is complete, the operating system starts the program by passing control to the loaded program code.

In computing, position-independent code (PIC) or position-independent executable (PIE) is a body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address. PIC is commonly used for shared libraries, so that the same library code can be loaded at a location in each program's address space where it does not overlap with other memory in use by, for example, other shared libraries. PIC was also used on older computer systems that lacked an MMU, so that the operating system could keep applications away from each other even within the single address space of an MMU-less system.

A fat binary is a computer executable program or library which has been expanded with code native to multiple instruction sets which can consequently be run on multiple processor types. This results in a file larger than a normal one-architecture binary file, thus the name.

<span class="mw-page-title-main">COM file</span> Type of simple executable file

A COM file is a type of simple executable file. On the Digital Equipment Corporation (DEC) VAX operating systems of the 1970s, .COM was used as a filename extension for text files containing commands to be issued to the operating system. With the introduction of Digital Research's CP/M, the type of files commonly associated with COM extension changed to that of executable files. This convention was later carried over to DOS. Even when complemented by the more general EXE file format for executables, the compact COM files remained viable and frequently used under DOS.

<span class="mw-page-title-main">Bootloader</span> Software responsible for starting the computer and load other software to the CPU memory

A bootloader, also spelled as boot loader or called boot manager and bootstrap loader, is a computer program that is responsible for booting a computer.

<span class="mw-page-title-main">IBMBIO.COM</span> System file (DOS BIOS) in PC DOS and DR-DOS

IBMBIO.COM is a system file in many DOS operating systems. It contains the system initialization code and all built-in device drivers. It also loads the DOS kernel (IBMDOS.COM) and optional pre-loadable system components, displays boot menus, processes configuration files and launches the shell.

Executable compression is any means of compressing an executable file and combining the compressed data with decompression code into a single executable. When this compressed executable is executed, the decompression code recreates the original code from the compressed code before executing it. In most cases this happens transparently so the compressed executable can be used in exactly the same way as the original. Executable compressors are often referred to as "runtime packers", "software packers", "software protectors".

Relocation is the process of assigning load addresses for position-dependent code and data of a program and adjusting the code and data to reflect the assigned addresses. Prior to the advent of multiprocess systems, and still in many embedded systems, the addresses for objects were absolute starting at a known location, often zero. Since multiprocessing systems dynamically link and switch between programs it became necessary to be able to relocate objects using position-independent code. A linker usually performs relocation in conjunction with symbol resolution, the process of searching files and libraries to replace symbolic references or names of libraries with actual usable addresses in memory before running a program.

<span class="mw-page-title-main">Overlay (programming)</span>

In a general computing sense, overlaying means "the process of transferring a block of program code or other data into main memory, replacing what is already stored". Overlaying is a programming method that allows programs to be larger than the computer's main memory. An embedded system would normally use overlays because of the limitation of physical memory, which is internal memory for a system-on-chip, and the lack of virtual memory facilities.

<span class="mw-page-title-main">DOS</span> Group of closely related IBM PC-compatible operating systems

DOS is a family of disk-based operating systems for IBM PC compatible computers. The DOS family primarily consists of IBM PC DOS and a rebranded version, Microsoft's MS-DOS, both of which were introduced in 1981. Later compatible systems from other manufacturers include DR-DOS (1988), ROM-DOS (1989), PTS-DOS (1993), and FreeDOS (1998). MS-DOS dominated the IBM PC compatible market between 1981 and 1995.

References

  1. ↑ Dhamdhere, Dhananjay M. (1999). Systems Programming and Operating Systems. Education. New Delhi, India: Tata McGraw-Hill. p. 232. ISBN   0-07-463579-4. ISBN   978-0-07-463579-7. Archived from the original on 2020-02-01. Retrieved 2011-11-08. (658 pages)
  2. ↑ Dhamdhere, Dhananjay M. (2006). Operating Systems: A Concept-based Approach. Education. New Delhi, India: Tata McGraw-Hill. p. 231. ISBN   0-07-061194-7. ISBN   978-0-07-061194-8. Archived from the original on 2020-02-20. Retrieved 2020-02-20. (799 pages)
  3. ↑ Paul, Matthias R.; Frinke, Axel C. (1997-10-13) [1991], FreeKEYB - Enhanced DOS keyboard and console driver (User Manual) (6.5 ed.) (NB. FreeKEYB is a Unicode-based dynamically configurable driver supporting most keyboard layouts, code pages, and country codes. Utilizing an off-the-shelf macro assembler as well as a framework of automatic pre- and post-processing analysis tools to generate dependency and code morphing meta data to be embedded into the executable file alongside the binary code and a self-discarding, relaxing and relocating loader, the driver supports to be variously loaded and install itself as TSR or device driver and it implements advanced self-relocation techniques (including into normal DOS memory, UMBs, unused video memory, or raw memory also utilizing program segment prefix overloading and environment segment recombination) and byte-level granular dynamic dead code elimination at load-time as well as self-modifying code and reconfigurability at run-time to minimize its memory footprint depending on the hardware, operating system and driver configuration as well as the selected feature set and locale.)
  4. 1 2 Paul, Matthias R.; Frinke, Axel C. (2006-01-16), FreeKEYB - Advanced international DOS keyboard and console driver (User Manual) (7 (preliminary) ed.)
  5. ↑ Kildall, Gary Arlen (February 1978) [1976]. "A simple technique for static relocation of absolute machine code". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia . People's Computer Company. 3 (2): 10–13 (66–69). ISBN   0-8104-5490-4. #22 ark:/13960/t8hf1g21p. Retrieved 2017-08-19. . Originally presented at: Kildall, Gary Arlen (1977) [22–24 November 1976]. "A Simple Technique for Static Relocation of Absolute Machine Code". Written at Naval Postgraduate School, Monterey, California, USA. In Titus, Harold A. (ed.). Conference Record: Tenth Annual Asilomar Conference on Circuits, Systems and Computers: Papers Presented November 22–24, 1976. Asilomar Hotel and Conference Grounds, Pacific Grove, California, USA: Western Periodicals Company. pp. 420–424. ISSN   1058-6393 . Retrieved 2021-12-06. (609 pages). (This "resize" method, named page boundary relocation , could be applied statically to a CP/M-80 disk image using MOVCPM  [ pl ] in order to maximize the TPA for programs to run. It was also utilized dynamically by the CP/M debugger Dynamic Debugging Tool (DDT) to relocate itself into higher memory. The same approach was independently developed by Bruce H. Van Natta of IMS Associates to produce relocatable PL/M code. As paragraph boundary relocation another variant of this method was later utilized by dynamically HMA self-relocating TSRs like KEYB, SHARE, and NLSFUNC under DR DOS 6.0 and higher. A much more sophisticated and byte-level granular 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 to dynamically minimize the runtime footprint of resident drivers and TSRs (like FreeKEYB).)
  6. ↑ Huitt, Robert; Eubanks, Gordon; Rolander, Thomas "Tom" Alan; Laws, David; Michel, Howard E.; Halla, Brian; Wharton, John Harrison; Berg, Brian; Su, Weilian; Kildall, Scott; Kampe, Bill (2014-04-25). Laws, David (ed.). "Legacy of Gary Kildall: The CP/M IEEE Milestone Dedication" (PDF) (video transscription). Pacific Grove, California, USA: Computer History Museum. CHM Reference number: X7170.2014. Archived (PDF) from the original on 2014-12-27. Retrieved 2020-01-19. […] Laws: […] "dynamic relocation" of the OS. Can you tell us what that is and why it was important? […] Eubanks: […] what Gary did […] was […] mind boggling. […] I remember the day at the school he came bouncing into the lab and he said, I have figured out how to relocate. He took advantage of the fact that the only byte was always going to be the high order byte. And so he created a 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 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 […] had the bytes reversed, right, for the memory addresses. But they were always in the same place, so you could relocate it on a 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 […] (33 pages)
  7. ↑ Sage, Jay (May–June 1988). Carlson, Art (ed.). "ZCPR 3.4 - Type-4 Programs". The Computer Journal (TCJ) - Programming, User Support, Applications. ZCPR3 Corner. Columbia Falls, Montana, USA (32): 10–17. ISSN   0748-9331. ark:/13960/t1wd4v943. Retrieved 2021-11-29.
  8. ↑ Mitchell, Bridger (July–August 1988). Carlson, Art (ed.). "Z3PLUS & Relocation - Information on ZCPR3PLUS, and how to write self relocating Z80 code". The Computer Journal (TCJ) - Programming, User Support, Applications. Advanced CP/M. Columbia Falls, Montana, USA (33): 9–15. ISSN   0748-9331. ark:/13960/t36121780. Retrieved 2020-02-09.
  9. ↑ Sage, Jay (September–October 1988). Carlson, Art (ed.). "More on relocatable code, PRL files, ZCPR34, and Type-4 programs". The Computer Journal (TCJ) - Programming, User Support, Applications. ZCPR3 Corner. Columbia Falls, Montana, USA (34): 20–25. ISSN   0748-9331. ark:/13960/t0ks7pc39. Retrieved 2020-02-09.
  10. ↑ Sage, Jay (January–February 1992). Carlson, Art; McEwen, Chris (eds.). "Ten Years of ZCPR". The Computer Journal (TCJ) - Programming, User Support, Applications. Z-System Corner. S. Plainfield, New Jersey, USA: Socrates Press (54): 3–7. ISSN   0748-9331. ark:/13960/t89g6n689. Retrieved 2021-11-29.
  11. ↑ Sage, Jay (May–June 1992) [March–June 1992]. Carlson, Art; McEwen, Chris (eds.). "Type-3 and Type-4 Programs". The Computer Journal (TCJ) - Programming, User Support, Applications. Z-System Corner - Some New Applications of Type-4 Programs. S. Plainfield, New Jersey, USA: Socrates Press (55): 13–19. ISSN   0748-9331. ark:/13960/t4dn54d22. Retrieved 2021-11-29.
  12. ↑ "Chapter 10 Managing Memory". Caldera DR-DOS 7.02 User Guide. Caldera, Inc. 1998 [1993, 1997]. Archived from the original on 2017-08-30. Retrieved 2017-08-30.
  13. 1 2 3 Paul, Matthias R. (2002-04-06). "Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1". freedos-dev. Archived from the original on 2020-02-07. Retrieved 2020-02-07. […] Add a SYS device driver header to the driver, so that CTMOUSE could be both in one, a normal TSR and a device driver - similar to our FreeKEYB advanced keyboard driver. […] This is not really needed under DR DOS because INSTALL= is supported since DR DOS 3.41+ and DR DOS preserves the order of [D]CONFIG.SYS directives […] but it would […] improve the […] flexibility on MS-DOS/PC DOS systems, which […] always execute DEVICE= 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" for 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, no PSP) […] 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 […]
  14. ↑ Paul, Matthias R. (2001-08-18). "Re: [fd-dev] On GRAFTABL and DISPLAY.SYS (Was: Changing codepages in FreeDOS)". freedos-dev. Archived from the original on 2017-09-04. Retrieved 2017-09-04. […] At least the MS-DOS 6.0+ GRAFTABL relocates itself over parts of its PSP segment (offset +60h and upwards) to minimize its resident size. […] (NB. A post-DR-DOS 7.03 GRAFTABL 2.00+ supports dynamic self-relocation as well.)
  15. 1 2 3 Paul, Matthias R. (2002-02-02). "Treiber dynamisch nachladen" [Loading drivers dynamically] (in German). Newsgroup:  de.comp.os.msdos. Archived from the original on 2017-09-09. Retrieved 2017-07-02. (NB. Gives an overview on load-high methods under DOS, including the usage of LOADHIGH etc. commands and self-relocating methods into UMBs utilizing the XMSUMB API. It also discusses more sophisticated methods necessary for TSRs to relocate into the HMA utilizing intra-segment offset relocation.)
  16. ↑ Boothe Management Systems (1972-11-01). "Throughput - Are you getting all you deserve? - DOSRELO". Computerworld - The Newsweekly For The Computer Community (advertisement). Vol. VI, no. 44. San Francisco, California, USA: Computerworld, Inc. p. 9. Archived from the original on 2020-02-06. Retrieved 2020-02-07. […] DOSRELO provides a method of making DOS 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 of the program before the Linkage Editor catalogs it on the Core Image Library. […]
  17. ↑ The Worm Memory Test (PDF). Vector Graphic. 2015-10-21. Archived (PDF) from the original on 2019-05-15. Retrieved 2021-12-13. (3 pages) (NB. From a Vector Graphic 3 service manual.)
  18. ↑ Wilkinson, William "Bill" Albert (2003) [1996, 1984]. "The H89 Worm: Memory Testing the H89". Bill Wilkinson's Heath Company Page. Archived from the original on 2021-12-13. Retrieved 2021-12-13. […] Besides fetching an instruction, the Z80 uses half of the cycle to refresh the dynamic RAM. […] since the Z80 must spend half of each instruction fetch cycle performing other chores, it doesn't have as much time to fetch an instruction byte as it does a data byte. If one of the RAM chips 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, not from RAM […] result[ing] in the 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 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 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. Incidentally, the program is called a worm test because, as the RST 7 instruction moves up through memory, it leaves behind a slime trail of NOPs (NO OPERATION). […]
  19. ↑ Steinman, Jan W. (1986-09-01). Written at West Linn, Oregon, USA. "The Worm Memory Test". The Right to Assemble (TRTA). Dr. Dobb's Journal of Software Tools for the Professional Programmer . Redwood City, California, USA: M&T Publishing, Inc. / The People's Computer Company. 11 (9): 114–115 (662–663). ISSN   1044-789X. #119. ark:/13960/t74v34p9p CODEN   DDJOEB . Retrieved 2021-12-13. (2 pages)
  20. ↑ Steinman, Jan W. (1986). "III. Useful 68000 Routines and Techniques, 16. The Worm Memory Test" (PDF). Written at West Linn, Oregon, USA. Dr. Dobb's Toolbook of 68000 Programming. New York, USA: Brady Book / Prentice Hall Press / Simon & Schuster, Inc. pp. 341–350. ISBN   0-13-216649-6. LCCN   86-25308. Archived (PDF) from the original on 2021-12-13. Retrieved 2021-12-13. (1+5+10+1 pages)
  21. ↑ Dewdney, Alexander Keewatin (March 1985). "Computer Recreations - A Core War bestiary of viruses, worms and other threats to computer memories". Scientific American . 285: 38–39. Archived from the original on 2017-07-04. Retrieved 2017-07-04.

Further reading

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.