(I am working on an IoT project, and most of my Lua demo code examples
would alreadly work in basic Lua (thus without using "openlibs" - this
would save about 50kB of my valuable 130kB ROM Code...), just
additinoally the string lib functions usually are needed for some very
restricted things ... so mainy only this string.sub, and a somehow
very "stripped down" function string.find (similar to strchr) also
would be sufficient for my needs...
You may drop some string.*() functions handling patterns if this is a concern, or just use these functions with the boolean parameter indicating plain-text search only, or not uses these functions and use another like string.chr()
would be somehow nice to have some
sort of "string-mini-lib" version for this - but it would somehow be
necessary to be documented by Lua, otherwise I think it would not make
much sense...).
You may also use tagging of NaN values to store the lua datatype if it's not à double, and as well allows to store bytes of very short strings (or an empty string) directly within a tagged NaN).
Tagged NANs can also be used to store some range of integers without converting them first to a double (and then use floatting point instructions or librairies). Your math library or arothmetic opérations on Lua numbers may also just support 32 bit floats so that values that all types would fit in a single 32 bit value (except largeur types requiring a pointer that could be still stores in a 32-bit NaN with such tagging of datatype, by converting the pointer to a small integer acting like a handle or object id referencing another external storage specific to each tagged datatype.
This can reduce a lot the memory needed, can improve the data locality (to get a higher rate of successful hits in CPU caches... including with modern 64-bit CPUs if you keep 64-bit double to use 64-bit NaNs for storing all non-number types, or short string values without tagging in the NAN an objectid to an external global table of strings or converting buffer pointers in user space with some alignement contraint into a small enough integer.
I've already tested the Nan tagging in 64-bit format, and definitely it is much faster and saves lot of memory, and its not even possible to exhaust the maximum memory allowed by 64-bit OSes for user space : you'll first reach the physical ram limite and your app will swap memory pages before you've reached the maximum capacity permitted by tagging NAN values (in most bits of their 52-bit mantissa). No modern is allows any user space program to use adresses longer than 48 bit, and once you pack short strings in tagged NaN, you can also add alignement contraints for string buffers, and all other pointers needed for complexe types like table, and so allow adding 2bits for handles/objectids, leaning that you can use a giant user space with 50-bit pointers... In practice, this limit will not be reached at all.
We clearly can safely use NAN tagging for very long time (as long as we don't use and bit 128-bit OSes for virtualized machines running over the whole internet). And this definitely faster and more efficient than using a 128-bit structure or a pair of 64 bit registers to handle ALL Lua values.
This just requires minor changes to the code in C that binds Lua values to native C types
