Lua taking advantage of MCU MRAM

------=_Part_1029272_1812659188.1785367477148
Content-Type: multipart/alternative; 
	boundary="----=_Part_1029273_736337391.1785367477148"

------=_Part_1029273_736337391.1785367477148
Content-Type: text/plain; charset="UTF-8"

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. 


-- 
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/99387f8e-7e58-4a46-8796-d6eb6ab251fdn%40googlegroups.com.

------=_Part_1029273_736337391.1785367477148
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi. This is my first post on the group after monitoring it for the past yea=
r, so please go easy on me<div>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:=C2=A0</div><div><ul><li>XI=
P bytecode, with flash mapped to RAM address space</li><li>Flash-based stri=
ngs</li><li>Flash-based read-only tables</li><li>Modified heap manager usin=
g slab heaps of selected sizes to support commonly allocated objects (for s=
peed and reduced fragmentation)</li><li>Multiple lua threads with pre-empti=
on support</li></ul><div>I'm aware that there are many MCU-based Lua projec=
ts out there, some with small footprints like mine. I'm also watching the i=
ntroduction of MRAM very closely as it is set to revolutionise the way that=
 memory is managed.</div><div><br /></div><div>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 via=
ble as secondary RAM.</div><div><br /></div><div>As MRAM rapidly replaces f=
lash, Lua could better take advantage of it by providing cues to the heap m=
anager about whether allocation requests are likely to be volatile (ephemer=
al, often changed) or stable (changing infrequently, more persistent). Stab=
le allocations can still be subject to change.</div><div><br /></div><div>H=
as there been any thought given to whether Lua's VM could do it transparent=
ly or whether Lua syntax could be extended to support something like &lt;no=
nvolatile&gt; in the same way that &lt;const&gt; has been introduced?=C2=A0=
</div><div>Strings and bytecode would be obvious ones to consider, but some=
 strings will have very limited lifetimes.=C2=A0</div><div><br /></div><div=
><br /></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;lua-l&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:[email protected]">lua-l+unsubsc=
[email protected]</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
lua-l/99387f8e-7e58-4a46-8796-d6eb6ab251fdn%40googlegroups.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/lua-l/99387=
f8e-7e58-4a46-8796-d6eb6ab251fdn%40googlegroups.com</a>.<br />

------=_Part_1029273_736337391.1785367477148--

------=_Part_1029272_1812659188.1785367477148--