Hi,
I guess the 10k figure was for eLua RAM usage, my bad: http://www.eluaproject.net/doc/v0.9/en_arch_ltr.html
Thanks for the pointers, I have removed external libs already, and using integers gives me a 2k reduction in the executable size.
I will try removing scanf.
How little has Lua been ever compiled to which keeps all language features of say Lua 4.0? Has anyone tried going back further to Lua 3.0 for example?
I have applied
http://www.lua.org/extras/5.3/noparser.c as well on Lua 5.3 and the size as I mentioned was about 63k on x86. Our last figure with -O2 was 59k on ARM. I will check if we can drop in the
Newlib-nano and try higher optimizations.
I decided to give Lua 4.0.1 a shot, and got about 27k on ARM with external libs removed and integer number type. I tried removing all opcodes too just to see how much of a difference removing opcodes can potentially make and got a reduction of about 5k(I will of course be keeping only the opcodes that I see in the bytecode disassembly of my lua code). I assume each opcode is totally independent.
I also realized that I could remove some of the functions from lapi.c which I do not need to bind any C functions, might give me some 1 or 2K.
Someone mentioned removing metatables from the Lua code base. Is that easily removable by removing a function or two?
Is there a regression suite I can run after removing opcodes to check if expected language features still work? Like say just function calling and table access.
Thanks
Abhijit
>> What are my other options to reduce the size? (...)
> You may get rid off the metatable, it can reduce many codes.
I am curious about this. Has anybody built a Lua derivative without metatables?
Is it feasible? or are metatables too deeply intricated with the Lua VM?
What would be the gain? (executable footprint, performance?)
