# Lua 5.1.5 — substantial real-world C test

Lua's reference C implementation (17K lines, 24 source files) compiled
for the W65816 / Apple IIgs target.  Serves as a "real-world C" stress
test for the backend — exercises every major language feature, dispatch-
heavy VM, deep recursion, GC walks, etc.

## Build

```
bash tests/lua/build.sh        # compile all 24 Lua sources + stubs
bash tests/lua/runLuaTest.sh   # build + link the test wrapper
```

## What works

- **All 24 Lua source files compile cleanly** under our backend.
- **Links into a multi-segment binary** via link816 `--segment-cap`.
  Five segments at ~40KB each (with gc-sections enabled — drops to one
  segment when only the API entry points are used).
- **Loads in MAME** (verified via direct `mame ... -autoboot_script`).

## Caveats

A few functions (`symbexec` in ldebug.c, `auxsort` in ltablib.c,
`luaV_execute` in lvm.c, plus `lstrlib.c` under `--layer2`) exceed what
LLVM's `greedy` allocator can place with the 65816's single accumulator
and abort with `ran out of registers during register allocation`.  This
is a hardware constraint, not a miscompile.  `build.sh` handles it
automatically: it compiles through `scripts/ccRegallocFallback.sh`, which
retries an affected TU with `-mllvm -regalloc=basic` (the simpler,
always-terminating allocator) only when greedy fails.  No per-file list
is maintained; a newly register-heavy TU is handled transparently.

These functions are the largest in Lua and exhibit unusual register
pressure (luaV_execute is a 30+ case VM dispatch).  See the regalloc
discussion in [`../../LLVM_65816_DESIGN.md`](../../LLVM_65816_DESIGN.md).

## Runtime execution status

`runLuaTest.sh` passes: the API smoke test (create a state, push three
integers, sum them, check a string, pop, close) writes the `0xC0DE`
sentinel under MAME.

It used to crash, and not because of any sandbox.  The link is
multi-segment (`--segment-cap`, five segments), and clang forms a
function pointer as a 16-bit offset plus the bank in DP `$BE` -- bank 0.
link816 only redirected pointers to seg2+ functions through bank-0 `JML`
trampolines for GS/OS ExpressLoad links, so here Lua's allocator (the
first thing `lua_newstate` calls, through a pointer) was called in bank 0,
landed in `vfprintf`, and the machine ran wild; MAME itself then died of
the I/O the runaway stack wrote.  link816 now builds the trampolines for
every multi-segment link (fixed bank bases: the absolute target is baked
in).

## Files

- `lua-5.1.5/` — vendored Lua 5.1.5 source tree (from www.lua.org)
- `build.sh` — compile script (auto-falls-back to basic regalloc via
  `scripts/ccRegallocFallback.sh` when greedy can't place a TU)
- `luaStubs.c` — `strcoll`, `strxfrm`, `freopen` stubs for missing libc
- `luaTest.c` — minimal Lua API test (sentinel `0xC0DE` if pass)
- `runLuaTest.sh` — full build + run wrapper