[rescue] Wanted: Old Sun Hardware

[Jonathan Patschke]

On Wed, 14 Oct 2009, Carl R. Friend wrote:

> At the point where the behaviour of a program may be non-deterministic
> based on the whim of the CPU, detailed tracing and troubleshooting --
> indeed "provability" -- becomes if not impossible, then impractical.

That depends on what level of provability you're after.

>   Please feel free to call me a throwback, but I actually like it when I
> can describe what a system is actually doing when it executes a program
> I have written.  This is best done at the gate level.

So, no MMUs, no microcode, and no interrupts (including a clock for
driving a schedule to facilitate multiprogramming), then?

It all depends on what you're trying to prove.  If you're trying to prove
the state of the entire system, that's really only possible for very small
systems.  The instant your CPU can be interrupted by something external to
your program, you can no longer prove machine state solely in terms of
your program, since whatever generates those interrupts is also an input
to the system state.

If you want to prove algorithmic equivalence, does it matter?
Out-of-order scheduling is usually guaranteed to be invisible (if it is
visible, that's a hardware bug); that is, a program should produce
equivalent results on an in-order machine versus and out-of-order machine.
This holds for very large complex programs (such as operating systems).

Intel and VIA both produce CPUs that are execute instructions out-of-order
(Intel Core and VIA Nano) and in-order (Intel Atom and VIA C7).  To see
the difference in running equivalent code, you need a logic analyzer.

-- 
Jonathan Patschke
Elgin, TX
USA