hawk@hpavla.HP.COM (Dave Hawk) (01/05/90)
I am interested in learning what the current "state of the art" is
for feasible interrupt response rates for Ada based systems on 68xxx
and 80x86 microprocessors. I am interrested in Ada systems which run
directly on the hardware itself with an Ada vendor's run time (no
intermediate OS such as Unix or OS/2). If you have knowledge of an
Ada system using interrupts on one of these microprocessors could you
please post a brief response to this basenote listing:
1.) Approximate interrupt rate,
2.) Processor and clock speed,
3.) Name of compiler vendor,
4.) A comment on margin (i.e. are you near the limits of
what the system can do, or do you still have
processor time to burn?)
Thanks,
David Hawk
Hewlett-Packard Co.
Avondale, Pa.griest@ajpo.sei.cmu.edu (Tom Griest) (01/09/90)
Regarding David Hawks posting on Interrupt Rates for Ada programs: >> 1.) Approximate interrupt rate, The system I am currently working on has several different interrupts, the highest rate is 500Hz. The implementation uses "fast" interrupt entries in that the compiler essentially generates code to save/restore registers, places this around your Ada "accept" statement, and vectors directly to this code. Thus, the interrupt rate is the same as for assembly language, and incurs only the overhead of processor interrupt handling and register preservation. In our case this is about 10 usec. round-trip. Latency is primarily determined by how long interrupts are disabled during runtime calls and are typically held very short (under 20usec) but I don't have a number for the worst case possibility. The maximum interrupt rate is therefore limited by what is done during the interrupt. If an entry call is made during the interrupt, it is treated in a special way and is effectively deferred until after the interrupt is completed. Such a call is believed to have low overhead (we have not measured it recently, but we recall numbers well under 100usec). Our application must process interrupts very frequently in order to prevent the loss of data. Less frequently it wakes up another task to perform extended processing on the data received. >> 2.) Processor and clock speed, We are using a 16MHz 80386, currently running in "Real-Mode". Accesses within 4KB memory pages incur no wait states, switching pages forces a wait state. >> 3.) Name of compiler vendor, DDC-I Inc. >> 4.) A comment on margin (i.e. are you near the limits of >> what the system can do, or do you still have >> processor time to burn?) Our application is very close to margin, and to a limited extent is designed to degrade gracefully as it exceeds the available CPU cycles. (The processing load is highly dependent on the number of targets and rockets that require tracking, what flight phase the rockets are in, and even computations that vary depending on parameters like square roots performed in software.) Our system has the ability to become distributed to obtain additional processing resources, but this characteristic has little or no impact on the way in which interrupts are processed. However it is used to offload rocket trajectory calculations, graphics processing, and various other operations and therefore can provide isolation from the activities with high interrupt rates. The system is strictly real-time and when rocket calculation deadlines are missed, it degrades very rapidly. In particular, the processor closes the servo loop between the rocket attitude data and the trajectory planner of the rocket to intercept the target. These equations are based on accelerations computed on presumed fixed intervals between reports. If the intervals become aperiodic, the rocket stability suffers substantially and the hit rate is dramatically reduced. Also, if the update deadlines are missed during the final ingress phase and targets change acceleration then the extrapolated positions will be incorrect resulting in missed targets. Tom Griest LabTek Corporation griest@ajpo.sei.cmu.edu