aglew@crhc.uiuc.edu (Andy Glew) (09/12/90)
A short while back there was a brief flurry about a program that caused an OS crash when run on a variety of RISCs, but seemed to have no problems on CISCs. As I recall it, it executed data (and the OS wasn't handling traps well). Somebody eventually found a CISC it also bombed on. Has anyone saved these postings? Can he (or the poster of the CISC crasher) mail the posts to me? -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
chris@mimsy.umd.edu (Chris Torek) (09/12/90)
In article <AGLEW.90Sep12014046@dwarfs.crhc.uiuc.edu> aglew@crhc.uiuc.edu (Andy Glew) writes: >A short while back there was a brief flurry about a program that >caused an OS crash when run on a variety of RISCs, but seemed to have >no problems on CISCs. > >As I recall it, it executed data (and the OS wasn't handling traps >well). Somebody eventually found a CISC it also bombed on. Right. (The CISC was the 80386, as I recall. Current 80386s have that bug fixed.) I was extremely tempted to follow up the 80386-bug with something saying `ah, yes, this clearly demonstrates the superiority of CISC architectures' ... so now I am: :-) Note that, on all the machines that crashed *except one*, it was a bug in the OS and not in the chip. The one exception? A CISC. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
schow@bcarh185.bnr.ca (Stanley T.H. Chow) (09/17/90)
In article <26507@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: > >Note that, on all the machines that crashed *except one*, it was a bug >in the OS and not in the chip. The one exception? A CISC. >-- >In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) >Domain: chris@cs.umd.edu Path: uunet!mimsy!chris kinda expected. Don't you think? After all, the whole point of RISC is to move the complexity from the chip to the S/W. But it is still a nice demonstration that the complexity didn't go away, just moved. Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!uunet!bnrgate!bcarh185!schow (613) 763-2831 ..!psuvax1!BNR.CA.bitnet!schow Me? Represent other people? Don't make them laugh so hard.
guy@auspex.auspex.com (Guy Harris) (09/19/90)
>kinda expected. Don't you think? After all, the whole point of RISC is >to move the complexity from the chip to the S/W. But it is still a nice >demonstration that the complexity didn't go away, just moved. And, perhaps, a useful demonstration as well. I remember seeing somebody arguing against RISC because it requires people to put complexity into software, not realizing that if you move it into hardware it doesn't go away, it just moves....
aglew@crhc.uiuc.edu (Andy Glew) (09/19/90)
>>kinda expected. Don't you think? After all, the whole point of RISC is >>to move the complexity from the chip to the S/W. But it is still a nice >>demonstration that the complexity didn't go away, just moved. > >And, perhaps, a useful demonstration as well. I remember seeing >somebody arguing against RISC because it requires people to put >complexity into software, not realizing that if you move it into >hardware it doesn't go away, it just moves.... The systems whose OS was broken will have a fix in the next OS update, maybe even a patch before that. The systems whose hardware was broken will have to wait for a new processor design, or at least a mask revision, and then they'll have to replace the socketed MPU at best, the whole board at worst. On the other hand, it might be cheaper to replace a chip than to upgrade OS... :-( -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
karsh@trifolium.esd.sgi.com (Bruce Karsh) (09/19/90)
In article <AGLEW.90Sep18125247@dwarfs.crhc.uiuc.edu> aglew@crhc.uiuc.edu (Andy Glew) writes: >On the other hand, it might be cheaper to replace a chip than to upgrade OS... >:-( What's the smiley for? It really is far easier and faster to replace a socketed chip than to install a new OS release on a UNIX system. A long time ago, it probably was true that software problems were not very expensive to correct after shipment. But now, it's a significant expense. But we still design computer systems on the assumption that there'll be a lot of new OS releases. In any other industry, they wouldn't be called "releases". They'd be "recalls". Bruce Karsh karsh@sgi.com
aglew@crhc.uiuc.edu (Andy Glew) (09/19/90)
>>On the other hand, it might be cheaper to replace a chip than to upgrade OS... >>:-( > >What's the smiley for? It really is far easier and faster to replace a >socketed chip than to install a new OS release on a UNIX system. Wasn't a smiley. Was a frowny. Now it's a frowny with a wrinkled forehead. This is a smiley: :-) >A long time ago, it probably was true that software problems were not very >expensive to correct after shipment. But now, it's a significant expense. >But we still design computer systems on the assumption that there'll be a >lot of new OS releases. Still, an OS fix can be cheaper than an engineering change to all existing boards of a system. (I've been there). >In any other industry, they wouldn't be called "releases". They'd be >"recalls". Bug fixes are comparable to recalls, yes. But what about enhancements? Like providing NFS on a system that formerly did not have it? -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
rwa@cs.athabascau.ca (Ross Alexander) (09/19/90)
karsh@trifolium.esd.sgi.com (Bruce Karsh) writes: > [...] It really is far easier and faster to replace a >socketed chip than to install a new OS release on a UNIX system. If you have to install a *whole release* to fix a bug in the trap handlers, I suggest you find another vendor. The kind of fix needed should fit on a floppy, and retrofit with one kernel rebuild and a reboot - perhaps 5 minutes work, and you can do it on the phone. Try replacing a chip over the phone some time :-) >In any other industry, they wouldn't be called "releases". They'd be >"recalls". Yeah, uh-huh, that's why Detroit has been releasing new models yearly since the epoch - they're all "recalls" on the Model T. Get a grip. -- -- Ross Alexander rwa@cs.athabascau.ca (403) 675 6311 ve6pdq