I.11 Memory Descriptor (MD) in TOS

typedef struct md
{
    struct md *m_link;      /* Pointer to next MD         */
    int32_t      m_start;   /* Start address of the block */
    int32_t      m_length;  /* Length of the block        */
    BASEPAGE  *m_own;       /* Pointer to the basepage    */
} MD;

Note: The component m_own here points to the basepage of the process to which the memory block belongs.

These structures are administered in the internal memory management of TOS (but not of MagiC!). These descriptors, as far as they are used, hang in three memory lists, namely for free blocks, occupied blocks and for the next block to be occupied (mem_rover). With the mem_rover concept one attempts to achieve that consecutive Malloc calls reserve consecutive memory if possible (this has been described as an error already elsewhere). This is intended to reduce memory segmentation.

This idea is unusable if several programs are running simultaneously and call Mallocs alternately, however. The concept implemented by Atari has the advantage that it is not sensitive to programs that run amuck, since the MDs lie is system memory, far away from user memory. A known disadvantage of the described concept is that only a very restricted number of Malloc calls are possible, since every call swallows an MD of the limited system memory; this is also massively burdened by opened folders and files. A further disadvantage of the TOS memory management: If a program overspills a memory block, i.e. writes past its end, then this generally passes completely unnoticed.

Specially in multitasking systems the danger of an overwritten memory block is very much higher than in TOS. Furthermore, the number of memory blocks required, as well as those for folders (each program has its own files and standard directories) is appreciably higher. For these resons MagiC has a completely different concept; in that there is only one memory list whose pointers point to the first MCB.

Type definitions

Memory-Control-Block (MCB) in MagiC

MRETS