[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: guarantees of exception safety in Lua
- From: David Kastrup <dak@...>
- Date: Wed, 29 Oct 2008 10:52:16 +0100
David Kastrup <dak@gnu.org> writes:
> David Given <dg@cowlark.com> writes:
>
>> 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.
>
> Fortran machine architectures tended to be stackless. I remember the
> CDC machines (Cyber 175 was what I used) having a "return jump
> instruction". Before jumping to the given destination, it wrote a jump
> to _after_ the RJI instructions into the memory word preceding the
> destination. When the called function finished, it jumped to this
> instruction preceding its body.
>
> Of course, recursive function calls were not possible.
I'm getting old. The instruction was just named "RJ", and it wrote to
the memory word _at_ the destination and then continued. Just took a
refresher from <URL:http://klausler.com/cdc6600.txt>
--
David Kastrup