[Oberon] [Fwd: Re: Fw: FPGA - Bitmaps.Mod]
Tomas Kral
thomas.kral at email.cz
Thu Apr 13 19:00:44 CEST 2017
Hi Joerg, Andreas,
Thank you this looks all very neat.
I am rereading the chapters on heap management as I do something wrong,
as my bitmaps are not seen by GC when `System.Collect' is clicked.
Tomas
> -------- Forwarded Message --------
> > From: Jörg Straube <joerg.straube at iaeth.ch>
> > Reply-to: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> > To: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>, ETH Oberon
> > and related systems <oberon at lists.inf.ethz.ch>
> > Subject: Re: [Oberon] Fw: FPGA - Bitmaps.Mod
> > Date: Wed, 12 Apr 2017 08:05:50 +0200
> >
> > 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
> >
> >
> >
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> > systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
More information about the Oberon
mailing list