Forth and others (Was Re: How to get Ada to ?cross the chasm??)

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

(I changed the Subject as it was drifting so much off-topic.)

This discussion is degenerating into anecdotes about the bad-old-days of 
computing. But perhaps it is good to be reminded, now and then, how much 
better things are today :-)

On 18-05-12 21:37 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>> 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;
>
> Sure, threaded code has been around forever, but Forth's cleverness goes
> way beyond that: see Yosefk's article that I linked to.

Yeah, I know about the syntax extensibility and "immediate" programming. 
But to me, considering practical programming, it is part of the 
"frightfulness" of Forth. I believe that Rust has a syntax macro scheme 
that goes in that direction, but not so far.

On the theoretical level, I admit that it is interesting to see how far 
the basic Forth machine can be expanded in various directions by such 
definitions. Rather like demonstrating the Turing completeness of some 
very small set of machine instructions.

>> an HP2100 16-bit mini... we considered implementing a Forth system --
>> the commercial Forth costing more than the university was eager to
>> pay.
    ...
> I don't have the impression that the commercial Forths of the era
> (Polyforth?) were very expensive ... but I don't know your university's
> budget or what Forth Inc was actually charging.

The university's budgeting principle, at least for astronomy, seemed to 
be: staff work is free (we have to pay you anyway, we don't much care 
what you do, and we can't fire you easily) but you have to fight for any 
cash you might want for buying stuff.

I don't remember how much Forth Inc asked, and we probably did not know 
about any other sources of Forth implementations.

>> 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...
>
> Yikes!  Yeah people like Forth because it avoided that type of thing.
> BASIC might have been another possibility?

As I wrote, BASIC was used previously at this site. However, the 
applications were exceeding the abilities of BASIC. It was not fast 
enough, it did not do multi-tasking, and -- hold on to your hat -- the 
programs were running out of variable identifiers!

The HP-BASIC in use allowed variable identifiers of the form: one letter 
A-Z followed by one optional decimal digit. My boss at the time was the 
director of the radio telescope site and had written many of the BASIC 
programs. For each BASIC program he had a paper sheet ruled with eleven 
columns, for the digits 0-9 and "no digit", and rows A-Z, with ticks in 
the letter-digit boxes for the variables used in the program.

I believe the BASIC system had no "search" function or "list variables" 
function, so this was the only way he had of keeping track of his 
variables, short of reading through all of the source code of the 
program. Naturally, REM comments were used very sparingly, because they 
consumed memory, and consumed paper tape. And each REM used up a line 
number, so you could not insert a REM between lines 110 and 111 without 
renumbering the program, and then you lost your own memory of which line 
numbers were which subroutine for GOSUB.

And now these paper sheets were filling up, with few or no empty boxes 
left. So the programmer would have had to start reusing variables for 
different purposes in different parts of the program. Of course this 
BASIC had no local variables.

Forth or Algol would solve this problem, and increase execution speed too.

I cannot resist relating that while Algol solved the problem with the 
identifier space filling up, we ran into another problem involving 
programs with many variables:

As the machine had no stack, all variables, local as well as global, 
were statically allocated locations in RAM. The HP2100 had instructions 
which could more easily access the "base page" of RAM, a chunk of RAM (I 
forget the size) starting from address zero. The Algol compiler 
allocated many variables (I believe all scalar variables) in the base 
page. If you had too many such variables -- as we of course had, after a 
while -- the program failed to link, due to base-page overflow, although 
there was plenty of RAM left at higher addresses.

Being at the time young and full of vim, I made a post-compiler program 
(in Algol) that read in the relocatable object-code tape produced by the 
Algol compiler and punched out a relocatable object-code tape that was 
altered to eliminate or reduce base-page use (I forget the method I 
used, but it may have been to make all references indirect via the base 
page, so allocating only one base-page word for each variable). That 
saved the day, and were were able to write, compile, and link the 
programs we needed.

Later on, the HP2100 system was replaced by a MicroVAX and DEC Ada. So 
now we are almost back on topic; but I have to report that, even later, 
when I was no longer working there, Ada was replaced by some 
curly-bracket languages.

>> 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.
>
> Atom has some stuff to help with that.  You might like the CUFP slides,
> that are still in wayback:
>
> https://web.archive.org/web/20131220122421/http://cufp.galois.com/2008/slides/HawkinsTom.pdf

Sorry, I do not see where that presentation addresses this issue of how 
to suspend and resume a complex computation which has lots of state. 
Maybe it is easy to do in Haskell (perhaps save a continuation?) but one 
of the slides suggests that Atom generates C code ("returns single C 
function to be called at base rate"), and suspend/resume is not easy in C.

As an example of this problem, one of my colleagues used a main-loop 
design for the control SW for the MIXS and SIXS instruments on the ESA 
Bepi-Colombo Mercury orbiter (to be launched in October, I believe). 
Each second of real time is divided into 1000 slices of one millisecond 
each, and various small "tasks", similar to Atom "rules", are executed 
in these slices, spread across the 1000 slots according to the desired 
frequency of each "task". However, in several cases the "tasks" want to 
execute loops that take too long to fit in a slot, so the loop has to be 
stopped (suspended) and the stop point (loop counter) stored, to be 
resumed in a later slot. This complicates the program logic considerably 
for those "tasks", especially for nested loops.

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