Sat Jan 11 15:30:50 CET 2020

Summary exok.c and discovery of the core issue

This is actually a simple and straightforward way to write CSP
directly in C.  It seems that it is only necessary to create the
proper overlay of the continuation.

struct env {
    uint32_t a;
    uint32_t b;
    uint32_t c;

#define COP(var,klabel,typ) \
    k->pval = &(var);       \
    k->next = &&klabel;     \
    k->op_type = typ;       \
    return;                 \

#define SND(var,klabel) COP(var,klabel,1)
#define RCV(var,klabel) COP(var,klabel,2)

void task(void *next, void *ctx, struct k *k) {
    struct env *e = ctx; // FIXME: not possible in general
    if (next) goto *next;

    e->a = 123;

    RCV(e->b, k1);
    e->c = e->a + e->b;
    SND(e->c, k2);
    SND(e->c, k3);
    goto again;

The thing that is "almost right" here is the assumption that we can
use the same struct for the input and the output environment.

That is where the core of the problem lies to convert this to C.

The rest is really straightforward standard ANF/CPS stuff.

In the example above, the stack is only growing, so the unused part of
the C struct is simply ignored, but no notational overhead is created.

In a more elaborate example, the C stack will "fork".  It's not quite
clear how to handle that.  One trick could be to use inline struct
definitions.  However in general it might be necessary to throw an
optimizer at the problem.

What is quite surprising is that this might actually work as a guide
to write CSP in C.

I.e. it is important to see that the conversion from task to state
machine is entirely on the inside of the tasks.  The scheduler doesn't
need to know.  It treats the task as a state machine.

That means that I can take my time to design the taks compiler, but I
can already start working on and using the scheduler.