Ram Size ZX-24

[DocJC]

Simple question, the result of debugging endeavours...

When the compiler lists the Errors, Target CPU, Code, RAM, and Persistent data, does the RAM value include ALL of the RAM utilized by the various components of the program?
On the ZX-24 I believe there are 1536 bytes available, of the 2048 bytes present. Does the listed amount include that used by the program, the TaskStacks, the Ques, byte arrays, and the defined variables?
I believe it does, but I wanted to make sure...

I have abut 700 bytes in ques and arrays, and (potentially) 340 bytes in taskstacks, and if they are not included in the ram size listed, it could explain a bug I'm tracking.
I am not using any recursion.

Thanks,
JC

No errors. Target CPU: ZX24, Code: 7172 bytes, RAM: 984 bytes, Persistent memory: 8 bytes
>Exit code: 0

[dkinzer]

The value displayed for the RAM use is the amount of RAM that is statically allocated. That includes all of the RAM for module-level variables (including queues, task stacks, etc.) and RAM for variables that are defined within a subroutine/function with the Static attribute.

Note, particularly, that the value does not include RAM that is dynamically allocated (for non-Static local variables, procedure invocation/parameter passing, etc.) nor does it include the storage space for strings. These two sources of RAM use are described separately because they are satisfied from two separate regions. The former elements consume space on the task's stack while the latter takes space from the "heap". The task stack of Main() and the heap jointly use all of the remaining unallocated RAM (the Main() task stack grows from lower addresses upward while the heap grows from the end of User RAM downward).

The compiler makes an estimate of the dynamic allocation requirement for each procedure (i.e subroutine or function), a value that includes the stack requirements for all of the procedures that it invokes, etc. This value is listed in the .map file in the Procedures section. Moreover, for each task, the compiler will compute an estimate of the number of bytes required for the task stask. This information is shown in the .map file in the "Task Invocation" section. These estimates do not include the dynamically allocated space required for storing the characters of String variables.

An example may help to clarify. Say that the compiler reports that 984 bytes of RAM are allocated as it does in your case. That means that on a ZX-24 the remaining 1536-984=552 bytes of RAM is shared by the Main() task stack and the heap. If the .map file indicates that the Main() task requires 550 bytes, the application will compile with no warnings but will probably not run correctly if any strings are used since the heap will almost certainly collide with Main's task stack.

You may want to reduce the size of the defined task stack to something near the value the compiler's estimate and see if that makes any difference in the symptoms that you're seeing. You could also reduce the queue sizes to free up additional RAM.

[DocJC]

Thank you for the info, it will help me track down my bug(s?).

I'm not sure the stack and heap are colliding, as my Main states that the Min Size is 42, Act. Size 585. I do believe, however, that I am overwriting data somewhere...
Individual Tasks, several of which are stand alone functions, work UNTIL several of them are simultaneously enabled, then lock ups or reboots occur.

I will keep plugging away

Thank you,
JC

[dkinzer]

You might want to read about Runtime Stack Checking. When a stack overflow is detected the processor is reset and information about the stack fault is available when it begins to run again.

Another possibility is that a task could be writing beyond the bounds of an array. There is is no detection of this run-time problem and the effects are often the symptoms that you describe. If this is occurring, it could be the result of a problem in your program or it could be a code generation error in the compiler.

It is also possible that the compiler's estimate of the stack requirement is incorrect. You can determine the actual use by initializing the array used for a task stack to a known value before invoking CallTask. Then, as the task is running (or when it has completed), you can search down from the end of the array looking for the first location that does not contain the initialization value. That will give you the "high water mark" for the stack use of the task during its execution.

[DocJC]

I will pursue all of the above.
I appreciate the guidance!
JC