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

[Paul Rubin <no.email@nospam.invalid>]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> (Your mention of Forth I don't understand. I see Forth as one large
> step below C in language level -- cripes, one even has to manage the
> stack manually! -- and requiring extremely careful coding to avoid the
> program going off the rails. Moreover, I don't see any particular
> support in Forth for real-time aspects or control-flow restrictions
> such as loops with static iteration bounds.)

Forth is interesting and while I'd consider it lower level than C, the
Forth newsgroup participants would disagree vociferously.  It focuses
the mind to the point that someone wrote a book comparing it to Zen
meditation.  Its implementation techniques are startlingly clever and
I'd consider studying and using it to be a worthwhile exercise for any
serious programmer.  I use it in some personal projects because I like
the mental exercise and because of how it forces me to simplify problems
to their bare essentials.  That said, its heyday was the 1970s-80s
minicomputer era and (contra what the Forthers say) doing anything
serious with it today seems to me like an exercise in masochism.  I'm
far faster at C than I am at Forth, the opposite of what Forth
programmers claim.

Forth is usually implemented as a very simple threaded-code interpreter
(the "inner" or "address" interpreter) written in assembly language,
plus a source-language interpreter (the "outer" or "text" interpreter)
written in Forth itself.  The inner interpreter is maybe a few dozen asm
instructions and implements a 2-stack VM.  The outer interpreter is
basically an assembler for the VM, plus it often lets you write
definitions directly in assembly language with the assembler itself
written in Forth, using Forth syntax.  There is sometimes a cooperative
multitasker that itself is just a handful of instructions that basically
swaps stack pointers around between tasks.

The whole implementation is simple enough that the programmer can and
does understand and maintain the whole thing, all the way down to the
hardware (OS?  We don't need no stinking OS).  You can have a
respectable interactive interpreter in a few KB of program space using
maybe 100 bytes of ram.  Or you could have a complete IDE-like
environment on a minicomputer with 8k of ram and a floppy drive.

It's conducive to realtime control applications because there is such
a direct mapping between Forth code and machine code, even closer than
C in my opinion.  When a Forther types "2 2 + ." to the text
interpreter they can predict exactly what instructions the machine
will run.  There's not dozens of layers of libraries between the user
program and the machine.  There's usually no heap allocation, GC,
background tasks, or anything else happening while the program runs.

Its main touted feature is its interactivity: in some ways it's more
like using a debugger than a compiler.  You get some weird piece of
poorly documented hardware and you can put Forth on it, and start poking
at the control registers (defining functions to bang them in sequence
etc.) and figuring out what stuff does.

I got a couple of small STM8 8-bit MCU boards from Aliexpress for about
0.5 euro each.  They have 8K of program flash and 1k of ram, and they
can run a reasonable interactive Forth.  Forth must have had the same
attraction on 1970s minicomputers that an interactive Python prompt does
on PC's today.

This book about Forth development methods predated the whole Agile
movement by decades(?):  http://thinking-forth.sourceforge.net/

Maybe mentioning Agile is poor recommendation here since I guess Ada
users have a dim view of Agile.  I can sympathize with that, at least
as far as production code is concerned.  But even when one has to ship
reliable production code at the end of the day, it's useful to be able
to first slap out a crappy prototype that lets you explore the
possible feature space and implementation strategies.  Tools like
Python and (at the lower level) Forth are great for that.

I liked this article although Forthers complain about it and some of
their disagreements with it are valid:

http://yosefk.com/blog/my-history-with-forth-stack-machines.html

> The concept of "dynamic allocation" is interestingly vague. All
> real-time applications I've seen have dynamic allocation in various
> data buffers and queues, even if they never use the system heap.

Yeah I'm used to a much more limited style of realtime system, that
uses a few fixed memory locations or maybe fixed sized arrays, plus
some simple functions and loops, with no heap allocation after the
initialization phase.  But of course things can be much more
complicated.

>> https://github.com/tomahawkins/atom
> "Compile-time task scheduling" probably means fixed task frequencies,
> rather than event-driven, preemptive tasks, am I right?

Pretty much.  It's been a while since I tried it, but it is made for
HRT and its intended application was motor controllers, so not much
complex communication.  IIRC the user program is compiled to a single
event loop where the different "tasks" each get to look at each event
and possily act on it.  It is designed for constant-time execution, so
instead of

  if (condition) then f(); else g();

its conditional execution construct (called "mux" instead of "if")
compiles into

   r1 = f()
   r2 = g()
   result = condition ? r1 : r2 ;

That is, both branches are executed and then the condition selects
which value to use.  The whole program is constructed that way, so the
main loop is supposed to use the exact same number of machine cycles
on every pass, no matter what the individual tasks decide to do.

> New ideas as hard to get past product assurance people, who tend to
> be quite conservative (with good reason).

Yep, I'd be conservative about something like that too.  In a weird
way, even though Forth has no safety checks, its simplicity reflects a
form of extreme conservativism.