Editing Position-independent code (section)

== History ==
In early computers such as the [[IBM 701]]<ref name="IBM_1952_701"/> (29 April 1952) or the [[UNIVAC I]] (31 March 1951) code was not position-independent: each program was built to load into and run from a particular address. Those early computers did not have an operating system and were not multitasking-capable. Programs were loaded into main storage (or even stored on magnetic drum for execution directly from there) and run one at a time. In such an operational context, position-independent code was not necessary.

Even on  [[base and bounds]]{{efn|name="NB_BNB"}} systems such as the [[CDC 6600]], the [[GE-600 series|GE 625]] and the [[UNIVAC 1107]], once the OS loaded code into a job's storage, it could only run from the relative address at which it was loaded.

[[Burroughs Corporation|Burroughs]] introduced a [[Memory segmentation|segmented]] system, the [[B5000]] (1961), in which programs addressed segments indirectly via control words on the [[call stack|stack]] or in the program reference table (PRT); a shared segment could be addressed via different PRT locations in different processes. Similarly, on the later [[B6500]], all segment references were via positions in a [[stack frame]].

The [[IBM System/360 architecture|IBM System/360]] (7 April 1964) was designed with [[IBM System/360 architecture#Addressing|truncated addressing]]  similar to that of the [[UNIVAC III]],<ref name="Sperry_1962"/> with code position independence in mind. In truncated addressing, memory addresses are calculated from a ''base register'' and an offset. At the beginning of a program, the programmer must establish ''addressability'' by loading a base register; normally, the programmer also informs the assembler with a ''USING'' pseudo-op. The programmer can load the base register from a register known to contain the entry point address, typically R15, or can use the [https://en.wikibooks.org/wiki/360_Assembly/360_Instructions/BALR BALR (Branch And Link, Register form)] instruction (with a R2 Value of 0) to store the next sequential instruction's address into the base register, which was then coded explicitly or implicitly in each instruction that referred to a storage location within the program. Multiple base registers could be used, for code or for data. Such instructions require less memory because they do not have to hold a full 24, 31, 32, or 64 bit address (4 or 8 bytes), but instead a base register number (encoded in 4 bits) and a 12–bit address offset (encoded in 12 bits), requiring only two bytes.

This programming technique is standard on IBM S/360 type systems. It has been in use through to today's IBM System/z. When coding in assembly language, the programmer has to establish addressability for the program as described above and also use other base registers for dynamically allocated storage. Compilers automatically take care of this kind of addressing.

IBM's early operating system [[DOS/360]] (1966) was not using virtual storage (since the early models of System S/360 did not support it), but it did have the ability to place programs to an arbitrary (or automatically chosen) storage location during loading via the PHASE name,* [[Job_Control_Language|JCL (Job Control Language)]] statement.

So, on S/360 systems without virtual storage, a program could be loaded at any storage location, but this required a contiguous memory area large enough to hold that program. Sometimes [[Fragmentation (computing)|memory fragmentation]] would occur from loading and unloading differently sized modules. Virtual storage - by design - does not have that limitation.

While DOS/360 and [[OS/360]] did not support PIC, transient [[Supervisor Call instruction#OS/360 and Successor System SVCs|SVC routines]] in OS/360 could not contain relocatable address constants and could run in any of the transient areas without [[relocation (computing) | relocation]].

IBM first introduced virtual storage on [[IBM System/360 Model 67|IBM System/360 model 67]] in (1965) to support IBM's first multi-tasking operating and time-sharing operating system TSS/360. Later versions of DOS/360 (DOS/VS etc.) and later IBM operating systems all utilized virtual storage. Truncated addressing remained as part of the base architecture, and still advantageous when multiple modules must be loaded into the same virtual address space.

By way of comparison, on early [[Memory segmentation|segmented]] systems such as [[Burroughs MCP]] on the [[Burroughs large systems|Burroughs B5000]] (1961) and [[Multics]] (1964), and on paging systems such as IBM [[TSS (operating system)|TSS/360]] (1967){{efn|name="NB_TSS"}}, code was also inherently position-independent, since subroutine virtual addresses in a program were located in private data external to the code, e.g., program reference table, linkage segment, prototype section.

The invention of dynamic address translation (the function provided by an [[Memory management unit|MMU]]) originally reduced the need for position-independent code because every process could have its own independent [[address space]] (range of addresses).  
However, multiple simultaneous jobs using the same code created a waste of physical memory. If two jobs run entirely identical programs, dynamic address translation provides a solution by allowing the system simply to map two different jobs' address 32K to the same bytes of real memory, containing the single copy of the program.

Different programs may share common code. For example, the payroll program and the accounts receivable program may both contain an identical sort subroutine. A shared module (a shared library is a form of shared module) gets loaded once and mapped into the two address spaces.