[Oberon] Fw: FPGA - Bitmaps.Mod

[Andreas Pirklbauer]

PS: There is a small proof-of-concept for a *generic* heap allocation routine New(ptr, size) that accepts a 'size' argument:

andreaspirklbauer/Oberon-generic-heap-allocation 


It resembles the code in Bitmaps.Mod (and could be used within it).
Andreas

      From: Jörg Straube <joerg.straube at iaeth.ch>
 To: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>; ETH Oberon and related systems <oberon at lists.inf.ethz.ch> 
 Sent: Wednesday, April 12, 2017 8:05 AM
 Subject: Re: [Oberon] Fw: FPGA - Bitmaps.Mod
   
Hi Tomas
I refined the module "Bitmaps" a little bit. This code allocates variably sized bitmaps and makes sure the garbage collector collects them if no longer referenced. As Andreas pointed out: it is the responsibility of the module using "Bitmaps" to make the bitmaps globally reachable. If not, the allocated memory gets freed up more or less immediately...
I compiled the code with the emulator on a Mac
MODULE Bitmaps; (* jr/11apr17 *)
IMPORT SYSTEM, Kernel := KernelOSX;
TYPE TypeTag = RECORD size, ext1, ext2, ext3, offset: INTEGER END; (* see Project Oberon, figure 8.8 *) Address = POINTER TO RECORD END; (* this pointer will be redefined by TypeTag *) Bitmap* = POINTER TO RECORD width, height: INTEGER; tag: TypeTag;   (* type descriptor of the pointer "base" *) base: Address END;

PROCEDURE New*(w, h: INTEGER): Bitmap; VAR b: Bitmap; BEGIN NEW(b); IF b # NIL THEN b.width := w; b.height := h;
 (* the following code defines a type tag corresponding to ARRAY size OF BYTE *)
 b.tag.size := (w+7) DIV 8 * h; (* size of the bitmap in BYTEs *) b.tag.offset := -1;   (* type has no pointers, important for GC *) (* allocate memory and define its type *) Kernel.New(SYSTEM.VAL(INTEGER, b.base), SYSTEM.ADR(b.tag));  
 IF b.base = NIL THEN b := NIL END END RETURN b END New;
END Bitmaps.
System.Free Bitmaps ~ORP.Compile Bitmaps.Mod ~

2017-04-07 17:41 GMT+02:00 Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>:

To be precise:
If you don't make dynamically allocated objects reachable via at least one global pointer variable, they simply won't be marked during the mark phase of the garbage collector, which means that they *will* be collected during the subsequent scan phase. That's the whole point of garbage collection...


      From: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
 To: ETH Oberon and Related Systems <oberon at lists.inf.ethz.ch> 
Cc: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
 Sent: Friday, April 7, 2017 5:35 PM
 Subject: [Oberon] Fw: FPGA - Bitmaps.Mod
  
...
4. If you want your objects to be automatically collected by the Oberon garbage collector, you must make it globally reachable via a global pointer. Then they will appear in mod.ptr in the module block which are used as roots for the garbage collector. (Oberon uses all named pointer variables in existence as roots for the mark phase of the garbage collector. See Oberon.GC for the details. It simply calls Kernel.Mark(mod.ptr) for each loaded module mod.

     
            

   
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/ mailman/listinfo/oberon





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