Re: Lua with Paged / Banked memory architecture

[Ralph Hempel <rhempel@...>]

Alexander Goldstone wrote:

<snip>

> + Our thinking is that we could give Lua 1MB to run its scripts (instead
> of the limited data-space it currently has) if we could alter lua to use
> 16KB pages/banks. We only have to update the value of a single register
> to re-point the useable 16KB block to another area of the 1MB. So what
> we need to do (if possible without a substantial re-write of Lua) is to
> have Lua allocate and reference memory accross multiple pages and switch
> pages accordingly.

<Puts on glasses and strokes chin thoughfully>

Way back in the old days, banked memory architectures were common, and
some compiler vendors even supported this notion for variables
and function entry points.

You would put all the "fast" access variables and code into memory that
could never be banked out, and declared others as banked.

Basically, a function call or variable reference that was allocated
in the banked space generated special code that switched to the
desired bank and it all just "worked". Unless it didn't and then
you had to mess with your linker until it did.

This only works for things that you know ahead of time are going
to be banked, and I doubt any modern compiler supports this at all.

I don't think rewriting Lua is going to get you much bang for your
buck, the problem needs support right down at the compiler level.

16K is awfully small for a Lua script. Not the code mind you, but the
environment that is set up every time you initialize a Lua state.

Depending on how big your script is, it might fit. But unless you work
very hard to recover the space used by that script (by nilling)
variables and then forcing garbage collection, you'll end up
with very little space due to heap fragmentation.

Can you just fully reinitialize the Lua state every time
you run a new script?

And have you given any consideration to Forth as a scripting
language for your very tight memory constraints?

Ralph