[Oberon] RiskFive; was Oberon on ULX3S explanation

[Andreas Pirklbauer]

   > I admit that the address fixing is not the easiest part of a compiler and module loader,
   > but it is not undocumented. The first paragraph of  chapter 12.7.9 in this document
   > https://inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf explains what
   > the compiler generates, why its doing it and what fields the module loader has to
   > extract so he can modify the instruction while loading the module from disk to memory.

Jörg,

Thanks for pointing out additional sections in the book which also talk about this topic. I was referring to section 6.3. in the previous msg.

This is probably one area where the book indeed suffers a little bit from the “distributed documentation” syndrome (but at least it’s all contained in a single book!). An alternative way to describe this topic would be to bring all the pieces together and write a paragraph along the following lines:


1. The compiler cannot include absolute addresses in object files, but includes numbers. This is done in order not to violate the basic postulate of modular programming (which states that changes in the implementation must not lead to changes in the interface of a module).

2. The compiler generates the following BL instruction for external procedure call in ORG.Call (containing only numbers!):

     | BL (4) | cond (4) | mno (4) | pno (8) | pc-fixorgP (12) | 

3. Which the module loader will fix up to

     | BL (4) | cond (4) | offset relative to PC (24) | 

using the now know absolute addresses of the referenced module and procedure (these are known only at load time).

-ap