[Oberon] Fw: FPGA - Bitmaps.Mod

[Andreas Pirklbauer]

Tomas,

The "size" of the heap record, as specified in the type descriptor, needs to satisfy certain criteria, in order for Kernel.New to work:
a) it must include 8 bytes for the two hidden fields 'mk' and 'tag'
b) the total must be 32, 64, 128 or n*256 bytes long.


See module Memory.Mod on 

https://github.com/andreaspirklbauer/Oberon-generic-heap-allocation

to see how this can be done (first three lines of procedures Memory.New).

It's essential (!) to set size correctly, otherwise the garbage collector gets confused, as becomes evident when studying the code for procedures Kernel.Mark and Kernel.Scan (which obtains the size if a heap record by inspecting the size field in the type descriptor). If it's not a valid size, Kernel.Scan will insert it in the "n*256" list without the record actually being a multiple of 256. Bad!


[Oberon] Fw: FPGA - Bitmaps.Mod

Tomas Kral thomas.kral at email.cz 
Wed Apr 19 12:53:09 CEST 2017
Previous message: [Oberon] Fw: FPGA - Bitmaps.Mod
Next message: [Oberon] FPGA - Naming Conventions
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Andreas, Joerg, I have tried both methods suggested here. (a) without tag declaration, simply calling Kernel.New(b.base, SYSTEM.ADR(b.size)); (b) with tag declaration and persistence tag.size := <size of your object to be allocated>; tag.ext[0] := 0; tag.ext[1] := 0; tag.ext[2] := 0; tag.ptr := -1; Kernel.New(b.base, SYSTEM.ADR(tag.size)) They both seem to allocate a block of requested size, however when GC is run, sometimes heap is inconsistent and `System.Watch' reports strange

Sent from my iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170419/5d483a41/attachment.html>