[Oberon] Intermediate scopes in Oberon-07

Andreas Pirklbauer andreas_pirklbauer at yahoo.com
Sun Feb 11 19:02:30 CET 2018


  > Wirth tries very hard to avoid so called "type explosion”.
  > Therefore, he rather declares a single record with very
  > generally usable fields than a hierarchy of record types.
  > And fewer type declaration in total also means fewer local ones.

For the compiler, the rationale for the decision to use such
multi-purpose fields is explained in ch 12.3.1 on p.29 of:

www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf <http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf>

But at least for the compiler, there is another reason for using
the rather compressed representation using multi-purpose fields:
to minimize memory usage! For example, the length of record type
ORB.Object is 56 bytes, to which procedure NEW will add 8 bytes
(for the type tag and the mark field) for a total of 64 bytes.

If one adds even a single field to this one record, memory usage
would double to 128 bytes for *each* allocated heap record (it’s 
how heap blocks are implemented in PO2013: 32, 64, 128, n*256).

Given that even for small modules there are typically hundreds
of identifiers in the symbol table (mainly because of imports),
it’s easy to increase heap usage by a few hundred KB, depending
on the size of the modules being compiled.

And THAT makes a big difference on a machine with only 1 MB
of memory (as used by PO2013) and a heap size of 415KB.

I once did a small experiment and found that it can easily
break the compiler on more than one occasion.

BUT: Such implementation considerations - which in addition
are completely irrelevant on machines with larger memories -
don’t belong to a discussion about programming styles. But
historically, such considerations were important - as everyone
who has worked on machines such as the PDP-11 will remember :-)
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180211/c7228d0c/attachment.html>


More information about the Oberon mailing list