Re: Execution of bytecodes

[Karel Tuma <kat@...>]

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:

https://github.com/elua/elua/commit/d54659b5723bcd2b1e3900362398c72c18a9aa0b#diff-11aa8ea7184c7ca4c7043df1d3250797

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