From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a5449b9a03812b50 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-07-30 13:37:26 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!arclight.uoregon.edu!news.tufts.edu!uunet!dca.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: GNAT documentation question Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Tue, 30 Jul 2002 20:36:47 GMT References: <3D406C6B.9DE867E4@boeing.com> <5ee5b646.0207281028.607ea804@posting.google.com> <3D458108.A5D88B80@raytheon.com> <5ee5b646.0207292018.663f3d95@posting.google.com> NNTP-Posting-Host: shell01.theworld.com Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.7/Emacs 20.7 Xref: archiver1.google.com comp.lang.ada:27497 Date: 2002-07-30T20:36:47+00:00 List-Id: Simon Wright writes: > dewar@gnat.com (Robert Dewar) writes: > > > That's straightforward. If you want Annex D dispatching rules > > (that's the semantically significant issue here), then you need to > > use the pragmas documented in Annex D to have this effect. I would > > be surprised if there was anything else to this issue. In other > > words, real time priorities are not an end here, they are simply a > > means to an end, the end being the proper implementation of annex D > > features. > > Our point of view was: > > * we have a mixed language, multi-process program > > * we need parts of it to run with priorities higher than those of > normal processes > > * we can use priocntl to get this to happen (this was Solaris) > > * wow! if we run as root, GNAT does what we want! (this was 3.11, I > think) > > so the question of whether we had Annex D dispatching rules never > entered our heads. This is a good example of why I think Annex M is useless. This programmer wants to know how to fiddle with *process* priorities, which have nothing to do with what's in the RM, and in fact Annex M doesn't give any pressure toward answering it. How could it? The RM knows nothing of processes. Nonetheless, good documentation would explain how Ada priorities affect process priorities and the like. You can't legislate "good documentation", any more than "morality". I think compiler documentation should be driven by "what do we think the programmer wants to know about" rather than by "the RM says we have to document certain things". > We were delighted to have found a solution, so never raised the > question with ACT. Had we still been supported on that contract when > we discovered the changed behaviour, we would of course have asked! When I wrote the docs for AdaMagic for the SHARC chip, I *first* wrote what I thought was useful: sections about "how to debug" and "how to handle interrupts", etc, with examples and whatnot. This was somewhat driven by my own knowledge, and somewhat by questions from customers. Then I went through Annex M, and if it said I must document something-or-other about interrupts, I referred the reader to the interrupt section, rather than inserting some out-of-context factoid about interrupts in Annex M. Our documentation of Annex M ensures that we obey the rules (although as Robert Dewar pointed out, this can't be formally verified), but it not particularly useful to users. - Bob