Re: Isn't this in favour of Ada??

["Robert I. Eachus" <rieachus@comcast.net>]

Marin David Condic wrote:

> It doesn't seem like a big leap to have some language defined "signal" 
> abstraction that could be either hardware triggered, OS triggered or 
> software triggered so that the protected procedure could do what it is 
> currently doing to connect to an interrupt (connecting to the "signal" 
> abstraction instead), but you could hide the triggering mechanism under 
> a package body somewhere.
> 
> I'm not looking to avoid having to do some code substitution between a 
> target machine and a simulation. What I'm looking for is a mechanism 
> that lets you hide the SOURCE of the interrupt in a package BODY so that 
> the embedded executive developer and the workstation simulation 
> developer can both work from a common specification and all we have to 
> do to get off the target and on to the simulation is substitute one 
> package body. With Ada as it stands, I'm not sure I can do that without 
> some significant gyrations. A language defined "signal" would seem to 
> provide a simple mechanism for doing that.

Hmmm...  If I wanted to do this in a platform independent manner, I'd 
have a package containing an enumeration type that provided the 
interrupt names.  If you prefer, you could have an integer type with 
deferred constants for some common useful names.

Also in the package would be a generic package with two procedures for 
binding and unbinding the interrupt to a task or protected object entry. 
  The choice of generic formals I leave up to you.  I'd go for a formal 
parameterless procedure for the action to be called.  That lets you use 
a procedure in a protected object.  And I would have the package body 
maintain a stack of bindings that resides in the non-generic enclosing 
package.  However, I would have the unbind routine raise an error if it 
is not from the generic instance that did the binding.  Oh, and the 
generic body should use finalization to insure that when the scope in 
which the generic package is instantiated is left, the interrupt is 
unbound if necessary.

At the other end of the spectrum would be an implementation where 
instantiating the generic did the binding, and the unbinding occurs when 
the enclosing scope is left. So the generic takes two 
(generic)parameters an interrupt name or number and the procedure or 
entry to be called.  Not as powerful an abstraction, but easier to use. 
  In practice though, most interrupt bindings will have the same scope 
as the main program...

RIE