Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!oliveb!amiga!cbmvax!mks From: mks@cbmvax.commodore.com (Michael Sinz - CATS) Newsgroups: comp.sys.amiga.tech Subject: Re: Mutual Exclude Gadgets Keywords: Gadgets Message-ID: <9166@cbmvax.commodore.com> Date: 29 Dec 89 14:13:00 GMT References: <947@lpami.wimsey.bc.ca> Reply-To: mks@cbmvax.commodore.com (Michael Sinz - CATS) Organization: Commodore, West Chester, PA Lines: 131 In article <947@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <9147@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes: [stuff deleted...] >> >>And MARKV@kuhub.cc.ukans.edu (MARK GOODERUM - UNIV. OF KANSAS ACS - MARKV@UKANVAX) >>writes: >> >>>Although you are free to use the field on your own to track things manually >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>I have no idea if this would break in the future if this field did begin to >>>get used. >> >>>Mark Gooderum Only... \ Merry Christmas !!! >> >>WRONG! Under no circumstances should you help yourself to a field that >>the system reserves for possible future use. If we were to implement >>mutual exclusion using this field, yet you were using the field for >>your own implementation, how well do you think the two would co-exist? >> >>Not very well at all. > >Whoa! That field is specified, in the latest includes I have, as being the >proper place to specify gadget mutual exclude. It is most definitely NOT >specified as being reserved, nor are there any warnings against using it as a >gadget mutual exclude field. While I fully realize that gadget mutual exclude >does not work in the current release, that is completely beside the point. > >>The rule is simple: Make sure all unused or reserved fields are properly >>initialized (normally to all zeros). > >Yes, the rule _is_ simple, but that field is NOT specified as unused or >reserved. For the rule to work, it must work both ways. You cannot reasonably >expect to leave fields lying around that are not marked as untouchable and just >sort of hope that nobody will use them. Worse, you cannot reasonably specify a >field as being for a particular purpose and hope to defend yourself when >someone uses it for that purpose. Ahh, but you must understand that the field is for SYSTEM use for that purpose. Lets say you do it via a pointer to a special field that you invent. How will the system, once (if) mutual exclude is implemented, know what to do with that field? Is it a pointer, a magic value, junk? This is a *SYSTEM* field and that in itself says that if you don't use the system function (and, right now there is none) you *MUST* respect the fact that the field is unavailable to you. > >>You have plenty of other places to store your own data. We generally don't. >> >>In summary, we reserve the right to use the MutualExclude field of gadgets >>for anything we please, which may not even be Mutual Exclusion. Correctly >>written programs leave these fields NULL. We can't guarantee compatibility >>of incorrectly written programs with future revisions of the Amiga hardware >>and software. > >Do you reserve the right to make GRELBOTTOM suddenly mean GRELRIGHT, or to >change the call to OpenLibrary() to DoIO()? Correctly written operating >systems do what the documentation says they do. It is an unfortunate fact of >life that bugs can happen. The proper thing to do in the case of this >particular bug is to either implement this field for its originally intended >purpose, leave it alone and let the authors use it for their own mutual exclude >routines, or to document it as being reserved, and wait a reasonable length of >time (a few releases perhaps), before using it for something else. No, we don't change things that are defined to work. Mutual Exclude field could be seen as a reserved field for future work. That is, we may, at one point, have hoped to add mutual exclude via that field but have now noticed that that would not be the best way to handle that so we change it so that the field is something more important. (Maybe even mutual exclude) But, since there is no current mutual exclude using that field, there is no way you can know what type of value needs to be in that field. In that way, the field is just an empty that you need to keep that way until you know what type of values will do things. This is much like the bits in the gadget flags. You don't set bets that are not defined yet. It may not change the way it works now, but when that bit gets used, what will you do then? What will the gadget do? > >If CBM decides to use this field for something other than gadget mutual >exclude, you can expect to have to defend your actions against a flood of >protest, and to my mind, your position will be indefensible. > >>There is a fairly long history of such violations (using MOVESR instead >>of GetCC(), not putting image data into chip memory, etc.). Please learn >>from these kinds of mistakes instead of attempting to create new ones >>or worse, encourage them. > >These are entirely different matters, and not even close to being analogous. > >All through the includes, one can find reserved and private fields. ROM >Stompers and Structure Twiddlers have been duly warned about the consequences >of messing with them. 'Proper Programmers' do not mess with them, but they >might be using a field DEFINED BY CBM to do what they see as perfectly ^^^^^^^^^^^^^^ >legitimate operations, fully within the letter and spirit of the documented >guidelines. Again, we have not yet defined HOW, so you can not define it youself unless you really wish to BREAK when we do define it. If the definition comes out be a "Pointer to the Mutual Exclude function that gets passed, in D0 the gadget ID and A0 the gadget address" and you used it as a pointer to a MX data array or a bit field, POOF, your program goes and executes random data at stange addresses. YOU blow up, and it would have been YOUR fault. > >This is not a flame... yet. It is a vehement plea for sanity. There are enough >programs out there already that purposely or inadvertently violate the rules. >The last thing we need is for CBM to pull the rug out from under us by changing >the rules in mid-stream. Please reconsider your position on this matter. > >> Peter Cherna, Software Engineer, Commodore-Amiga, Inc. >> {uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com >>My opinions do not necessarily represent the opinions of my employer. > >-larry > >-- >" All I ask of my body is that it carry around my head." > - Thomas Alva Edison - >+-----------------------------------------------------------------------+ >| // Larry Phillips | >| \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | >| COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | >+-----------------------------------------------------------------------+ /----------------------------------------------------------------------\ | /// Michael Sinz -- CATS/Amiga Software Engineer | | /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | | /// | |\\\/// When people are free to do as they please, | | \XX/ they usually imitate each other. | \----------------------------------------------------------------------/