[Oberon] Re (2): "Inner core" and "Outer core".

Wim Niemann niemannw at xs4all.nl
Sun Dec 8 18:28:51 CET 2019

> It has to do with booting the OS:
> 1) If you power-up your machine, the CPU gets initialized and the program counter is set to a specific ROM address
> 2) at this address resides the bootloader in ROM. it loads a few sectors from disk to RAM position 0. In these sectors is the linked inner core
> 3) After sector loading, the bootloader jumps to RAM position 0 and executes the inner core, basically the main body of Modules.Mod
> 4) The inner core loads the rest of the Oberon system (=outer core), basically Oberon.Mod and starts the Oberon loop.

The way I interpret the inner core is:

The compiler has to produce machine language which can run on the target hardware. By using 'MODULE *', version 0 compiler output can run directly on bare metal (e.g. the bootloader) but can not import MODULES.
The Oberon System requires dynamic loading of a module. Thus the compiler outputs .rsc files which support dynamic loading but must be linked and loaded before it can be executed.

**  The inner core contains the minimum functionality which is required to run Modules.Load.  **

When memory is empty after boot, Modules itself is not available to load Modules.rsc. Therefore Modules and its dependencies Kernel, FileDir and Files are pre-loaded as the inner core boot image (exactly like the result of loading Modules.rsc).

This looks like the simplest way of solving the chicken-and-egg problem of loading the dynamic loader at boot.

Now, the inner core uses exactly the same compiler .rsc output as all other modules. You do need a separate Modules.Mod to produce the inner core (CoreLinker.Mod in norebo).

Wim Niemann

More information about the Oberon mailing list