Re: How to get Ada to ?cross the chasm??

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 18-05-09 03:53 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> I think there was more to it: Lisp and relatives did not then provide
>> the standard functionality that most mainstream applications needed:
>> database functions, GUIs, real-world interactions, and so on.  They
>> were good in their niche, but it would have needed bravery (and
>> probably nonstandard language extensions) to embark on translating a
>> COBOL application into Lisp.
>
> Of course GUIs originated in Smalltalk and Lisp systems,

I should have said "UI" rather than "GUI", but my fingers were entrained 
by the currently more common acronym. I had in mind the vendor-specific 
SW tools for creating UIs to databases and other on-line systems, before 
the standard windowing systems and before the web.

> The smallest such systems, true, but the average smart phone these days
> has GB of memory and multi-core GHz processors.

Yes, but energy efficiency is becoming very important even there, for 
battery life and to avoid scorching the user's hands. If a 4x increase 
in execution time means the battery has to be charged 4x as often...

However, I suppose that with a proper OS, it is easier to divide the 
programs running on the device into "hot spots" -- programs/services 
that are always running and account for the major part of the energy -- 
and "cool spots" -- programs that are called up now and then, and for 
which the energy consumption is not critical -- and to choose the 
language for each program accordingly.

> MicroPython uses garbage collection and works fine (if
> the program is not too big) with 32k of ram.

Yes, "if the program is not too big". But I agree that there are many 
applications that fit in such small systems, even with GC and other 
less-than-100% efficiencies.

> This functional Lisp dialect for MCUs (written in Finland if you're
> feeling nationalistic) was also really cool for a while:
> https://github.com/sbp/hedgehog

Looks nice, and why not. There are certainly applications for 
microcontrollers where it is worth-while to use larger HW models to gain 
programming convenience and margins.

>> [bump allocation] In a multi-threaded system I believe a lock would be
>> needed
>
> I think GHC might use a separate minor heap for each thread.
> Surprisingly a quick scan of various literature doesn't establish this
> firmly though.  I do know that Erlang uses a separate heap per
> lightweight process, so some processes can run while others are GCing.

A thread can have its own initial heap, for short-lived thread-local 
data, but in my applications the bigger chunks of data usually end up 
being sent from one thread to another, implying either copying between 
heaps or some kind of inter-thread locking at some later point.

>>> idiomatic Haskell runs around 4x slower than idiomatic C
>> Not sufficient in most of the embedded applictions I have worked on.
>
> I'd expect those applications have hot and cold spots like everything
> else, so the 4x should also usually suffice.

The system engineers (a couple of levels above me in the industrial 
contractor-subcontractor hierarchy) are damnably good at specifying HW 
that is just about sufficient for the SW applications they specify. So 
one tries not to waste HW resources.

There are certainly "cool spots" in the applications that do not 
contribute much to the CPU load, and could be 4x slower without blowing 
the budget. Sometimes one can relax to a more functional programming 
style in those parts, but using different languages and run-time systems 
in "hot" and "cool" spots would be cumbersome in such bare-metal, 
single-program systems.

> Many space applications were historically written in Forth on much
> slower hardware than you're using now.

(I found a list of Forth applications in space at 
http://web.archive.org/web/20101024223709/http://forth.gsfc.nasa.gov/. 
Almost all from the USA, and most using the Harris Forth-oriented 
processor.)

Certainly some of the HW was slower. But the crux of the matter is not 
the absolute HW power, but the cost of margins: can one afford to buy, 
launch, and supply energy to a 4x more powerful processor, just to have 
the luxury of a functional or GC programming language? When the 
necessary algorithms can be implemented more or less as easily in a 
conventional, procedural, non-GC language?

> Forth traditionally used a simple threaded-code interpreter
> that (while quite memory efficient) was maybe 10x slower than assembly
> or compiled C code.  You'd use assembly for speed-critical subroutines
> and Forth for the rest.

Indeed, on small processors with weak instruction sets and short 
registers, using an interpreter can be very advantageous, decreasing 
code size with minor impact on speed. Even the Apollo spacecraft had 
part of their guidance SW implemented in that way.

> The convincing obstacles to Haskell or Lisp are
> more likely to be memory and nondeterminism, than pure speed.

It depends. In embedded SW there are often both very time-critical 
functions and less time-critical functions. Some space-based SW have 
used Lisp-like languages for the latter -- things like higher-level 
planning; failure detection, isolation and recovery; and other functions 
were AI methods are slowly entering.

>> While my current application has 8 MiB of RAM (up from 4 MiB in the
>> preceding app)...  But the processor clock is only some 60 MHz
>
> That's a big fast system compared to the historical Lisp environments!

Sure, but the application requirements are also larger. The CPU load in 
my current application is about 40%. Slowing down the code by factor of 
4x would be impossible with this HW. The system engineers do trade-offs 
between dedicated HW (FPGAs etc) and processor HW (SW functions) and do 
not provide lavish margins for the latter.

Some functions in space-based SW do have almost ridiculous amounts of 
time available. Many anomalies and failures can take hours or days to 
become critical -- say, a loss of attitude control leading to a loss of 
solar electrical power, which must be corrected before the batteries are 
drained. For such functions, the ability to easily program complex, 
AI-like algorithms would be welcome, and I believe is coming into use.

A final note: a couple of years ago, there seemed to be a group within 
the European Space Agency who were promoting Java for on-board SW (I'm 
not sure if this was some real-time Java with limited GC, or normal 
Java). I haven't seen any results so far, but then I don't have much 
visibility into ESA. The hot topic in ESA today seems to be model-based 
design and automatic code generation, which means that the coding 
language is seen as less important.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .