davec@nucleus.amd.com (Dave Christie) (08/21/90)
In article <AGLEW.90Aug17125258@lasso.crhc.uiuc.edu> aglew@lasso.crhc.uiuc.edu (Andy Glew) writes: >Hi Dave! Hi Brian! Mind if I jump in? > >>>Taking advantage of architectural quirks isn't automatically evil. >>>You just have to weigh the costs against the benefits. >> >>Unless you know what the architects might come up with in the future >>in the way of architectural extensions, you can't know all the possible >>costs. > >Within a company, "architects" should have long range plans for the >direction of the architecture, and should be able to give software >developers for that architecture an idea of what the costs will be. > Of course, the plans will change, sometimes breaking previously >stated cost goals (but hopefully not breaking previously stated >compatibility rules). > >If you haven't got a rough idea of where you are headed in 5 years' >time (I'd like to say 10 years' time, but most US companies don't >think that far ahead (except maybe IBM)) you aren't architecting, >you're implementing. Fine. I don't imagine anyone in this business is just 'implementing'. And nobody is just 'architecting'. The two are very much interdependent. Of course you have long range plans, but the further out you go the less focused they are, because all the things that drive architectural development (implementation technology and techniques, software directions, customer needs) aren't terribly predictable beyond five years. I assume the architectural quirks that Brian was referring to are the grey areas in any architectural definition covered by such phrases as "undefined operation", "implementation dependent", "reserved", and my personal favorite, "try this and you'll be shot" (never get this one past the publications dept, though...). They might better be called implementation quirks. These grey nooks and crannies exist because their behavior doesn't need to be defined for most people's purposes (except maybe to say they won't compromise any protected mode of operation), and the tighter you tie up an architectural definition, the tighter you tie your hands for future implementations and extensions. So grey areas that don't need to be defined will remain grey in future plans. (And then there's the corners you haven't even covered because in the limited amount of time you have to put together a user's guide you can't think of all the unobvious ways clever software developers will try something.) As for communicating future plans to software developers, if your product is successful at all, you can't possibly review everyone's use of the quirks. Major developers will get access to the architects and future plans under non-disclosure, and if one is really counting on a quirk behaving a certain way they would be given serious consideration, or shown how such a seemingly innocuous little thing could have significant impact on your planned super-duper hyper-scalar biological implementation in sea-moss. (But then, I don't think major developers are prone to counting on quirks.) A lot of smaller developers will generally have to live with the grey areas and assume worst-case potential cost for using a quirk: the cost of doing it all over again without the quirk on the very next implementation of the target architecture. (Which may very well be trivial, but then, you often don't know the true cost of doing something until you've actually done it.) To tie in another couple of threads, use of quirks is an extension of the HLL/assembler portability tradeoffs, and is akin to breaking the timing rules. Sorry to be long-winded, but what the heck, traffic's been light lately. ------------------------------- Dave Christie I don't speak for AMD, and I'm sure they appreciate that.
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/22/90)
In <1990Aug21.163009.26625@mozart.amd.com>, davec@nucleus.amd.com (Dave Christie) says "I don't think major developers are prone to counting on quirks." Ahh, if only things were as simple in the PC world as they appear to be in the mini/workstation world... Probably the classic example is the ongoing battle between Apple and many developers of software for the Macintosh over Adherence to the Rules (as laid down in Inside Mac, the tech notes, the human interface notes and other miscellaneous pieces of documentation) versus the urge to take hardware-specific shortcuts. The most famous offender is Microsoft, and as far as I recall the most stupid thing they ever did (and there were some humdingers) was some scheme in Excel 1.x for determining if a floating-point coprocessor was present: the standard environment query wasn't good enough for them, instead they came up with their own ingenious test that worked with a 68881 but failed with a 68882. 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... PS: regarding "try this and you'll be shot"--read any Apple documentation lately? It's full of statements like this--and worse. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 ..that time of year when the kennels become a melting pot of molting pets...
aglew@dwarfs.crhc.uiuc.edu (Andy Glew) (08/22/90)
>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]
usenet@nlm.nih.gov (usenet news poster) (08/23/90)
Dave Christie says: > "I don't think major developers are prone to counting on quirks." and Lawrence D'Oliveiro replies: > Ahh, if only things were as simple in the PC world as they appear > to be in the mini/workstation world... Sometimes the reliance on quirks seems almost intentional, as for example, the IBM PC ROM-BIOS. The early, slick, products (Lotus123, MS flight sim.) didn't stick to the rules because the code that ran according to the rules was slow. By using undocumented interrupts and system calls the software got speed but the user got stuck for the copyrighted IBM-BIOS. Was someone in marketing smart enough to actually lay this deviousness out ahead of time, or did it just sort of happen? I don't know, but IBM sold alot of PCs while the cloner makers tried to come up with a ROM-BIOS that would support all the undocumented "features". David States
paulsc@orca.WV.Tek.com (Paul Scherf) (08/23/90)
In article <1990Aug22.220851.7933@nlm.nih.gov> usenet@nlm.nih.gov (usenet news poster) writes: > Sometimes the reliance on quirks seems almost intentional, as for > example, the IBM PC ROM-BIOS. The early, slick, products (Lotus123, > MS flight sim.) didn't stick to the rules because the code that ran > according to the rules was slow. By using undocumented interrupts and > system calls the software got speed but the user got stuck for the > copyrighted IBM-BIOS. Was someone in marketing smart enough to actually > lay this deviousness out ahead of time, or did it just sort of happen? I suspect there were once pre-released versions of Lotus123 and MS flight simulator that may have pretty much stuck to the rules. When they saw the performance wasn't as good as they wanted, they looked for ways to speed it up. That is likely to be when the oddities mentioned before may have been added. Another possibility is that the writers of Lotus123 and MS flight simulator didn't realize those things were against "the rules", but I'd like to think of Kapor and Gates as being good enough software design engineers and software project managers, to know when they are breaking "the rules". Paul Scherf, Tektronix, Box 1000, MS 60-850, Wilsonville, OR, USA 97070 paulsc@orca.WV.Tek.com 503-685-2734 ...!tektronix!orca!paulsc