lua-users home
lua-l archive

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




On Sat, Jan 10, 2015 at 4:01 PM, John Hind <john.hind@zen.co.uk> wrote:
> I believe a chip with 512k of RAM is good for a lot of real world eLua
applications. <Bogdan Marinescu>

Have you considered doing a Kickstarter like the Python and _javascript_
examples I referenced?

There was some activity in this area, but we have nothing to show for it yet.
 

> I don't think Lua is taking lot of RAM, all dynamic languages that I know
of need a lot of RAM (for good reasons) . <Bogdan Marinescu>

There is an idea that has been rattling about in my mind for a few years
now, but it may still be a little half-baked. This is that it should be
possible to allocate the bytecodes of functions/closures separately from any
required volatile storage (for example upvalues). The latter would be stored
in RAM, while the bytecodes would be stored as immutable strings (strings in
Lua already being  byte-safe and immutable).
[snip]

Again, eLua already does that. When you compile a Lua program to bytecode and upload it to the internal flash, the bytecode is executed directly from flash. You can also use strings directly from flash, in which case a TString has two parts: a header (dynamically alocated) and a pointer to the actual content (in flash). It's even possible to put the whole TString structure in flash, but this sacrifices elegance and portability (which is not to say that I'm not going to do it eventually). Similary, an eLua rotable lives completely in flash. I believe there are other things than can be moved to flash. This fails (or at least is useless) on pure Harvard archictures, but personally I don't know of any modern 32 bit MCU based on a pure Harvard architecture (except maybe the new ESP8266, I'm still trying to understand that thing).
 
I'm still waiting for the _javascript_ kickstarter chip to be delivered so
time will tell how useful it is. _javascript_ has the big advantage that being
intrinsically event-driven it fits well with interrupt-driven
microcontroller applications, but compared to Lua it is an ugly, bloated
language, and Python is barely better without even the advantage of being
event-driven.
But I think it would be relatively easy to write an
event/interrupt driven scheduler for Lua coroutines.
 
Yes. Strictly speaking, _javascript_ isn't more event driven than Lua. It's just that a lot of things around _javascript_ happen around node.js and its event loop (which is something very interesting and I'd like to see that in eLua at some point). But you can implement that model equally well in Lua, Python and many other languages.
 
Best,
Bogdan