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-Thread: 103376,a9bbfb8cd49f1a51 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news.maxwell.syr.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Isn't this in favour of Ada?? Date: 19 Jul 2005 14:08:01 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <42d64dde$0$64794$edfadb0f@dread12.news.tele.dk> <8764vcdv2f.fsf@deneb.enyo.de> <__NCe.5411$oZ.1564@newsread2.news.atl.earthlink.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1121796481 16548 192.74.137.71 (19 Jul 2005 18:08:01 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 19 Jul 2005 18:08:01 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:3680 Date: 2005-07-19T14:08:01-04:00 List-Id: Marin David Condic writes: > Well, if I thought about it long enough, I could probably figure out > some way of disconnecting the interrupt from the code it has to trigger > using only existing Ada mechanisms. What I fear is that it would > introduce either too much inefficiency or not provide for > uninterruptability that may be needed by an ISR. I suppose it wouldn't > hurt too much if you actually shielded the ISR beneath some hardware > abstraction layer & kept it small, providing most of the "Real" work has > to happen above it. (Let it grab data and propogate a message of some > sort?) But then you're really not making a provision to run all of the > software for an embedded system on some workstation platform in an > off-line way. > > It would be better with a language mechanism, but I don't know if it is > either too complicated or of too narrow an interest to be worth a > language update. The problem you're talking about is "How to deal with cases where you need to write different code for different platforms." If the language is well designed, and the compilers aren't too buggy, this will happen fairly rarely. Interrupt handling is inherently platform specific, so this is one case where you'll need platform-specific code. The usual solutions are to use a preprocessor of some sort, or to write different versions of the same source file, and have the build process select among them. So I think no interrupt-specific language mechanism is warranted here. I agree with you that it would be nice to have a way to trigger an interrupt under program control. - Bob