Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!ucsd!rutgers!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@dwarfs.crhc.uiuc.edu (Andy Glew) Newsgroups: comp.arch Subject: Re: Architectural quirks Message-ID: Date: 22 Aug 90 16:55:14 GMT References: <12459@encore.Encore.COM> <3300161@m.cs.uiuc.edu> <1990Aug17.155925.1588@mozart.amd.com> <1990Aug21.163009.26625@mozart.amd.com> <1296.26d2c053@waikato.ac.nz> Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois, Computer Systems Group Lines: 22 In-Reply-To: ccc_ldo@waikato.ac.nz's message of 22 Aug 90 05:26:43 GMT >In the DOS world, one example that comes to mind is one of the >problems that came to light as the 80486 chip was making its >first few public appearances: it turned out that AutoCAD was >neglecting to clear a "reserved" bit before loading a new value >into an 80386 status register, and the '486 didn't like this >at all. So they changed the relevant '486 instruction to ignore >the setting of that bit. I guess this isn't a case of "counting on >quirks" so much as neglecting to check certain low-level sources >of possible future incompatibility *very* thoroughly. The end >result being that the hardware vendor has to work around the software >vendor's mistakes... All "reserved bits" should be implemented "Read as zero, trap on nonzero write". Or, at least, "Read as zero, software should write old value or zero". But nobody gets it right. The FUTUREBUS+ draft didn't have the reserved bit usage policy defined (for its CSRs). Hopefully they will in the next draft. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]