Talk:Relocation (computing)

Undiscussed aspect of relocation.

It seems to me that an important part of relocation isn't discussed in this article. That being, the nature of some processors, that they often include absolute addresses within their machine encodings, and that sometimes, these too must be altered in order for a program to properly execute. For instance, all programs written for the 6502 microprocessor execute at one base address, and if loaded to a different base address, must have the absolute addresses expressed in their instructions altered so as to be properly executable at this new base address. William R. Buckley (talk) 18:01, 29 July 2008 (UTC)[reply]

Different types of relocation

The article misses the different types of relocation:

Static relocation
Dynamic relocation —Preceding unsigned comment added by 213.22.75.98 (talk) 16:02, 29 November 2008 (UTC)[reply]

Merge Rebasing

The article Rebasing survived an AfD Wikipedia:Articles for deletion/Rebasing. I argued for merging into this article, and there was some agreement there. Both articles are stubs and a merged article would be stronger and eventually cover the concepts of compile-time, static, dynamic, run-time, and virtual relocation. And rebasing. — Becksguy (talk) 03:39, 14 September 2010 (UTC)[reply]

I am in agreement with this suggestion, that Rebasing be merged with Relocation (computer science). Doing so will improve the quality of discussion of each process. Making this merge will I think require some creative writing, as the present articles have some disparity of content. William R. Buckley (talk) 21:06, 1 October 2010 (UTC)[reply]

Agree; rebasing is just relocation. IBM VM users do this manually when building DCSS's (Discontinuous Saved Segments), which are just another form of shared libraries. The programmer creating the DCSS is responsible for manually defining the load address to avoid conflicts. The key point of relocation is that compiled code assumes some load address, usually zero, and then has to be modified, whether by the linker, the loader, or by itself to run at a different address. I think all types of relocation should be included here as subtopics. I also suggest the article contain an example of how relocation is accomplshed.Peter Flass (talk) 13:43, 9 November 2011 (UTC)[reply]

Terms should be taken literally

Rebasing is rebasing and relocation is relocation; if in some context you call the same thing rebasing, then it's rebasing, because everyone calls it that way. It's not Wikipedia's pedagological responsibility to tell people which words to use. Of course, there are two equally good options (in my opinion):

merge them but indicate clearly in which context either word is used, or when both are appropriate
keep separate articles, add link to the other

--Sigmundur (talk) 13:55, 4 February 2011 (UTC)[reply]

Computer science?

I propose a merger with Relocation table, my reasons being, I believe, pretty obvious and uncontroversial. I also think the article's title should be Relocation (computing), as the subject is a technical concept, rather than a theoretical one. Ian (178.37.148.53 (talk) 16:02, 4 September 2011 (UTC))[reply]

Merging Relocation table into Relocation (computer science) sounds good. Renaming to computing seems reasonable, though less important. Make it so! Vadmium (talk) 01:01, 5 September 2011 (UTC).[reply]

Done.Peter Flass (talk) 01:05, 12 November 2011 (UTC)[reply]

definition of relocation

This is simply not true: "In computer science, relocation is the process of replacing symbolic references or names of libraries with actual usable addresses in memory before running a program." Relocation has nothing to do with symbolic references.

I also tinkered with the "self-relocation" article, and now have the opinion that it should be merged here into a general discussion of various types of relocation.Peter Flass (talk) 13:31, 9 November 2011 (UTC)[reply]

This is somewhat dependent, but in many cases it is true. The common system where you separately compile source programs into object programs, and then later link them together, requires relocation at link time. Well, I got here while looking at address constant, and the process of resolving address constants. And also, that there are no articles for external symbol or relocation dictionary, which are needed to explain address constants. Now, one problem is that the address constant article is somewhat OS/360 oriented, but I believe that the ideas apply to other systems. Consider V-type address constants, which do exactly what you say they don't do. At compile time, it is only the symbolic reference that is known, and at link time they are (usually) resolved.

Some time ago, wondering how different systems did it, I was mentioning that the OS/360 linker allows relocation factors of (-1) and (2), in addition to the commonly used (0) and (1). Wondering how some others did it, someone mentioned a PDP/11 OS that allows for even more complicated relocation, there the compilers or assemblers pretty much put a program to do the relocation into the object module. V-type adcons assemble as 0, and at link time an actual address is placed there, using the external symbol dictionary. It also goes into the relocation dictionary for later relocation at relinking or program fetch.

Now, the reason I am writing this, is that there are no articles for external symbol or relocation dictionary. Specifically, they are needed to explain the way different systems do similar things. Gah4 (talk) 12:32, 23 January 2024 (UTC)[reply]

Example

Previously I suggested an example to illustrate relocation. I tinkered one up myself (below). Rather than add it to the article I thought I'd but it here for discussion.

Seeing no discussion I've touched up the example a bit and added it to the article. Peter Flass (talk) 23:22, 12 May 2013 (UTC)[reply]

Example of relocation

This example uses Donald Knuth's MIX architecture and MIXAL assembly language. The principles are the same for any architecture, though the details will change.

(A) Program SUBR is compiled to produce object file(B), shown as both machine code and assembler. The compiler may start the compiled code at an arbitrary location, say location zero. Location 13 contains the machine code for the jump instruction to statement ST in location 5.
(C) If SUBR is later linked with other code it may no longer start at location zero. In this example the linker places it at location 120. The address in the jump instruction, now at 133, must be relocated to point to the new location of the code for statement ST, now 125. [1 61 shown in the instruction is the MIX machine code representation of 125].
(D) When the program is loaded into memory to run it may be loaded at some location other than the one assigned by the linker. This example shows SUBR now at location 300. The address in the jump instruction, now at 313, needs to be relocated again so that it points to the updated location of ST, 305. [4 49 is the MIX machine representation of 305].

Peter Flass (talk) 02:44, 11 November 2011 (UTC)[reply]