[Oberon] Dynamic local array implementation

[Chris Burrows]

> 
> From: Luca Boasso [mailto:luke.boasso at gmail.com]
> Sent: Friday, 13 October 2017 10:06 AM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: Re: [Oberon] Dynamic local array implementation
> 
> 
> The Astrobe compiler does use a frame pointer. Given the local
> variable 'a' declared as:
> 
> VAR
>   a: ARRAY OF INTEGER;
> 
> The code generated by NEW(a, 10) is as follows:
> 
>     MOV      r10,10
>     STR      r10,[fp,-8]
>     MOV      r10,r10 lsl 2
>     SUB      sp,sp,r10
>     STR      sp,[fp,-4]
> 
> 
> I see, that is similar to what I was expecting.
> If my understanding is correct,  [fp, -8] and [fp, -4] represent an
> array descriptor, where you store the length and address on the stack
> respectively. SP is decremented by length*element size to make space
> for the array.Very neat!
> Is [fp,-4] the beginning or the end of the array "a"?
> 

[fp,-4] corresponds to a[0]

> I have checked "An Oberon Compiler for the ARM Processor" p. 26 and
> it seems like in that compiler dynamic arrays are allocated on the
> heap:
> 

No - global dynamic arrays were allocated on the heap but local dynamic arrays were allocated on the stack. In that compiler a corresponding call was generated to the procedure MAU.AllocH or MAU.AllocS respectively. Astrobe used to do the same but now generates inline code for local dynamic array variables instead. 

> 
> Do you know if that system had a garbage collector?   

Apparently not (p. 25 of the same document):

"It is used for recording the hierarchy of extensions of a type (see below), and contains the necessary meta information about the type that is needed by a garbage collector. The latter information is not generated in this current implementation, with the exception of the record’s size."

Regards,
Chris Burrows
CFB Software
http://www.astrobe.com