Lua taking advantage of MCU MRAM

[Regan Ryan]

Hi. This is my first post on the group after monitoring it for the past year, so please go easy on me

I'm working with Lua 5.5, embedding it on an MCU (Arm Cortex-M33) with Zephyr. The implementation has gone really well. I've made minor changes to base Lua to support: 

• XIP bytecode, with flash mapped to RAM address space
• Flash-based strings
• Flash-based read-only tables
• Modified heap manager using slab heaps of selected sizes to support commonly allocated objects (for speed and reduced fragmentation)
• Multiple lua threads with pre-emption support

I'm aware that there are many MCU-based Lua projects out there, some with small footprints like mine. I'm also watching the introduction of MRAM very closely as it is set to revolutionise the way that memory is managed.

MCUs with limited SRAM could utilise large MRAM blocks for less-volatile objects. This could have huge benefits in managing a Lua heap. In my case, I could go from a heap size of KBs to MBs. Since MRAM has excellent (but not infinite) endurance, as long as allocated objects are not changed every few milliseconds, it's very viable as secondary RAM.

As MRAM rapidly replaces flash, Lua could better take advantage of it by providing cues to the heap manager about whether allocation requests are likely to be volatile (ephemeral, often changed) or stable (changing infrequently, more persistent). Stable allocations can still be subject to change.

Has there been any thought given to whether Lua's VM could do it transparently or whether Lua syntax could be extended to support something like <nonvolatile> in the same way that <const> has been introduced? 

Strings and bytecode would be obvious ones to consider, but some strings will have very limited lifetimes. 

[Martin Eden]

Hello Ryan,

On 2026-07-30 01:24, Regan Ryan wrote:
> Has there been any thought given to whether Lua's VM could do it
> transparently or whether Lua syntax could be extended to support
> something like <nonvolatile> in the same way that <const> has been
> introduced?
> Strings and bytecode would be obvious ones to consider, but some
> strings will have very limited lifetimes.

Since Lua 5.4 syntax allows marking variables at definition with attributes:

  local LookupTable < magnetoresistive_memory > =
    {
      ['abc'] = 'Some long string',
      ['def'] = 'Another long terminal value',
    }

So I think extension should add that attribute to specification.
Of course this will require extension of VM instructions set.

But keep in mind that Lua strings live in global pool of uniques.
So that table definition will only allocate array of pointers
in MRAM.

-- Martin

[Regan Ryan]

All strings that I'm aware of at compile time will be loaded (with their hashes) into MRAM instead of being interned. I'm finding it hard to figure out the lifetime of strings created at runtime.

Even though lua_Alloc currently passes the Lua type in osize when ptr==NULL (such as LUA_TTHREAD,  LUA_TNUMBER...), that is not enough for me to determine how mutable it is. 

So, I'm thinking about how I might modify luaM_malloc to overload the tag/osize even further by adding hints about the lifetime and mutability of the object.

Regan

[TopchetoEU]

This could be very doable without much extension of the core language (VM, instruction set, etc.). A function, for example `table.mram(tab)`, could accept a single table argument and copy it into MRAM, if it isn't already there, and return the table in MRAM (the passed argument in SRAM would be then GC'd). As for the VM side, you would only need to hint `lua_createtable` with where to place the table (it seems you are already doing this).

However, you will need some sort of mechanism to 'persist' locations of MRAM tables. The 'dumbest' way to go about this would be to assign 'slots' in MRAM sequentially, and hope that allocation in MRAM happens deterministically.

On another note, I do agree that lua would benefit greatly from a more "hintable" allocator interface, even outside the embedded world.

On Thursday, July 30th, 2026 at 3:12 AM, Regan Ryan <regan...@irismv.com> wrote:

> Hi. This is my first post on the group after monitoring it for the past year, so please go easy on meI'm working with Lua 5.5, embedding it on an MCU (Arm Cortex-M33) with Zephyr. The implementation has gone really well. I've made minor changes to base Lua to support:
>
> - XIP bytecode, with flash mapped to RAM address space
> - Flash-based strings
> - Flash-based read-only tables
> - Modified heap manager using slab heaps of selected sizes to support commonly allocated objects (for speed and reduced fragmentation)
> - Multiple lua threads with pre-emption support

>
> I'm aware that there are many MCU-based Lua projects out there, some with small footprints like mine. I'm also watching the introduction of MRAM very closely as it is set to revolutionise the way that memory is managed.
>
> MCUs with limited SRAM could utilise large MRAM blocks for less-volatile objects. This could have huge benefits in managing a Lua heap. In my case, I could go from a heap size of KBs to MBs. Since MRAM has excellent (but not infinite) endurance, as long as allocated objects are not changed every few milliseconds, it's very viable as secondary RAM.
>
> As MRAM rapidly replaces flash, Lua could better take advantage of it by providing cues to the heap manager about whether allocation requests are likely to be volatile (ephemeral, often changed) or stable (changing infrequently, more persistent). Stable allocations can still be subject to change.
>
> Has there been any thought given to whether Lua's VM could do it transparently or whether Lua syntax could be extended to support something like <nonvolatile> in the same way that <const> has been introduced?
> Strings and bytecode would be obvious ones to consider, but some strings will have very limited lifetimes.
>
>
>

> --
> You received this message because you are subscribed to the Google Groups "lua-l" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/lua-l/99387f8e-7e58-4a46-8796-d6eb6ab251fdn%40googlegroups.com.