[Oberon] NAstrobe for RISC5 on Pepino
Chris Burrows
chris at cfbsoftware.com
Thu Aug 2 14:34:44 CEST 2018
> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Andreas Pirklbauer
> Sent: Thursday, 2 August 2018 9:38 PM
> To: ETH Oberon and related systems
> Subject: [Oberon] NAstrobe for RISC5 on Pepino
>
> > The RISC5 compiler doesn't need a frame pointer (since access
> > to intermediate locals is not allowed > - a restriction I agree
> with).
>
> Wasn t the original reason that the FP is no longer needed that the
> *size of the stack frame (params + locals) is known at compile time?
>
OK - I may have got my wires crossed. For the record here is a direct quotation of the information I was attempting to paraphrase:
"Finally, note that access to variables via the static link list (intermediate level variables) is less
efficient than access to strictly local variables, because every step through the list requires an
additional memory access. Several solutions have been proposed and implemented to
eliminate this loss of efficiency. They ultimately always rely on the mapping of the static list onto
a set of base registers. We consider this as an optimization at the wrong place. First, registers
are scarce resources which should not be given away too easily. And second, the copying of
link elements into registers upon every call and return may easily cost more than it saves, in
particular because references to intermediate-level variables occur quite rarely in practice. The
optimization may therefore turn out to be quite the reverse.
In fact, programming experience has shown that the access of intermediate level variables is
bad practice and better be avoided. Implementors must welcome this insight, as it makes the
static link superfluous. If in addition we renounce the allocation on the stack of objects whose
size is unknown at compile-time (such as dynamic array parameters in Algol), we can even omit
the dynamic link. This because the amounts by which the stack pointer is to be decreased and
increased are known by the compiler and can be inserted explicitly in the code. This makes a
frame pointer superfluous and leads to a significant simplification and speedup of prolog and
epilog: Variables are addressed with SP as the base register."
For the complete story refer to Chapter 12.2 'Addressing of variables' in the second part of 'Compiler Construction':
https://www.inf.ethz.ch/personal/wirth/
> Compiler Construction > Chapters 9 - 16
Regards,
Chris Burrows
CFB Software
http://www.astrobe.com/RISC5
More information about the Oberon
mailing list