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

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

On 18-05-12 01:39 , Paul Rubin wrote:
> 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.

Yes. It's weird how some people fall in love with strange things -- like 
Forth, or Ada...

> Its implementation techniques are startlingly clever

There have been compilers of higher-level languages that generate 
threaded code that looks like the code one expects from Forth; on the 
other hand, I believe there are now Forth compilers that can emit a more 
conventional kind of code. I'm not sure if threaded code was invented in 
connection with Forth, or was adopted in Forth because it suited the 
interactive environment.

If you want a thrill (hair-raising kind), have a look at how Gforth 
implements threaded Forth code by cutting and splicing machine code 
generated by gcc from C source for the interpreter.

> That said, its heyday was the 1970s-80s minicomputer era

Around that time, I was using an HP2100 16-bit mini (64 KiB of magnetic 
core memory) for controlling an astronomical radio telescope and its 
instruments. To replace the very limited HP-Basic which had been used 
before, we considered implementing a Forth system -- the commercial 
Forth costing more than the university was eager to pay.

In the end we used HP-Algol instead. The programming process was 
"interesting". To edit a source code file: load the interactive editor 
from paper tape, load the source code from paper tape, edit (as in 
Basic) the lines that need changes, save the edited source on paper tape.

To build the program: load the compiler from paper or magnetic tape 
(fortunately a single-pass compiler), load a source file from paper tape 
and compile it, get the object on paper tape, repeat for all changed 
source files. Then splice the new and old object-code tapes together 
with Scotch tape, load the linker from paper or magnetic tape, feed in 
the spliced object tapes, get the executable on paper tape, load that 
tape, press Run. Ah, nostalgia...

The interactive Forth had a certain attraction, in comparison.

> and (contra what the Forthers say) doing anything
> serious with it today seems to me like an exercise in masochism.

I agree. There are very few situations were I would consider using 
Forth; possibly for some very small embedded device that must be 
reprogrammable on itself, without cross-programming from a PC.

> Forth is usually implemented...   There is sometimes a cooperative
> multitasker that itself is just a handful of instructions that basically
> swaps stack pointers around between tasks.

I cannot resist to note that I implemented a cooperative multi-tasker 
for the HP2100 Algol system eulogized above. It was dirt simple: the 
machine had two working registers and no stack. Some of the users of the 
earlier Basic-based SW were amazed to see the typewriter terminal 
printing at the same time as the ADC was reading data at the same time 
as the magnetic tape was spinning.

Not having a stack meant that subprograms were not reentrant, so one had 
use a certain amount of care in choosing when to switch tasks.

> 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.

For the "2 2 +" part, yes. For the "." part, not so much. And once the 
program gets larger, knowing exactly which instructions the compiler 
will emit for each statement helps little to understand the whole, I think.

> Maybe mentioning Agile is poor recommendation here since I guess Ada
> users have a dim view of Agile.

Agile versus waterfall depends on the project's goals rather than the 
language, I feel. In some projects -- space on-board SW is typical -- 
the customer knows what is wanted, based on intense earlier analysis of 
the mission, its scientific or technical aims, SW/HW trade-offs etc. In 
agile projects there is flexibility in the scope, the HW, the 
functionality, everything.

IMO Ada is well suited for agile development, because you can refactor 
things wildly and the compiler will help you put it into shape again. In 
a less strict language, conflicts or incompatibilities caused by 
refactoring can stay hidden until the program fails with a run-time 
error -- much harder to correct.

(That said, the support that the GPS IDE currently offers for 
refactoring is very rudimentary, being limited to renaming things 
systematically -- usually one identifier at a time :-( )

>> 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.

I seem to have difficulty communicating my point here. Do you equate 
"dynamic" with "heap"?

In my view, if your system has a UART and accumulates incoming 
characters into a line buffer until in comes a CR to end the line, you 
are allocating space dynamically in the buffer for each incoming 
character. Now that is an extreme example, but I hope it shows what I am 
driving at: in principle, if the program uses up space, when needed, in 
any "memory" that can fill up, it is allocating that space dynamically, 
even if this "memory" is not the system heap.

>>> https://github.com/tomahawkins/atom
> ... 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 ;

In the WCET analysis community, this coding style is called "single-path 
programming". There are some advocates, and even some HW development for 
it. One has to rethink one's algorithms, but it is claimed that the 
worst case is usually no worse than for a conventional algorithm.

> That is, both branches are executed and then the condition selects
> which value to use.

Another approach is to execute only the selected branch, but to ensure 
that both branches use the same amount of time, inserting dummy 
instructions in the shorter branch if needed. There have been posts on 
comp.arch.embedded form people who are doing that.

Of course this approach does not work as well on machines that have 
variable instruction timing from caches etc.

> 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.

The problem in a main-loop system is combining high-frequency tasks with 
low-frequency tasks that do complex computations. The main loop has to 
suspend and resume the complex computation frequently, which is not so 
easy unless one does a full task-context switch.

>> 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.

I am reminded of the Mythbusters TV shows where the goal is to construct 
just about anything with duct tape :-)

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