[Oberon] Clarifying type compatibility in Oberon-07

[Andreas Pirklbauer]

>
> Wouldn't you need a frame pointer to implement it? The current
> compiler does not need one, since the stack frame size is know
> at compile time, adding this feature would break this invariant.
> Am I missing something?
>

Luca - good point. I am not sure whether it can be done without 
re-introducing the FP concept. Perhaps we should add Chris who
has actually implemented it in the Astrobe products.

My first reaction:

1. From the caller’s point of view, the size of the stack frame
is of course still known, so the procedure prologue and epilogue
should be unchanged (I think). It is only *inside* the local
procedure that additional data gets allocated on the stack
via calls to NEW(array, size).

2. If this is implemented by adjusting the stack pointer, then
you do have a point: i.e. the question is how the stack pointer 
gets readjusted in the "right way” at the end of the procedure,
given that the amount by how much it needs to adjusted is not
known at compile time?

3. But what if the compiler reserves - and does this *only*
for procedures that actually contain calls to NEW(a, size) -
one additional hidden local variable on the stack that
simply keeps track of allocations: each time NEW(a, size)
is called, that counter gets incremented by ’size’. And
before the procedure epilogue gets executed, the compiler
could simply insert an instruction, that adjusts the stack
pointer by the amount stored in the hidden variable, i.e.
by how much the stack pointer has been adjusted during
execution of the local procedure.

The cost is (a) 4 bytes extra local stack space for the counter
and (b) the fact that NEW contains one addition instruction.

I guess that is one implementation option I would
probably consider. It seems fairly easy to implement
with only a few lines of extra code in the compiler),
but perhaps there are other - better - ways to do it.

-AP

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171012/dac0a69b/attachment.html>