Alfredo writes:

> >When he writes about a "signal-based, synchronous" model, he *is*
describing
>  >a finite state automaton. And in that regard, I don't mind a bit giving
> away
>  >the two most important take-home lessons of the class:
>  >
>  >The First Rule of Open-Loop Programming: "Never do it."
>  >The First Rule of Asynchronous Programming: "Never do it."
>  >
>  >All devices, whether they are software- or hardware-based, interact with
>  >their environments through an alphabet of signals and triggers. You, as
the
>  >designer, want to expel every bit of probabilitistic behavior out of
their
> design.
>  >Everything you do, you want to make as simple as possible -- and you want
> it to
>  >be 100%, fully deterministic.
>
>  To add more chile to Wirt's soup, you might want to review Ivan
Sutherland's
>  Turing-Award material:
>  http://research.sun.com/async/Publications/KPDisclosed/micropipelines/
>  cmicropipelines.pdf

If you're suggesting that Ivan Sutherland is disagreeing with what I am
saying, that wouldn't be accurate. In fact, he's arguing exactly the same design
philosophy, but in hardware, not software. As I mentioned earlier, the finite
state automata approach works just as well in hardware, either analog or
digital, as it does in software, and that's part and parcel of its beauty.

I wrote earlier, "... you must know what state you are in at all times, and
that entails building a top-most "wait loop", which itself is often governed by
a heartbeat sequencing timer, attributes which occur in all synchronous
machines. If you do this, you can build systems of amazing behavioral complexity
surprisingly simply."

I mention this again only because that idea is key to Sutherland's argument.
If there's any confusion, it's in the term "asynchronous." All inputs and
outputs to a system are asynchronous in one sense: there is no grand clock in the
universe. Inputs arrive essentially randomly. But the system, if it is to be
reliable, must be synchronous with whatever it is in communication with, and
that can only be done in a closed-loop, know-what-state-you're-in-at-all-times
transition structure.

As for the innards of the system, it can be "asynchronous" (if you define
that in a more narrow form as no internal clocking) or "synchronous" (containing
an internal heartbeat). If a program or hardware processor is simple enough,
you can quite often get away with nothing but a wait loop design. Indeed,
that's what Sutherland says about his pipeline processors: "Because pipelines are
event-driven, their simplicity is not available within the clocked-logic
conceptual framework," but they're not asynchronous in a global sense. If they were,
they couldn't possibly begin to work.

But once the process becomes complex, especially if it is trying to
manipulate several processes in parallel, a heartbeat scheduler (either an internal
program or a central CPU clock in hardware) quickly becomes essential to good
design, and that is a part of what I was going to talk about in the class.

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *