Resource Limits

Every program you compile for the Coldwave Script VM runs inside a fixed resource budget: a maximum number of variables, a maximum number of instructions, a fixed amount of memory, and so on. This chapter describes what those limits are, how to see where your program sits inside them, and what to do if you reach one.

For everyday scripting you will rarely notice the limits — the defaults are sized generously for typical PLC programs. This chapter becomes relevant when you are building something larger, or when a compile fails with a limit diagnostic.

What a Limit Is

A limit is an upper bound on a single, countable resource that a program may consume. Limits fall into three groups, depending on when they are checked:

Group	Checked when	Examples
Compile-time	During compilation	variables, labels, instructions
Load-time	When a program image is loaded	program size, constants
Runtime	During script execution	nested function-call depth

If your deployment uses a specific VM profile configured by your integrator (SMALL, MEDIUM, or LARGE), the actual numbers differ from those shown in this chapter. The device's integrator can tell you which profile is active, or you can read it from the budget report described further down.

The Limits in Detail

This section lists the limits you may encounter while writing scripts. Each entry names what the limit counts and what to do if you reach it.

Program instructions

The total number of internal instructions produced by the compiler. One IF typically produces a handful of instructions; a loop, a function call, or an arithmetic expression each add a few more.

When reached: your program is too large to fit into the configured instruction buffer. Split into smaller functions or function blocks, or move repetitive code into a reusable block.

Variables and constants

The total number of named declarations: VAR, CONST, inputs, outputs, and block inputs/outputs. Each unique name contributes one entry.

When reached: remove unused VAR declarations, merge related values into arrays, or move state into function-block instances.

Arrays

Two separate limits apply to arrays:

• ARRAY_MAX_LEN — the maximum length N a single array may declare (DIM a AS INT[N]). Values above the limit are rejected with SCRIPT_ERR_ARRAY_BAD_SIZE.
• ARRAY_COUNT — the maximum number of array declarations per program. Exceeding it raises SCRIPT_ERR_ARRAY_TOO_MANY.

The storage for an array takes N consecutive slots in the TMP segment, so long arrays also count against the heap budget described under Memory.

When reached: shrink the declared length if it is larger than needed, merge several arrays that share an index into one, or raise the limit via a larger VM profile.

Scopes

The number of distinct lexical scopes the compiler creates — every IF, FOR, WHILE, function body, and block body opens one.

When reached: flatten deeply nested control structures or extract inner logic into a function.

Jump targets

Internal targets used for branches. IF, FOR, WHILE, CASE, and function calls each consume one or more jump targets.

When reached: reduce the number of branch-heavy constructs in a single program unit, or split large control-flow sections across multiple blocks.

Aliases

The number of ALIAS declarations, typically used to give hardware addresses readable names:

ALIAS PumpOn = %Q0.0
ALIAS Temp   = %I1.2

When reached: reuse existing aliases, or drop aliases for single-use hardware addresses.

Function-block declarations and instances

Block declarations are the distinct function-block types you declare (FUNCTION_BLOCK TimerFb). Block instances are the concrete instantiations (DIM T1 AS TimerFb). A program normally has far more instances than declarations.

When reached (declarations): merge similar block types into a parameterised one, or remove unused declarations. When reached (instances): instantiate shared blocks only once and feed them with different inputs instead of creating one per caller.

Call depth

The maximum number of nested function calls at runtime. Coldwave Script does not support recursion, so this limit is only reached by deep non-recursive call chains.

When reached: shorten call chains; unroll deep call sequences into loops where possible.

Function arguments

The maximum number of arguments a single function call may pass.

When reached: group related arguments behind a function block that carries them as inputs, or split the call into two.

Print string length

The maximum length of a single PRINT item after formatting. Longer values are truncated.

When reached: split the PRINT into multiple statements, or format strings incrementally.

Memory

The total private memory the VM uses for program structures: the program image itself, constants, strings, and symbol names. This is the resource most programs run out of first, because it grows with both the number and the size of declarations.

When reached: see the budget report described below to find out what is consuming the memory. Common remedies: shorter symbol and alias names, fewer long string literals, or a larger deployment profile (talk to your integrator).

The Budget Report

After every successful compile, the VM records how much of each limit your program consumed. The report is available both as data and as a printed summary.

Example output for a medium-sized program:

Script VM budget:
  Program words     :    412 / 2048   ( 20%)
  Symbols           :     87 / 256    ( 33%)
  Constants         :     23 / 256    (  8%)
  Labels used       :    156 / 512    ( 30%)
  Fixups            :    158 / 512    ( 30%)
  Aliases           :      8 / 64     ( 12%)
  Block decls       :      5 / 128    (  3%)
  Block insts       :      4 / 128    (  3%)
  Scopes used       :     12 / 64     ( 18%)
  Array descriptors :      2 / 32     (  6%)
  Heap bytes        :   3824 / 65536  (  5%)

Reading this regularly gives you a feel for where your program sits. A number climbing into the 70–90 % range is a useful early warning that you are approaching a limit, long before a compile fails.

Your editor or host environment may show the report automatically after each compile, or provide a button to display it. Check your tool's documentation for how to access it.

When a Limit Is Reached

If a limit is exceeded during compile, load, or runtime, the VM emits a single-line diagnostic before failing. The message always contains three things: what was reached, the actual and allowed count, and a concrete workaround. For example:

Too many variables/constants (257). Maximum is 256 per program.
  Workaround: remove unused VAR declarations, merge related values
              into arrays, or move state into FB instances

Most of the time, the workaround line is enough to resolve the issue without any change to the VM configuration itself. If you have genuinely outgrown the profile — not just inefficient code, but a program that really needs more headroom — your integrator can choose a larger profile or tune an individual limit. That part of configuration is covered in the VM developer documentation.

Summary

• The VM runs inside a fixed budget of countable resources: instructions, variables, labels, aliases, function blocks, call depth, memory, and more.
• The budget report shows current usage after each successful compile.
• If a limit is reached, the VM prints a single-line diagnostic naming the resource and giving a concrete workaround.
• If workarounds don't help, your integrator can raise the limits for your deployment.