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

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

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.  

> on the other hand, I believe there are now Forth compilers that can
> emit a more conventional kind of code.

Yes, those have been around forever too: just generate machine
instructions instead of an address list, and maybe add a little bit of
peephole optimization.  In Forth jargon this is called "subroutine
threading".  Less common but also well-established are actual optimizing
compilers with register allocation, that track the stack flow so that
when the top few stack slots are in registers, words like SWAP generate
no code at all.

> I'm not sure if threaded code was invented in connection with Forth,

I don't think so.

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

Yes, that's quite amazing :).

> an HP2100 16-bit mini... we considered implementing a Forth system --
> the commercial Forth costing more than the university was eager to
> pay.

Hmm, http://forth.org/fig-forth/contents.html doesn't show a FIG-Forth
(public domain Forth) port to that machine, slightly surprising.  I
don't have the impression that the commercial Forths of the era
(Polyforth?) were very expensive for an institutional budget (i.e. they
were more like Janus Ada than GNAT Pro to use a c.l.a. comparison) but I
don't know your university's budget or what Forth Inc was actually
charging.

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

> The interactive Forth had a certain attraction, in comparison.

Exactly so.

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

It can also be useful to include Forth as a configuration or debugging
interface in an embedded device.  

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

Nice :)

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

Well Forth has something like a malloc heap but it's actually rather
rarely used, and I somewhat mis-used the term when I referred to heap
allocation.  The main chunk of storage in Forth is called the
"dictionary" because word definitions go there, but basically everything
else goes there too.  It's a linear chunk of memory where allocation
happens by moving a pointer forward, and de-allocation usually doesn't
happen except by rebooting the system.  So you'd create an array by
moving the pointer forward that many words, and then you'd have the
array forever.

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

I would say a typical Forth app wouldn't do that during operation.  It
might read single characters or fixed sized packets from the UART, using
a software protocol or hardware flow control to make sure the other side
didn't send stuff before the receiving program was ready.

For interaction, Forth traditionally has a fixed array called TIB
(terminal input buffer) which holds a line of input.  I'm not sure if
the standard says what is supposed to happen if you type too long a
line.  ISTR it says that TIB is supposed to be at least 84 bytes in a
conforming implementation, unless the limitation is documented.

> 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