[Oberon] Dynamically sized allocation with NEW()

[Jörg]

Folks

I party agree with Chris and others, that its very seldom that dynamically sized structures are needed. Hence Oberon does not provide a NEW() with a size or length parameter. As can be seen eg in Files or Texts (both handling very dynamic structures with arbitrary length) that the way out is: linked lists of fixed sized blocks. Roughly, you call NEW several times until you have the length you need...

However there are structures (especially if they have to do with graphics/video) where it is of upmost importance that the structure is allocated in contiguous memory, so you can easily copy things straight away to the framebuffer. But you don‘t want to allocate eyerytime 10k if only 1K is needed.

Now, how this is done in Oberon? A clever method used in Fonts is the following:
You declare a base type with a certain static length, and then you declare an type extension with another static length.
  FontDesc = RECORD
    raster: ARRAY 2000 OF BYTE
  END;
  LargeFontDesc = RECORD (FontDesc)
    extRaster: ARRAY 1000 OF BYTE
  END;
  VAR F: Font; LF: LargeFont;
  IF len<2000 THEN NEW (F) ELSE NEW(LF); F := LF END;

This is obviously not a recipe for all cases, but it shows that you can live with NEW without size...

Jörg

Am 02.08.2018 um 10:53 schrieb Chris Burrows <chris at cfbsoftware.com>:

>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Tomas Kral
>> Sent: Thursday, 2 August 2018 12:17 AM
>> To: oberon at lists.inf.ethz.ch
>> Subject: Re: [Oberon] NAstrobe for RISC5 on Pepino
>> 
>> On Wed, 1 Aug 2018 21:39:18 +0930
>> Chris Burrows <chris at cfbsoftware.com> wrote:
>> 
>>> About 90% of the source code is identical to Wirth's latest
>> compiler.
>>> It generates identical symbol and object files for identical source
>>> files that have been compiled by the latest official compiler.
>> 
>> Hi Christopher,
>> 
>> Good work!
>> You had also once reported to have implemented New(addr,
>> size) allocator. Is it also part within that 10% of your compiler
>> extension?
>> 
> 
> No. 'addr'? That is something I would NOT encourage. 
> 
> You might be thinking of the local dynamic array extension that Wirth
> implemented in his ARM compiler and we support in the Astrobe for Cortex-M
> compilers e.g.
> 
> PROCEDURE P(s: ARRAY OF CHAR); 
> VAR 
>  local: ARRAY OF CHAR; 
> BEGIN 
>  NEW(local, LEN(s)); 
>  local := s;
> 
> The original discussion is here:
> 
> http://lists.inf.ethz.ch/pipermail/oberon/2017/011201.html
> 
> It requires the use of a stack 'frame' pointer in addition to the normal
> stack pointer. The RISC5 compiler doesn't need a frame pointer (since access
> to intermediate locals is not allowed - a restriction I agree with). While
> dynamic local arrays sounds a neat idea, I have yet to find a real need for
> them. Having to maintain a frame pointer just for them is a sufficient
> deterrent not to support that extension.
> 
> Regards,
> Chris 
> 
> Chris Burrows
> CFB Software
> http://www.astrobe.com/RISC5
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon