lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

To me it would be trivial to start doing this as:

- make a custom allocator that handles the GC'able memory accesses, giving the "pointer" value as bank + offset. - then any accesses will need to be guaranteed to switch in the right bank (needs modifying Lua core)

But the hard part is, as Ralph mentions, the 'lua_State' things itself, or whatever gets birth when bytecode is read in.

You should make some limitations as to what you actually want to run. Making that architecture run "anything" (any size of script, with any size of GC'able objects, tables of any size, etc...) is most likely not going to happen. And in that case, you really want to _know_ the limitations and not stumble upon them at one point, later on.

I would simply move to a better MPU, and feel safe. At least join the elua mailing lists, and observe the advancements there.


Alexander Goldstone kirjoitti 28.3.2009 kello 15:22: wrote:

Did I understand this right: you'd only have the Lua _scripts_
(precompiled bytecode) in the banked memory? How much of scripts do you

That would mean no banking is used for the GC'able objects. Makes no
sense to me..


Sorry, I'll try to be clearer:

+ The microcontroller has enough internal flash memory for our entire C
application (excluding the Lua script).

+ The microcontroller is based on the Harvard architecture which means
it addresses code and data space separately.

+ There is enough code-space for the C application (including the Lua
libraries and basic interpreter).

+ There is enough data-space for variables and constants associated with
the C application.

+ We can reference an additional 16KB data-space. The address of this
16KB block can be changed on the fly to reference anywhere across our
external 1MB RAM.

+ The microcontroller is connected to external NAND flash storage. The
only way in which this is relevant is that we are storing our script
files in this external NAND flash and loading it in at runtime.

+ All of this works. If, for example, our Lua script performs a simple
calculation and prints out the result then this works fine.

+ As our Lua script grows, it runs out of memory.

+ 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.

Does that make more sense than my previous email?



On Fri, 27 Mar 2009 17:35:48 +0000
Alexander Goldstone <> wrote:

Ralph Hempel wrote:

Is the banking in ROM or RAM? And 16k? That's an awfully small window.

Can you share a few more details?


The banking is in external RAM.

We have sufficient code space as the microcontroller is capable of
addressing 16MB of it - (Harvard architecture so separate address and
data buses).

It's main limitation is on data space, since it can only address 64KB of ram for which 32KB is on chip for application variable storage, 16KB is used for constant data access and the remaining 16KB would be for page access to the external 1MB of data ram that would only be used to hold
the Lua scripts.