Re: Lua taking advantage of MCU MRAM

This could be very doable without much extension of the core language (VM, =
instruction set, etc.). A function, for example `table.mram(tab)`, could ac=
cept a single table argument and copy it into MRAM, if it isn't already the=
re, 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` w=
ith where to place the table (it seems you are already doing this).

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

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

On Thursday, July 30th, 2026 at 3:12 AM, Regan Ryan <[email protected]>=
 wrote:

> Hi. This is my first post on the group after monitoring it for the past y=
ear, so please go easy on meI'm working with Lua 5.5, embedding it on an MC=
U (Arm Cortex-M33) with Zephyr. The implementation has gone really well. I'=
ve made minor changes to base Lua to support:
>=20
> -   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 c=
ommonly allocated objects (for speed and reduced fragmentation)
> -   Multiple lua threads with pre-emption support
>=20
> 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 ver=
y closely as it is set to revolutionise the way that memory is managed.
>=20
> 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 no=
t infinite) endurance, as long as allocated objects are not changed every f=
ew milliseconds, it's very viable as secondary RAM.
>=20
> As MRAM rapidly replaces flash, Lua could better take advantage of it by =
providing cues to the heap manager about whether allocation requests are li=
kely to be volatile (ephemeral, often changed) or stable (changing infreque=
ntly, more persistent). Stable allocations can still be subject to change.
>=20
> Has there been any thought given to whether Lua's VM could do it transpar=
ently or whether Lua syntax could be extended to support something like <no=
nvolatile> 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.
>=20
>=20
>=20
> --
> 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 [email protected].
> To view this discussion visit https://groups.google.com/d/msgid/lua-l/993=
87f8e-7e58-4a46-8796-d6eb6ab251fdn%40googlegroups.com.

--=20
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 e=
mail to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/lua-l/UpaB9=
pWhpdvwAYoQiBZNLPj2MvZnfmv8qIWZGXngCF1jO6RPEOPZ2L_D2SEMc0yDajA-IZ728BjosVdQ=
ZVtPXPIMU90w-xwiXGhrjJQqZEI%3D%40topcheto.eu.