Re: Lua taking advantage of MCU MRAM

------=_Part_1013640_1132805361.1785454684170
Content-Type: multipart/alternative; 
	boundary="----=_Part_1013641_349468491.1785454684170"

------=_Part_1013641_349468491.1785454684170
Content-Type: text/plain; charset="UTF-8"

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

On Friday, 31 July 2026 at 00:51:40 UTC+12 Martin Eden wrote:

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

-- 
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/8acf8796-2494-4342-bbbf-389813be16e8n%40googlegroups.com.

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

<div>All strings that I'm aware of at compile time will be loaded (with the=
ir hashes) into MRAM instead of being interned. I'm finding it hard to figu=
re out the lifetime of strings created at runtime.</div><div><br /></div>Ev=
en though lua_Alloc currently passes the Lua type in osize when ptr=3D=3DNU=
LL (such as LUA_TTHREAD,=C2=A0 LUA_TNUMBER...), that is not enough for me t=
o determine how mutable it is.=C2=A0<div>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.</div><div><br /></div><div=
>Regan<br /><br /></div><div class=3D"gmail_quote"><div dir=3D"auto" class=
=3D"gmail_attr">On Friday, 31 July 2026 at 00:51:40 UTC+12 Martin Eden wrot=
e:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex=
; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hello Ryan=
,
<br>
<br>On 2026-07-30 01:24, Regan Ryan wrote:
<br>&gt; Has there been any thought given to whether Lua&#39;s VM could do =
it=20
<br>&gt; transparently or whether Lua syntax could be extended to support=
=20
<br>&gt; something like &lt;nonvolatile&gt; in the same way that &lt;const&=
gt; has been=20
<br>&gt; introduced?
<br>&gt; Strings and bytecode would be obvious ones to consider, but some=
=20
<br>&gt; strings will have very limited lifetimes.
<br>
<br>Since Lua 5.4 syntax allows marking variables at definition with attrib=
utes:
<br>
<br> =C2=A0 local LookupTable &lt; magnetoresistive_memory &gt; =3D
<br> =C2=A0 =C2=A0 {
<br> =C2=A0 =C2=A0 =C2=A0 [&#39;abc&#39;] =3D &#39;Some long string&#39;,
<br> =C2=A0 =C2=A0 =C2=A0 [&#39;def&#39;] =3D &#39;Another long terminal va=
lue&#39;,
<br> =C2=A0 =C2=A0 }
<br>
<br>So I think extension should add that attribute to specification.
<br>Of course this will require extension of VM instructions set.
<br>
<br>But keep in mind that Lua strings live in global pool of uniques.
<br>So that table definition will only allocate array of pointers
<br>in MRAM.
<br>
<br>-- Martin
<br>
<br></blockquote></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/8acf8796-2494-4342-bbbf-389813be16e8n%40googlegroups.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/lua-l/8acf8=
796-2494-4342-bbbf-389813be16e8n%40googlegroups.com</a>.<br />

------=_Part_1013641_349468491.1785454684170--

------=_Part_1013640_1132805361.1785454684170--