[Oberon] Dynamic local array implementation

Andreas Pirklbauer andreas_pirklbauer at yahoo.com
Sun Oct 15 10:29:46 CEST 2017


> On Sun Oct 15 06:52:19 CEST 2017 Luca Boasso wrote:
>
> Since we have a garbage collector, unlike the Astrobe
> system designed for microcontrollers, probably it is
> cleaner to implement dynamic arrays like in Oberon-2.
> I would rather pay the price of longer collection cycles
> (that only happens if dynamic arrays are used) than a
> longer prolog/epilog for each function that you pay
> at every invocation even if the feature is not used.
> Don't get me wrong, I like Chris's implementation
> very much.

If you want to keep the current Oberon-07 procedure call
mechanism (i.e. with no FP), than implementing dynamic
arrays in the Oberon-2 is what you would need to do.

And the Oberon-07 procedure call mechanism is indeed
worth keeping! It has been made possible (in the step
from Oberon to Oberon-07) by several key decisions:

1) First, access to intermediate variables has been
   eliminated from the language. This eliminated the
   need for a static link (SL) in implementations.

2) Second, only objects with a size known at compile-
   time are ever allocated on the stack. This eliminated
   the need for a dynamic link (DL) or a frame pointer.
   Now, adjusting a single register (namely the SP)
   by an amount known at compile-time suffices.

3) Third, structured types (arrays and records) are
   always passed by reference, regardless of whether
   they are value- or VAR- parameters. This makes stack
   usage about as minimal as it gets, as no copying of
   structured parameters ever occurs (the implication
   is that structure value-parameters are ready-only).

In addition, in the RISC processor, the return address
is placed in a register (LNK) by the branch instruction,
and so the call only consists of a single BL instruction,
while all the rest is done in a single place, namely in
the prolog/epilog rather than before each call.

Hence, procedure calls are optimally efficient in
Oberon-07. I’d say it’s rather pristine. It also kind
of marks the end point in a long history of refining
the procedure call mechanisms starting with the Euler/
Algol days and then in Pascal, Modula and Oberon. It
really doesn’t get much more (time and space) efficient
than that. And you can build systems with small stacks.
 
On the other hand, allocation of dynamic arrays via
NEW(ptr, size) was eliminated in Oberon-07. But that
is another one of those length discussions that were
held in the late 80s/early 90s at ETH. Papers were
written on this.. But Oberon-2 has found a satisfactory
solution. But it also requires some extra effort, e.g.
for the garbage collector.

I was intrigued by Chris’s approach to local dynamic
arrays, because storage reclamation is automatic.

Perhaps there is no way to get THAT without having
to also introduce a FP and lengthen the prolog/epilog
of *each* procedure. But the one who does find a way
around this probably deserves a price.. ;-)

-AP 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171015/10e95c96/attachment.html>


More information about the Oberon mailing list