ChronOS Memory Management - Versionsgeschichte

Mat: /* Free RAM start address */

2013-05-21T23:21:27Z

‎Free RAM start address

Mat: /* Programming Interface */

2013-05-21T23:20:32Z

‎Programming Interface

Mat: /* Programming Interface */

2013-05-21T23:19:24Z

‎Programming Interface

Mat am 21. Mai 2013 um 23:13 Uhr

2013-05-21T23:13:54Z

Mat: /* Segments */

2013-05-21T22:32:03Z

‎Segments

Mat: Created page with "== Segments == The remaining free memory (starting at the end of the global variables and ending at Bascom's Frame start) is managed by the OS using segments. A segment is a line..."

2011-05-03T22:39:39Z

Created page with "== Segments == The remaining free memory (starting at the end of the global variables and ending at Bascom's Frame start) is managed by the OS using segments. A segment is a line..."

Neue Seite

== Segments ==
The remaining free memory (starting at the end of the global variables and ending at Bascom's Frame start) is managed by the OS using segments. A segment is a linear block of memory of any size fitting the available memory. They can be created and killed during runtime. On creation, the memory manager searches a free block big enough to hold the new segment.

Because this happens in a random order, external fragmentation could occur. This means, that there are small blocks of free memory between the segments, not big enough to hold new segments. In the end, a new segment cannot be created, although the free memory in addition is big enough.
To avoid this, the memory manager cleans up the memory by moving all segments together.
Addresses, which are pointing in a moved segment, become invalid. To take care of this, each pointer has to be registered in the OS and will then be adjusted if a segment is moved. However, this cannot be done with the task segments, because the pointers in the stacks are not registered. So these segments are static and are not moveable.

== Pipes ==
Pipes are simple LIFO buffers, so data will be written on the top of the stack and read from the bottom.
They are available for byte and word values. Each pipe is stored in an own segment. If you store a pointer in the pipe, it has to be registered.

@@ Zeile 14: / Zeile 14: @@
 === Free RAM start address ===
-Because the start address cannot be calculated with some constants, you have to set this yourself. To do this, check "Show internal variables" in Options->Compiler->Output and look into the compiler report and search for the address of the first byte not occupied by a variable.
+Because the start address cannot be calculated with some constants, you have to set this yourself. To do this, check "Show internal variables" in Options->Compiler->Output, look into the compiler report and search for the address of the first byte not occupied by a variable.
 Obviously this is a very important step, otherwise the values of global variables would be overwritten.
 <pre>

@@ Zeile 82: / Zeile 82: @@
 == Programming Interface ==
-Request memory from free memory pool:
+=== Malloc: Request memory from free memory pool ===
 <pre>
 Dim Object As Word
@@ Zeile 89: / Zeile 89: @@
 If there is a risk running out of memory (always be aware of that when using a dynamic allocation algorithm), a check if Malloc() returns 0 and a proper error handling is important.
-Return memory to the pool:
+=== Free: Return memory to the pool ===
 <pre>
 Free Object

@@ Zeile 87: / Zeile 87: @@
 Object = Malloc(Byval Size As Word)
 </pre>
 Return memory to the pool:

@@ Zeile 1: / Zeile 1: @@
-== Pipes ==
+== Common Settings ==
-Pipes are simple LIFO buffers, so data will be written on the top of the stack and read from the bottom.
-They are available for byte and word values. Each pipe is stored in an own segment. If you store a pointer in the pipe, it has to be registered.
+=== Allocation Algorithm ===