65816-llvm-mos/tests/lua/README.md

63 lines
2.8 KiB
Markdown

# 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