External module bugs - preventing from having more sophisticated submods

[mdbergmann]

ACE EXTERNAL MODULE BUGS DISCOVERED

Through extensive testing, we discovered several bugs in ACE's EXTERNAL module
handling that prevent the originally planned architecture:

1. TWO OR MORE DIM ARRAYS CRASH

   • Having two DIM statements in a module causes crash at program startup
   • Workaround: Use a single combined array
   • Status: Workaround exists

2. POKE IN MODULE CRASHES

   • Using POKE statement inside an EXTERNAL module causes crash
   • No workaround within module
   • Status: Must avoid POKE in modules

3. TOO MANY ARRAY ASSIGNMENTS IN SUB CRASHES

   • More than ~4 array assignments in a single EXTERNAL SUB causes crash
   • Even with direct indexing (_data&(0), _data&(1), etc.)
   • Even without optimization (-m instead of -Om)
   • Status: Cannot build complex tag arrays in module SUBs

ACE COMPILER BUGS TO FIX (for developers)

The following bugs are in ACE's EXTERNAL module (-m flag) code generation.
Relevant source files likely in src/ace/c/ (module.c, codegen.c, or similar).

BUG 1: Multiple DIM arrays in EXTERNAL module crash

Symptom: Program crashes immediately at startup (before any code runs)
Reproduce:

• Create module with two DIM statements: DIM a&(100) and DIM b&(50)
• Compile with -m flag, link with main program
• Run -> crash before first PRINT

Likely cause: When generating code for module-level DIM arrays, the compiler
may be miscalculating BSS/DATA section offsets, causing arrays to overlap
or corrupt memory. Alternatively, module initialization code may only handle
one array correctly.

Investigation: Compare generated .s assembly for single-array vs two-array
modules. Check how array base addresses are calculated and relocated.

BUG 2: POKE statement crashes in EXTERNAL module

Symptom: Program crashes when POKE is executed inside a module SUB
Reproduce:

• Create module with SUB that does: POKE someAddr, 65
• Call SUB from main program -> crash

Likely cause: POKE may generate code that references a base register or
data segment pointer that isn't set up correctly in module context.
The same code works fine in main program.

Investigation: Compare generated assembly for POKE in main program vs module.
Check if module SUBs have different register conventions or missing setup.

BUG 3: Too many array assignments in EXTERNAL SUB crash

Symptom: Program crashes when a module SUB has more than ~4 array assignments
Reproduce:

• Create module SUB with 5+ lines like: _data&(n) = value
• Even simple direct indexing crashes: _data&(0)=x, _data&(1)=y, etc.
• 4 assignments works, 5 crashes

Likely cause: Possible stack frame overflow, register exhaustion, or
incorrect offset calculation when many array accesses occur in one SUB.
May be related to how SHARED array access is compiled in module context.

Investigation: Compare generated assembly for 4-assignment vs 5-assignment
SUBs. Check stack frame size, register allocation, and array base address
calculations.

[mdbergmann]

This was fixed. Commit pending, is part of another branch.

[mdbergmann]

Closing as fixed