[Oberon] Fw: FPGA - Bitmaps.Mod

[Tomas Kral]

Hi,

Yes, I can see now.

Oberon maintains distinct chains of 32,64,128, and multiple 256 byte
blocks. With the idea to prevent holes and fragmentation?

Many thanks
Tomas

On Wed, 19 Apr 2017 15:48:27 +0200
Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> wrote:

> 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