[Oberon] Standalone BootLoader format

Andreas Pirklbauer andreas_pirklbauer at yahoo.com
Tue May 12 21:34:36 CEST 2020

   > One day I will get it clear, hope.

Tomas, I admit that the description in the book is not sufficiently clear
when it comes to nuances like that.

But it’s really all very simple. You just have to separate the notion of a
standalone program and the bootloader (a special standalone program).

Only what the boot loader (BootLoad.Mod) does with the addresses
12, 16, 20, 24 is special. And this is also the reason why BootLoad.Mod
CANNOT declare any global variables -> it would mess with these values.

Just remember this one thing: standalone programs always have their
global variables start at absolute memory address 8. Always!

In fact, if you look at the compiler (ORG.GetSB), you will see that
if version = 0 (=standalone program), you have the line

   IF version = 0 THEN Put1(Mov, RH, 0, VarOrg0)  (*VarOrg0 = 0*)

and, because ORP.dc = 8 for standalone programs (see ORP.Module),
you can see that the compiler ALWAYS places ANY global variables
of ANY standalone program at absolute address 8 or higher..

The bootloader is the ONLY standalone program which in fact
fills the memory locations 0, 8, 12, 16, 20, 24, … etc by reading
a file (the boot file). And this is why the bootloader cannot itself
declare any global variables. There would be a conflict.

All other standalone programs CAN declare global variables.

And if a standalone program (i.e. its code section) happens to
be loaded to absolute address zero, the code in ORG.Open
sees to it that there are at least 6 words within the code section
starting at address at 8 that can, in fact, be used for global vars.

So in fact, you are “hijacking" the code section to be used as
global variables for standalone programs starting at address 0.

It’s a hack, but that’s how PO 2013 has decided to implement it.

Which is why on Oberon on RISC-V I have chosen a
completely different approach. There, standalone
programs do in fact have their own "data section” (just like
a regular module loaded by the module loader) and also,
the boot loader (or any other standalone program) can
in fact be a pre-linked binary. This makes it possible to
write bootloaders that consist of several modules, for
examples modules which implement networking.

More information about the Oberon mailing list