--ram above 16 MiB silently breaks every program on a 68000/68010: the guest stack is placed beyond the 24-bit address bus, so the first library call returns into low memory.
Steps to reproduce
With the repo's own fixtures, on main (8e9bd85):
$ volamos --ram 17M fixtures/exectest
volamos: fixtures/exectest: continuation stub trapped at 0x000000c4 with no pending
continuation (guest jumped to the trampoline stub directly, or ContinuationStack
bookkeeping is out of sync)
$ volamos --ram 16M fixtures/exectest
exec ok
fixtures/memtest fails the same way. The threshold is exactly 16 MiB -- --ram 16385K is already broken.
Cause
It is the 68000's 24-bit address bus, not the continuation machinery the message blames:
$ volamos --cpu 68000 --ram 64M fixtures/exectest # continuation stub trapped
$ volamos --cpu 68010 --ram 64M fixtures/exectest # continuation stub trapped
$ volamos --cpu 68020 --ram 64M fixtures/exectest # exec ok
$ volamos --cpu 68030 --ram 64M fixtures/exectest # exec ok
$ volamos --cpu 68040 --ram 64M fixtures/exectest # exec ok
The guest stack is placed at the top of the address space, so --ram 64M puts A7 near 0x0400_0000. A 68000/68010 cannot express that: the address wraps to 24 bits, the JSR into a library pushes its return address somewhere in low memory instead, and the RTS pops whatever was there -- which is how execution ends up at CONTINUATION_STUB_ADDR (0x00C4) with nothing pending. The wrapping itself is faithful to the hardware; placing the stack somewhere the configured CPU cannot reach is not.
fixtures/hello survives at --ram 64M only because it makes no call that has to come back through a continuation.
Suggested fix
Validate --ram against the configured CPU's address width: with --cpu 68000/68010, anything above 16 MiB cannot work and should be a clean up-front error, the way an oversized --stack already is (#configurable-ram-size precedent) rather than a confusing failure several library calls later. --fpu is already a documented no-op below 68020, so a CPU-dependent constraint on --ram is consistent with how the flags already behave.
Since --ram's default is 16 MiB, this only bites someone who deliberately asks for more without also passing --cpu 68020, which is presumably why it has gone unnoticed.
Found while verifying #95/#97; unrelated to that work.
--ramabove 16 MiB silently breaks every program on a 68000/68010: the guest stack is placed beyond the 24-bit address bus, so the first library call returns into low memory.Steps to reproduce
With the repo's own fixtures, on
main(8e9bd85):fixtures/memtestfails the same way. The threshold is exactly 16 MiB ----ram 16385Kis already broken.Cause
It is the 68000's 24-bit address bus, not the continuation machinery the message blames:
The guest stack is placed at the top of the address space, so
--ram 64Mputs A7 near0x0400_0000. A 68000/68010 cannot express that: the address wraps to 24 bits, theJSRinto a library pushes its return address somewhere in low memory instead, and theRTSpops whatever was there -- which is how execution ends up atCONTINUATION_STUB_ADDR(0x00C4) with nothing pending. The wrapping itself is faithful to the hardware; placing the stack somewhere the configured CPU cannot reach is not.fixtures/hellosurvives at--ram 64Monly because it makes no call that has to come back through a continuation.Suggested fix
Validate
--ramagainst the configured CPU's address width: with--cpu 68000/68010, anything above 16 MiB cannot work and should be a clean up-front error, the way an oversized--stackalready is (#configurable-ram-size precedent) rather than a confusing failure several library calls later.--fpuis already a documented no-op below 68020, so a CPU-dependent constraint on--ramis consistent with how the flags already behave.Since
--ram's default is 16 MiB, this only bites someone who deliberately asks for more without also passing--cpu 68020, which is presumably why it has gone unnoticed.Found while verifying #95/#97; unrelated to that work.