[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