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: 8 Apr 93 23:07:53 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!til
de.csc.ti.com!mksol!strohm@ucbvax.Berkeley.EDU  (john r strohm)
Subject: Re: Interrupt Handlers with Alsys Ada
Message-ID: <1993Apr8.230753.21572@mksol.dseg.ti.com>
List-Id: <comp.lang.ada>

In article <1993Apr8.183659.29253@nosc.mil> sampson@cod.nosc.mil (Charles H. Sa
mpson) writes:
>     We are having difficulty in handling interrupts using Alsys Ada.  We
>are losing certain interrupts that require immediate servicing and that
>occur very close together, approximately 7 microseconds apart.
>
>     Our platform is a 33 MHz 386, executing in real mode.  We are compil-
>ing with the Alsys 286 compiler.  For various reasons involving special
>boards and COTS software, we cannot use an Alsys 386 compiler.  The board
>does not have any on-board buffering.

You have a real problem.  7 usec is 231 clock cycles on a 33 MHz processor.
That is about 60 instructions on a 386.  I doubt very much that you can get
in and out of an interrupt handler in Ada in 60 instructions and still do
anything useful.

My suggestion would be to take advantage of your assembly language excuse,
the one in your contract that says you can do some small amount of really
time-critical stuff in assembly, and do the interrupt handler there.  At
the same time, you get to wire the handler to check for the second interrupt
before going away, and do it all in one pass.

While you are at it: have your program manager shoot the system engineer
who signed off on the design that required two interrupts 7 usec apart.
Preferably in front of the entire project team, with the company system
engineering community watching and learning.