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=-0.0 required=3.0 tests=BAYES_20 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 18 Oct 92 19:01:39 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!cs.ucf.edu!c rigler@ucbvax.Berkeley.EDU (James Crigler) Subject: Re: Ada and real-time Message-ID: <1992Oct18.190139.20047@cs.ucf.edu> List-Id: The summary says it all. No one has mapped Ada tasking constructs to _general_purpose_ hardware. As I recall (don't have my LRM handy), the language is required to execute tasks AS IF THEY WERE EXECUTING ON SEPARATE CPU's. This does not map directly on to any general purpose hardware that I know of. I've often wondered why. Any compiler gurus care to enlighten the universe (or are we back to the days of DP-priests in white coats? :-). The Ada compilers with which I've worked closely (Alsys 80286, Tartan C30) have a large run-time penalty imposed by using the language's tasking. In the 2 Alsys-80286 jobs, the overhead was within acceptable limits (the requirement was for soft real time (I bet that raises some heckles :-)); the Tartan C30 (TI 320C30) compiler was unable to mix interrupt handling with tasking under our timing constraints, so we wrote procedural code called from the interrupt handler (the requirement was for hard real time). Jim Crigler ------------------------------------------------------------------------ If the 24th century is so great, how come they don't have a cure for baldness?