How do you make your UNIX crash ???

[Chris Torek]

In article <3442 at engadm3.csd.mot.com> lance at motcsd.csd.mot.com
(lance.norskog) writes:
>Awhile back, someone found that executing random data made quite
>a few RISC chips sieze up.

False.

In fact, the program caused a number of *operating systems* to crash.
As I recall, the only chip bug it exposed (one that was already known
anyway) was in a ``CISC'' (namely, one of the older 80386 implementations).

The ability to crash any particular operating system is not a useful
indicator of the reliability of any particular microprocessor.

That said, one should note that the more complex something is, the
easier it is to make a mistake when implementing it.  Bugs are often
found in complex-addressing-mode CPUs (until fixed in a later revision)
when:

  - an access-probe instruction crosses a page boundary
	(example: VAX 11/780)

  - a read-modify-write instruction crosses a page boundary
	(example: NS32016)

  - an exception occurs while recovering from an exception, e.g.,
	a parity error during a register state retract during a
	page fault.

In general, ``RISC'' chips avoid all these bugs by outlawing the
situations under which they occur: their instructions never cross page
boundaries, they do not provide r/m/w instructions, and so forth.
There is, of course, a wide spectrum of actual implementations, with
varying degrees of ``RISCness'', and simply not providing an operation
does not obviate any existing need for something equivalent.  In other
words, this sometimes merely moves complexity from point A (the
hardware) to point B (the software).

Finding the correct balance of simplicity and functionality is what
machine architecture is all about.  If you think you can do better than
``RISC'' (whatever that is, besides a marketing word---like obscenity,
we all know what RISC is when we see it, but no one can define it), by
all means, gather some venture capital and start a new company.

(There, have I managed to avoid pushing anyone's buttons? :-) )
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov