From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 23 Feb 93 12:42:05 GMT
From: destroyer!cs.ubc.ca!utcsri!newsflash.concordia.ca!nstn.ns.ca!jmacleod@han
dies.ucar.edu  (James Mac Leod)
Subject: Re: Interrupts
Message-ID: <jmacleod.79@fox.nstn.ns.ca>
List-Id: <comp.lang.ada>

In article <1993Feb17.161508.30722@iitmax.iit.edu> LEDUC@chico.acc.iit.edu (USE
RS) writes:
>Hi everyone,

>I'm working on an ada application requiring the use of interrupts.
>I understand you can use tasks to trap interrupts, but haven't
>tested it.

>task service is
>  entry ISR;
>  for ISR use at 16#xxx#;
>end service;

>My question is: instead of using the overhead of tasks, is it
>possible to tie the interrupt directly to a procedure?

>procedure ISR is
>end ISR;
>for ISR use at 16#xxx#;

>Any advice or comments is appreciated. Thanks in advance.

>Duc Le
>email:
>led@sunfs1.dsd.northrop.com

I don't think the procedure would work.  All task gets activated when the 
mainline program gets activated.  Therefore it is actually waiting for 
something to happen at 16#xxx#.  A procedure is only active during its 
lifecycle.  Once the procedure has completed it needs some other procedure 
to activate it and cannot be activated beyond a procedural call.
Micronav International Inc
P.O.Box 1523 / 104 Marine Drive
Sydport Industrial Park,
Sydney, N.S. Canada B1P 6R7
Tel: 902-564-8833      Fax: 902-564-8764