Re: Continuations

On 2024-07-14 19:14, John Levine wrote:

According to George Neuner  <gneuner2@comcast.net>:

At its simplest, a continuation is simply "the next instruction to be
executed", so any time you take/save a code address and then jump to
it you have executed a continuation.

That does not sound much like "continuation passing" to me.
I think of continuation passing as always ending a subprogram by calling some other subprogram, passing it one or more "continuation" subprograms as parameters, and expecting that callee to do something and then to "continue" by further calling one of those "continuations" (with further "continuation" parameters) and NOT to return to the original caller, ever.
By John's "simplest" definition, an ordinary call-and-return would be "continuation passing": the call "takes/saves" the return address somewhere, and the return jumps to that address.

This programming style is very old. The SAGE air defense system used
it in the 1950s, and SABRE copied it in the early 1960s. The software
was oranizaed into routines each of which took some input, did
something with it, perhaps scheduled other I/O operations, and then
explicitly saved its state and returned to the dispatcher.

I think that looks more like a multi-tasking system with run-to-completion, non-preemptive (small) tasks, considering each "routine" as a task and assuming that each routine started with recovering its saved context.
The main difference to present-day multi-tasking systems is then that the context-saving and -restoring was implemented separately and specifically in each task, and not in a shared "task switch" function.
There are today several real-time kernels that implement that kind of run-to-completion, non-preemptive multi-tasking.
Could you explain a bit about the "dispatcher" and how it decided which routine to execute next? Perhaps depending on which I/O had completed?