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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a9bbfb8cd49f1a51 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 27 Oct 2005 02:20:12 -0500 Date: Thu, 27 Oct 2005 03:20:26 -0400 From: "Robert I. Eachus" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Isn't this in favour of Ada?? References: <42d64dde$0$64794$edfadb0f@dread12.news.tele.dk> <8764vcdv2f.fsf@deneb.enyo.de> <__NCe.5411$oZ.1564@newsread2.news.atl.earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.79.61 X-Trace: sv3-k7AOlF49JNxll1Byy8TbPdZ8rbtAmlTVl6DrLRibSnF8Zmw9uO5nyJMkYvLykkEzVuGXGdvehd/1RP4!xiF+lXm3L07WPy4zoD+4mnZ7yDqGfK6Q2l9eVMzmbXvYsol/n8W2ffOMQvf+pEV8dBVS3iqFBYys!Ev0SOI30yCgX X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:5982 Date: 2005-10-27T03:20:26-04:00 List-Id: 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