97 of 172
ZBasic Language Reference 90 ZX Microcontroller Family 3.28.1 Task Control Block Each task has an associated Task Control Block (TCB) - a data area that occupies the first few bytes of the task stack in VM mode (the last few bytes of the task stack in native mode). In most cases, a program will not need to access the contents of a TCB. The information is included here for those rare circumstances when is needed. Use of this information is recommended for advanced programmers only. When a task is activated its task control block is initialized and then inserted into a circular linked list immediately following the task control block of the then-current task. The table below gives some information on the structure of the task control block. It is important to note that this information is considered implementation detail subject to change as necessary. Task Control Block Elements (VM Mode Devices) Offset Length Description 0 1 Task status. See StatusTask() for details. 1 2 Remaining time to sleep (in RTC ticks). 3 2 Address of next task control block. 5 6 Task context: IP, BP, SP (valid only when not the current task). 11 1 Task control flags (used internally). 12 2 Address of the byte following the end of the task’s stack. Task Control Block Elements (Native mode Devices) Offset Length Description 0 1 Task status. See StatusTask() for details. 1 2 Remaining time to sleep (in RTC ticks). 3 2 Address of next task control block. 5 2 Task context: SP (valid only when not the current task). 7 2 Task stack starting address. 9 2 Unused. 11 1 Task control flags (used internally). Caution: directly modifying the task control block (other than the “time to sleep” value) is strongly discouraged as doing so will probably cause your program to malfunction. 3.29 Dynamic Memory Allocation The ZX system maintains a dynamic memory allocation heap that is primarily used internally. For example, space is allocated from the heap automatically by the system to hold the characters of String variables. That allocated space is automatically returned to the heap when String variables change or go out of scope. In some applications, it is useful to be able to allocate a block of memory to use for some period of time (perhaps for a data buffer, for example) and then to deallocate the block when it is no longer needed. The ZBasic System Library routines System.Alloc() and System.Free() provide access to the dynamic memory allocation heap for such purposes. While these routines provide a very useful functionality, they must be used with great care because careless or improper use can result in malfunctioning of the heap. There are two fundamental problems that can arise: heap exhaustion and heap corruption. If blocks of memory are allocated from the heap and never freed, the heap will eventually become exhausted and subsequent allocation requests will fail. Since String variable types rely on proper heap function, assigning values to String variables will not have the desired effect when the heap is exhausted. Heap corruption occurs when the heap management data structures are inadvertently modified. Such corruption can result from writing to a previously allocated block after it has been freed or writing to memory outside the bounds of a properly allocated but not yet freed block. The heap may also be corrupted by inadvertent writes to RAM within the bounds of the entire heap such as might result from the careless use of the RamPoke() or BlockMove() routines, by writing beyond the bounds of an array, or overflowing the stack assigned to a task. Heap corruption will also be the likely result of passing an