Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!lll-winken!sun-barr!newstop!sun!amdcad!mozart.amd.com!nucleus!davec From: davec@nucleus.amd.com (Dave Christie) Newsgroups: comp.arch Subject: Architectural quirks (was: Is handling off-alignment important) Message-ID: <1990Aug21.163009.26625@mozart.amd.com> Date: 21 Aug 90 16:30:09 GMT References: <12459@encore.Encore.COM> <3300161@m.cs.uiuc.edu> <1990Aug17.155925.1588@mozart.amd.com> Sender: usenet@mozart.amd.com (Usenet News) Reply-To: davec@nucleus.amd.com (Dave Christie) Organization: Advanced Micro Devices, Inc., Austin, Texas Lines: 65 In article 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.