Instructions that refer directly to specific memory addresses sometimes execute faster, and replacing them with equivalent relative-addressing instructions may result in slightly slower execution, although modern processors make the difference practically negligible.
[4] In early computers such as the IBM 701[5] (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.
Programs were loaded into main storage (or even stored on magnetic drum for execution directly from there) and run one at a time.
The IBM System/360 (7 April 1964) was designed with truncated addressing similar to that of the UNIVAC III,[6] with code position independence in mind.
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.
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,* JCL (Job Control Language) statement.
By way of comparison, on early segmented systems such as Burroughs MCP on the Burroughs B5000 (1961) and Multics (1964), and on paging systems such as IBM TSS/360 (1967)[c], 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.
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.
When a linker links modules to create a shared library, it merges the GOTs and sets the final offsets in code.
[7] Position-independent functions access global data start by determining the absolute address of the GOT given their own current program counter value.
This is specifically targeted at making position-independent code smaller, less register demanding and hence more efficient.
[8] Versions of Windows prior to Vista require that system DLLs be prelinked at non-conflicting fixed addresses at the link time in order to avoid runtime relocation of images.
A call to a procedure saves PR4 in the stack before loading it with a pointer to the callee's linkage segment.
In IBM S/360 Time Sharing System (TSS/360 and TSS/370) each procedure may have a read-only public CSECT and a writable private Prototype Section (PSECT).
PIE binaries are used in some security-focused Linux distributions to allow PaX or Exec Shield to use address space layout randomization (ASLR) to prevent attackers from knowing where existing executable code is during a security attack using exploits that rely on knowing the offset of the executable code in the binary, such as return-to-libc attacks.
)[14] Apple's macOS and iOS fully support PIE executables as of versions 10.7 and 4.3, respectively; a warning is issued when non-PIE iOS executables are submitted for approval to Apple's App Store but there's no hard requirement yet [when?]
[17] Support for PIE in statically linked binaries, such as the executables in /bin and /sbin directories, was added near the end of 2014.