lua-users home
lua-l archive

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


Hi John!

On Fri, Jan 9, 2015 at 7:40 PM, John Hind <john.hind@zen.co.uk> wrote:
I would be very interested in a single-chip Lua implementation like this:

http://www.espruino.com/Pico  - for _javascript_

or this:

https://micropython.org/  - for Python

But it seems that Lua's relative extravagance with RAM is still the major
roadblock (it has always been possible to build Lua for integer numbers, so
lack of an FPU has never really been a showstopper).

True for the FPU part. As far as RAM goes, I haven't looked closely at MicroPython yet, but _javascript_ also needs a lot of memory. 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). I wouldn't expect the platforms you mentioned to be much more memory friendly than (e)Lua, but this is just intuition, not facts.
 
512KB RAM is plenty to
run Lua, but only with very simple scripts. 

I dispute that, at least with eLua. You can write fairly non-trivial eLua programs in 512K RAM.
 
Bogdan's eLua is fun to play
with and a brave effort, but in my experience it is not really practical for
real-world applications without at least a two-chip platform (processor and
RAM).

While this obviously depends on the kind of real world applications you have in mind, I believe a chip with 512k of RAM is good for a lot of real world eLua applications.
 
One of the great advantages of Lua however is that it is relatively
easy to compile it for bare-metal deployment (i.e. without an operating
system).

What is needed is for the core team to have another look at the memory
allocation strategy so it is easier to build Lua to allocate volatile data
such as numbers and tables in RAM but non-volatile (or less volatile) data
like strings and function bytecodes in EPROM.

The upvalue-free C functions introduced in 5.2 are already a step in the right direction. The emergency garbage collector helps too. eLua already executes bytecode directly from Flash and reads strings from Flash (partially for now, hopefully completely in the future). I'm about to restart doing some memory analysis for Lua and port my LTR patch to 5.3 and I'm looking at other optimizations. I truly believe that all this + 512k of RAM or even less would make for a pretty awesome eLua single chip.
 
On these microcontroller chips
it is usually possible to write to EPROM, but you want to minimise that
because it is relatively slow and the memory has limited write endurance.
The big development on the horizon is FRAM which combines the non-volatility
of EPROM with the endurance and speed of RAM bringing back unified memory
architectures (von Neumann rather than Harvard for the computer science
majors amongst you). However only TI are offering FRAM single-chip
microcontrollers at the moment and these do not yet have sufficiently large
unified memories for Lua (or other interpreted languages).


I wouldn't hold my breath for FRAM, but let's hope I'm wrong. I'd like to see that too (or any other persistent RAM solution for that matter).

Best,
Bogdan