Xref: utzoo comp.unix.admin:1364 comp.unix.internals:2400 comp.unix.programmer:1395 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!ukma!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.admin,comp.unix.internals,comp.unix.programmer Subject: Re: How do you make your UNIX crash ??? Message-ID: <11313@dog.ee.lbl.gov> Date: 22 Mar 91 08:27:23 GMT References: <690@tndsyd.oz.au> <513@bria> <3442@engadm3.csd.mot.com> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 48 X-Local-Date: Fri, 22 Mar 91 00:27:23 PST In article <3442@engadm3.csd.mot.com> lance@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@ee.lbl.gov