Re: Estimation of memory alloc for luaL_loadfile

[Alexander Chernoskutov <alecherov@...>]

Gonna joint the discussion. I've ported Lua to STM32 too, with 80-250k 
of RAM.
Had a test build with what I'm gonna call "ROM strings". My solution was:
1. `loadfile()` the target program on the PC Lua
2. Via some modifications to Lua, dump internal strings hash table along 
with the seed into a file.
3. "burn" the table into the microcontroller along with the Lua program
4. Modified Lua inside the microcontroller would take a pointer to the 
pre-build strings hash table and will use strings from there whenever 
possible. These strings are never freed (they're in ROM).
It is easy to distinguish 'normal' strings from 'ROM' strings simply by 
looking at the address value of the pointer (ROM and RAM have different 
address spaces).
Essentially there were two strings hash tables: one static in ROM and 
one dynamic in RAM.
In the end it was too cumbersome to maintain and use, but it lowered RAM 
consumption approximately by half in my case.

--
Regards, Alexander Chernoskutov
@alexcherov (telegram)

On 26.07.2023 18:48, Roberto Ierusalimschy wrote:
> > Last time I looked at the source code, Lua didn't really have a concept of
> > "ROMability", in the sense that you can't save data structures in ROM/flash
> > and use them directly from there (without having to load then into RAM). In
> > eLua it's possible to use the compiled bytecode directly from flash and
> > there's also a "read-only string" type that keeps the *content* of the
> > string in flash (just the content, not the whole TString data structure)
> > and uses it from there. But all these require changes to the Lua source
> > code.
> Both would be interesting additions to next version. By "read-only
> string" do you mean a string that is never freed? (All strings
> in Lua are read only...)
>
> -- Roberto