 |
 |
|
 |
 |
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
|
 |
|