[Oberon] Modula2 vs Oberon IMPORT

[Chris Burrows]

> 
> My concern is this - if a "main" Module IMPORTS 10 "slave" Modules,
> but uses only (e.g.) one procedure from each, then the code bloat in
> the final executable would be absurd, would it not? I might as well
> cut-n-paste the code into the "main" module, and re-use the code that
> way. Maybe this something a "peephole optimizer" could do?
> 

On Oberon systems memory savings are typically achieved much more simply and
safely at the 'module level' rather than at the 'procedure level'. The
majority of Oberon systems (e.g. Oberon programs running on the Oberon
operating system, Component Pascal programs running in the BlackBox
environment on Windows or Linux) use dynamic linking and loading - there is
no 'final executable' created that has to be created and stored before it is
executed. 

The savings arise because every module is loaded at most only once and
shared by all applications that IMPORT it. If the first application uses
only procedure X from Module A, the whole module is loaded. However, when
the next application starts which uses procedure Y from module A nothing has
to be loaded at all as A.Y is already there. 

For example if:

 app W imports modules A, B, C, D, E
 app X imports modules A, B, D
 app Y imports modules A, C, E 
 app Z imports modules A, D, E 

the total amount of memory used when all four apps are running on an Oberon
System is:

 W + X + Y + Z + A + B + C + D + E

Contrast this with the conventional use of pre-linked executables on Windows
and Linux. When all three apps are running the total amount of memory used
is:

 W + X + Y + Z + (4 * A) + (2 * B) + (2 * C) + (3 * D) + (3 * E) 

Chris.