131 of 208
ZBasic Language Reference 123 ZX Microcontroller Family Special Attributes Attribute Valid For Description Inline subroutine function Instructs the compiler to “inline” the code for the subroutine/function instead of generating a call. Generally, this yields faster execution, sometimes at the expense of larger program size. NoInline subroutine function Instructs the compiler not to “inline” the code for the subroutine/function and, instead, generate a call to the subroutine or function. Used subroutine function variable Instructs the compiler to include the variable or procedure in the executable even if it appears not to be used. This is useful, for example if external C or assembly code needs to use a ZBasic data item or procedure but it is not otherwise used in the program. Volatile variable Instructs the compiler to not make any assumptions about the content of the variable. This should be used when another task or an ISR may be modifying the variable. Example Dim index as Integer Attribute(Volatile) Sub foo() Attribute(Used,Inline) End Sub 5.6 Considerations for Task Stack Size As of v2.5.6, the ZBasic compiler produces an estimate of the minimum size for a native mode application’s tasks. The estimate is produced by performing a static analysis of the generated native code beginning with the entry point of each task (including the default Main() task). The static analysis determines, if possible, the maximum stack depth assuming that all possible execution paths through the code are followed. Additionally, each ISR (both user-provided and system-provided) is analyzed using the same technique to determine the maximum stack depth it will use. For each task, the required minimum task stack size is the sum of a) the maximum stack depth of the task itself, b) the size of the Task Control Block, c) the stack margin (default or user specified) and d) the largest of 1) the multi-tasking context size and 2) the stack depths of the individual ISRs. At the time of this writing, the Task Control block size is 13 bytes, the multi-tasking context size is 37 bytes (38 on ZX models with more than 64K of Flash memory), the maximum stack depth of the system supplied ISRs is less than 20 bytes and the default stack margin is 10 bytes. This leads to a typical task stack size minimum that is the stack depth of the task itself plus 60 bytes (37 + 13 + 10) or 61 bytes (38 + 13 + 10). The compiler outputs a list of the known tasks and the minimum task stack size for each to the .map file that is produced each time a project is compiled (unless it is explicitly requested otherwise). In most cases, the compiler stack depth estimation algorithm can successfully compute the maximum stack depth but there are certain situations where the stack effect cannot be deduced by examining the code. When this situation is encountered, the map file will list “???” as the minimum stack size in the task list contained in the .map file for the related task. In this situation, there are two possible alternative strategies. The first is to allocate a large task stack for the task in question, run the application (ensuring that as many of the executions paths as possible are taken) and then using the System Library function System.TaskHeadRoom() to determine how much unused space remains in that task’s stack. Based on the results of this observation, you may choose to increase or decrease the size of that task’s stack. The second option is to explicitly inform the compiler of the maximum stack depth for the routine or ISR that contains the problematic code. This is done using the #pragma StackUse directive within the particular procedure or ISR, the syntax of which is shown below. #pragma StackUse( <stack-depth> ) An alternate syntax that can be used outside of all procedures, but not for ISRs, is shown below.