lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Excerpts from Sean Conner's message of 2015-10-03 01:02:26 +0200:
>     const unsigned char c_blah[] = { ... };

Yes, that's how it's normally done. Alternate route is to write linker
script and construct ELF .o object files directly - in rare cases when
generating A LOT of data this way, and C compiler speed would be an issue.
> On modern Unix systems, const data like this is kept in memory marked as
> read-only.  If there is memory pressure on the system as a whole and memory
> needs to be "paged out", then such read-only sections can just be dumped and
> not written to the paging system since if the pages are needed, they can be
> paged back in directly from the executable on disk.

Yes, but again, premature optimization on modern systems.
>     1,045,919    uncompressed Lua bytecode
>       937,183    compressed Lua bytecode
>       921,587    compressed Lua source code

Don't do this. Use UPX with LZMA if the point is to reduce size of the whole
result on disk (interpreter+uncompressed script). Memory usage is essentialy
the same here, even with very large scripts - the polluted heap from
decompressor gets eaten by Lua heap during runtime anyway.

Bottom line:

As for actually using custom buffer without copying, this is
called XIP - "execute in place" in the embedded world. Special memory address
regions sit in flash memory and making a RAM copy is simply not possible
because there's not enough RAM (think 64kb SRAM chip, with 1MB flash).

For an implementation of XIP in Lua, see:

It would be nice if Lua supported XIP out of the box - by allowing
additional contract where user can load chunk from XIP region.
With constrained devices, opcodes and especially constant tables - 
strings, table initializers kept in flash at all times is essential.

-- k