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

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

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> Yeah, I know about the syntax extensibility and "immediate"
> programming. But to me, considering practical programming, it is part
> of the "frightfulness" of Forth.

Of course.  Calling something a work of genius is not necessarily nice.
It might be a work of evil genius ;-).  Anyway though Forth is
fiendishly clever beyond the sum of its parts.  It's a combination of
ideas that are individually no more than cute, but it all fits together
in a cohesive and ok frightening way ;).  The one-pass
assembler/compiler and the (no longer much used) block storage system
were other parts.

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

Meh, if you want a minimal theoretical machine, try SK combinator
calculus.  Forth was nuts and bolts (im)practical, very much about
wringing maximum use from those old small machines.

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

I don't know if eForth existed in that era but it's extremely easy to
port.  It's written in itself so there's a bootstrapping process were
you code 20 or so primitives in assembler (a handful of instructions
each) and that's enough to make it run.  This is what I use on the STM8
and it takes about 4k of program space.

> As I wrote, BASIC was used previously at this sit... 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!

Heh, but BASIC had arrays?!!  So A(1), A(2) etc could be used for
different purposes ;).

It looks like you can still run HP-2100 ALGOL under emulation:

http://simh.trailing-edge.com/pdf/hp2100_doc.pdf
http://simh.trailing-edge.com/docs/hp2100_algol_howto_doc.txt

> The HP2100 had instructions which could more easily access the "base
> page" of RAM,...

Yeah that's pretty standard in old processors including more recent ones
like the 6502 (still used by Forthers with old Commodore 64's).  

> I made a post-compiler program (in Algol) that ... punched out a
> relocatable object-code tape that was altered to eliminate or reduce
> base-page use

Interesting that the HP compiler didn't deal with this issue itself.
Machines like that were mostly before my time so I wonder what the usual
strategies were.  I think the 8051 MCU (still used in embedded systems
today) has the same design and there are lots of C compilers for it
so they must handle it somehow.  The base page is 128 or 256 bytes iirc.

> [Atom] 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.

Well I think the idea is you just have a few variables for the state,
and each pass through the main loop does a single iteration of whatever
loop your computation was doing, then updates the variables.  I don't
know if the approach is suitable for anything extremely complicated

> one of the slides suggests that Atom generates C code ("returns single
> C function to be called at base rate")

Yes it just generates a chunk of C code.  I remembered it generating a
big loop but it's been a while, so yeah, it's probably a single function
that you call from a loop that you write yourself.  It could be adapted
straightforwardly to produce Ada code or whatever instead, if someone
wanted that.

It's good to be reminded of it since it occurs to me that I have a
project it could actually be good for, running one of those multicolored
LED strips that you control with precisely timed pulses.  I've actually
been planning to do that in Forth but Atom is another possibility.

> control SW for the MIXS and SIXS instruments on the ESA Bepi-Colombo
> Mercury orbiter... Each second of real time is divided into 1000
> slices of one millisecond each, and various small "tasks", similar to
> Atom "rules"...

I wonder if that is too complicated to really fit Atom's single-path
approach.  In the example hydraulic app, there weren't many things going
on, but they had to happen exactly on schedule.