Hi,
some assumptions really have short life... Last week in by "lua-resume/lua-yieldk post" I proclaimed clearly, that I would not think of using Lua in integer only CortexM0 devices as STM32G0 series... but meanwhile I "licked Lua blood". And the recent STM32G0B controllers really at least for QFN32/5x5mm housing size allow > 100kB RAM (STM32G0B has 256 or 512k ROM/ 144kB - a nice possible way to go for small Lua things would then possibly also support already 128kB ROM / 36kB RAM of STM32G07 in the cute WCLSP28 2.5x2.5mm housing).
The main restriction for the core Cortex M0+ is:
- no floating point
- no Divide command
But they are all M0 PLUS(the + mainly means that they have 32bit multiply command :) ).
The missing Divide command can somehow be "accepted/ignored", as divide for integers can be done also very efficiently by compiler in typically 30-100 core cycles (and even core-managed device will in most times, like in Cortex-M4, be NO 1-cycle command, but need 10-30 cycles, at least for 3 or /64bit integer divide...).
But the missing floating point means, that if I want to run Lua on such a controller, it should be "free of floating point" (if you allow floating point, this will typically "eat controller resources excessively", as floating point math will be is about 1000 times slower than fix point math, and floating point support also will add about 30kB ROM need, and I assume that for a "small Lua application" floating point can be somehow "mainly avoided").
But somehow for the "lazy Lua user" it would important to be able to use some "sort of floating point numbers" anyway... .
I am quite sure that my "standard Lua users" for such a "stripped system" would be happy, if e. g. the float numbers have fix resolution of 1 permille, so 3 digits after point... and then I would propose to use in Lua Fix-Point math with 20 bit "before digit" and 10 bit "after digit" (so then max. number 1E6, and fix resolution of 0.001), and then 1 bit for sign and 1 bit for NAN/INF signaling.
Optimally nice would be, if the "pre-digit"/"after-digit" counts could be somehow configured in Lua conf file, as 14 digits will be required for resolution of 1E4 and 16 digits for "nearly 1E5", very well 14 pre/16 after, or 16 pre/14 after digits would make sense (or 10 pre/ 20 after for ppm resolution fix point math numbers).
So my dream for a "stripped Lua" for such Cortex-M0+ systems would be the following:
- float calculation replaced by fix point math with fix pre/after digits
- ministring lib (no pattern search ... mainly only support of printf and basic number/integer/string conversions)
- minimath lib (no cos/sin... possibly also no exp/log)
- no table support (at least no meta support)
- no coroutines (except please C support for yieldk and resume to allow cooperative "Lua-multithreading" by C support)
- only basic libraries (no file-io, no os,...).
To all who already have used "stripped down Lua systems" already 2 questions (I assume restricting to "basic libs" is very straight forwrad, so no question about this):
- Is it quite easy to strip support of tables and coroutines? (or is e. g. Lua code itself using "table handling" so dominantly, that this would not make sense).
- Is it quite easy/feasable to replace float math by such a "fix point" integer math?
... if somebody has done something similar like this already, I would be curious about the minimum ROM/RAM sizes which would be required by Lua after such "basic stripping down"
