I'll accept that I'm programming an ENIAC when
I can stick my voltmeter
on it and measure the 500V (or whatever) HT+ (B+ across the Pond). When I
can clip my 'scope on various testpoints. When I can warm my hands over
all those nice valves :-)
In one of my classes, we just had a guest speaker from Tera (the local super-
computer firm). He explained that this is exactly what is _not_ possible
with their machines, because the circuitry is so dense that testing like
that would disturb it. Tera's solution is very interesting but somehow I
suspect you would not approve.
The solution, BTW, is to use a method called SCAN. I assume that's an
acronym but I'm not sure. Their machines contain blocks of combinatorial
(stateless) logic separated by latches for pipelining purposes. The
latches can be "commutated" so that they connect to each other like a giant
shift register, rather than acting in parallel. Then the appropriate values
can be fed in and the combinatorial logic exercised for one clock tick.
(The point is to test the combinatorial logic and hope that the latches and
other test circuitry are working normally.)
There are many refinements, of course, but that's the essence of it. (There
are mulltiple SCAN paths; there are un-commutable latches to prevent test
data from being sent to the disk controller and erasing the filesystem and
other such calamities; there are specialized test controllers in every
machine.)
As a bonus the test circuitry is also used to boot the machine (by loading a
program into the cache, etc.) In that sense execution is the ultimate test
of the circuitry. :)
The speaker also noted that Tera's method is completely superior to Intel's.
-- Derek