Re: [Gnu-arch-users] Round III: xl and all that

[Tom Lord]

    > From: Jan Hudec <address@hidden>

    > >   The first step in the reduction has to try to reduce `two-power' in
    > >   the definition of `maybe-prime'.   It does that by changing the
    > >   $subgoal but leaving $goal alone:
    > >   [...]
    > >   The rule for what happens when $goal and $subgoal are different, and
    > >   $subgoal is fully reduced, is that $goal is copied to $subgoal:

    > Why isn't $goal a sequence of symbols? When different subgoal is needed,
    > it would be pushed and when finished poped again. (Terminating condition
    > is then that the last goal was poped).


Basically, $goal is not a stack of goals in order to provide an easy
to understand and use semantic model for parallel execution.

Suppose I have a definition:

        (define do-stuff  (parallel thread-a thread-b))

If that starts off evaluating thread-a, then as soon as thread-a gets
to a variable-binding reduction step, it comes back to evaluating
do-stuff again.  So the special form `parallel' is reconsidered and
this time it runs thread-b.  When thread-b gets to a variable-binding
reduction step its back to thread-a and so on.  (Of course, there's
many variations on `parallel'.)

Positing $goal is an easy way to model that parallelism.  The
alternatives (making threads primitive to the VM) seem far harrier to
me and also seem to make it harder to answer questions about 
the set of possible traces through various formula.

(There are really two operational models -- the one i posted and then
the one you really want to use to implement xl1.   The practical one
does have a (sorta-kinda) stack but the register contents of the
practical VM are isomorphic to those of the idealized VM that I
posted.)

Another way to say this is that:

        (define <name> <expression>)

is _conceptually_ (roughly) equivalent to:

        thread_<name>()
        {
          <name> = <expression>;
          switch ();
        }

where $goal is the register that determines what thread is resumed by
the next `switch()'.


    > [... trace showing why a stack is a good idea ...]
    > Since it's deterministic, 

Exactly.   By not using a stack we leave the door open for adding
non-deterministic operators.

    > What is the reason not to use it?

To leave the door open for adding non-deterministic operators.

-t