Confusions about address binding
<p><strong>Compile time</strong>. If you know at compile time where the process will reside
in memory, then absolute code can be generated. For example, if you know
that a user process will reside starting at location R, then the generated
compiler code will start at that location and extend up from there. If, at
some later time, the <strong>starting location changes</strong>, then it will be necessary
to recompile this code. The MS-DOS .COM-format programs are bound at
compile time.</p>

<ul>
<li>What can be the reason of the starting location to change? Can it be 
because of context switching/swapping ?</li>
<li>Does absolute code means binary code?</li>
</ul>

<p><strong>Load time.</strong> If it is not known at compile time where the process will reside
in memory, then the compiler must generate relocatable code. In this case,
final binding is delayed until load time. If the starting address changes, we
<strong>need only reload</strong> the user code to incorporate this changed value.</p>

<ul>
<li>How is relocatable code different from absolute code? Does it contain info about base,limit and relocation register?</li>
<li>How is reloading more efficient then recompiling as they mentioned <strong>only</strong> reload means no recompiling only reload?</li>
</ul>

<p><strong>Execution time</strong>. If the process can be moved <strong>during its execution</strong> from
one memory segment to another, then binding must be delayed until run
time. .</p>

<ul>
<li><p>Why it may be needed to move a process during it's execution?</p>

<p><strong>The compile-time and load-time address-binding methods generate
identical logical and physical addresses. However, the execution-time address-binding scheme results in differing logical and physical addresses.</strong></p></li>
<li><p>How compile and load-time methods generate identical logical and physical addresses?</p></li>
</ul>