[Oberon] Fw: FPGA - Bitmaps.Mod
thomas.kral at email.cz
Wed Apr 19 16:38:11 CEST 2017
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?
On Wed, 19 Apr 2017 15:48:27 +0200
Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> wrote:
> 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
> to see how this can be done (first three lines of procedures
> 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;
> tag.ext := 0; tag.ext := 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
More information about the Oberon