lua-users home
lua-l archive

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

Diego Nehab wrote:
> I remember somebody from NASA at a Lua conference some time back saying
> lots of people that write software there don't believe in dynamic memory
> allocation. They don't even believe in functions from the C runtime. They
> write their own stuff from scratch, just to make sure. Everything
> static, no recursion. Just for loops. That gives me a warm feeling of
> safety.

That's actually very traditional in the hard embedded world --- if you
look at platforms like VxWorks or Nucleus you're frequently see that
dynamic memory allocation --- malloc --- is an optional feature.
Instead, all data is stored in globals, which get allocated by the
linker at compile time.

Going even further, if you don't need reentrant functions, you can do
away with the stack --- all function parameters become global, and each
function gets exactly one return address. This can be useful on really
resource-limited machines, because you can make much more efficient use
of memory; stacks inherently waste memory because you have to allow
space for them to expand into.

But it's also useful because it makes the application much more
predictable, and therefore easier to verify. It becomes much easier to
statically find programming errors and to verify that functions are
guaranteed to exit on time, etc.

As late as 1996, spacecraft like the Sojourner Mars rover were running
off 8085 and their ilk, and that early spacecraft like like the Viking
orbiters only had 4k of 18-bit words of memory --- 2k for code, 2k for
data. The Pioneers and the Mariner Mars probes had CPUs constructed out
of discrete TTL logic components! It's only relatively recently that
space vehicles ran anything like what we'd consider to be 'normal' code.
>From the computing perspective, it's an utterly different world in space...

In a desperate attempt to bring things back on topic, I'll point out
that it would be possible to make a no-dynamic-allocation Lua subset,
but it wouldn't be very like what we'd consider to be Lua: no table
creation, no assignment to arbitrary table keys, and a very limited
amount of function nesting. It'd probably be relatively straightforward
to compile it to machine code, TBH, because it wouldn't support any of
the dynamic features that make Lua Lua... I wonder if such a thing would
be useful?

David Given