title: Confusions about address binding
body: <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>