[Oberon] ORL.Mod

Paul Reed paulreed at paddedcell.com
Mon May 19 22:22:45 CEST 2014


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





More information about the Oberon mailing list