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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d1b37af34f7d1666 X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: Connecting To Interrupts Using Protected Procedures Date: 1999/02/18 Message-ID: <36CC3CA5.F497700A@pwfl.com>#1/1 X-Deja-AN: 445731071 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <36CB42FA.FDD195CF@pwfl.com> <7ag0p8$ae3$1@nnrp1.dejanews.com> Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada Date: 1999-02-18T00:00:00+00:00 List-Id: robert_dewar@my-dejanews.com wrote: > > Please, obsolescent, not obsolete. The rules in Annex J > are just as normative as anything else in the RM. They > simply represent the design team's opinion of features > they would have preferred not to support, if they had > had a choice. Hair splitting. The annex says that an implementation *may* provide the feature, which by my understanding of "may" means they may equally well *not* implement it. Granted, we usually get from real-time compiler vendors mechanisms that are necessary for doing the job, but its nice to know what sort of things you can count on. > > I think the likelyhood of ANY of the annex J features ever > being removed fr om the language is zero. Why on earth > cause > significant back compatibility problems for no good reason? Probably a good way to bet, but again, considering that the mechanism is an optional item, I would imagine that over time, compiler writers will discontinue implementing/supporting it. (Unless guys like me are willing to shell out the big bucks to keep the feature in ;-) > > In this particular case, I actually prefer the Ada 83 style > of interrupts. I think it is a much cleaner interface from > a conceptual point of view, and it allows the program > counter to be used to encode the state of the interrupt > handler process. > I prefer it because it is what I know. It has worked well in the past and I'd agree that it is conceptually clean. However, there are some obvious inefficiencies and problems in making a task entry an interrupt handler if the task has to support the full range of features that "normal" tasks can do. This is why the ARM restricts protected procedures used as interrupt handlers from doing various things like making entry calls. When we want to handle an interrupt, we just want to context-switch and go - not run through the whole scheduler. :-) > As far as hardware goes, machine interrupt structure exists > that reflects both models. All ia32 (x86) machines for > example support a hardware model of interrupts essentially > identical to the J.7.1 method. > I'd bet that for a while at least, we will get support for entry interrupt handlers from the real-time compiler vendors. I'd still like to experiment with the alternatives to find out how fast they work and what advantages/pitfalls there may be. The world turns and we are all forced to learn new things or become an impediment to the business we are in. MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 Ph: 561.796.8997 Fx: 561.796.4669 ***To reply, remove "bogon" from the domain name.*** "Crime does not pay ... as well as politics." -- A. E. Newman