Re: Connecting To Interrupts Using Protected Procedures

[Marin David Condic <condicma@bogon.pwfl.com>]

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