[Oberon] ORL.Mod

[Charles Perkins]

Hi Paul,
On May 19, 2014, at 1:22 PM, Paul Reed <paulreed at paddedcell.com> wrote:

> Hi Chuck,
> 
>> What I had hoped to learn from ORL.Mod is the format of the binary image
>> that is laid down in the boot track of the disk or flash card.
> ... I know that the image will contain a sequence of modules and I assume
> they
>> are in this order: Kernel, FileDir, Files, Modules
> ... Chapter 14 in the new Project Oberon book tells me that the boot loader
>> then concludes with a branch to location 0, which will transfer control to
>> the module Modules. So does word 0 contain another branch instruction,
>> this time to the initialization routine for Modules? yes, the body of
> Modules.
> ...  0 - Branch... to the [body] of Modules
> ... 12 - Memory Limit (value overwritten to this offset by the boot loader)
>> 16 - AllocPtr
>> 20 - root of chain of module descriptor pointers? yes
>> 24 -  Limit/Stack/Heap Origin (value overwritten to this offset by the
>> boot loader) yes, the limit of the module area
> ...32 - MT starts here... how big is it?
> 
> Awesome - you've worked out all the details I think.  Each module is
> preceded by its module descriptor (Modules.Module).  MT[0] is the branch
> to a trap handler, so it's not used for linking. MT[1]...MT[n] should be
> the data pointers for each module (corresponding to the descriptor's .data
> field), NOT the descriptor addresses.
> 
> Whether you copy or modify Modules to be a linker is matter of taste,
> probably.  I have a version of Modules which is the linker - loading but
> only calling bodies if it is being called as the module loader, and the
> supplemental linker part patches the module descriptors after the link has
> succeeded, to take account of the offset in memory (the alternative is to
> add an offset in every address calculation, which I didn't think I'd get
> right).  This exploits the fact that (a) the branches are relative, and
> (b) there aren't any extended types in the inner core. Careful if you do
> linking like this in the live system, particularly if a trap occurs, and
> beware of re-usable gaps in the module table, where mod.name = "".
> 
> Great stuff - let me know if you need anything else.  I would strongly
> advise you keep checking your assumptions and make sure your linker can
> create the existing bootfile :)
> Cheers,
> Paul

Thank you, this information is helpful. I'm sure I'll have more
questions, but now I am digging around in the active memory with 
Tools.Inspect and reading the PDFs more closely.

Cheers,
Chuck