From: Gary Scott <Gary.L.Scott@lmtas.lmco.com>
Subject: Re: Ada Tasks vs Linux processes
Date: Wed, 04 Apr 2001 12:18:59 -0500
Date: 2001-04-04T12:18:59-05:00 [thread overview]
Message-ID: <3ACB5783.474B0834@lmtas.lmco.com> (raw)
In-Reply-To: E4Iy6.1270$4L4.246512@news1.frmt1.sfba.home.com
A more fundamental issue would be why would hardware be designed that
did not provide a positive status indication that it was "ready" for
further access. Using delays to handle interface issues with slow,
poorly designed hardware has caused a huge number of anomalies in
avionic systems that I've dealt with over the last 20 years. It's really
tiring...
tmoran@acm.org wrote:
>
> > ... by delaying until the next clock tick.
> Note this is a change from Ada 83, where the delay had to be "at
> least" that specified. Suppose there's a piece of hardware that
> needs 500 mics to settle after some operation, before it can next
> be accessed. Given a Duration'small of 10*mics, the unsuspecting
> programmer might write "delay 500*mics;". With a System.Tick of
> 1000 mics, that would delay somewhere between 1 and 2 ms, a safe
> time for the hardware to settle down, when compiled with Ada 83.
> In Ada 95 it need only take a single tick, which might happen
> within a few mics of reaching the "delay" statement and thus long
> before the hardware is ready. Crash and burn.
next prev parent reply other threads:[~2001-04-04 17:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-01 15:27 Ada Tasks vs Linux processes Frank
2001-04-01 22:32 ` David C. Hoos, Sr.
2001-04-02 17:30 ` tmoran
2001-04-02 18:00 ` Robert A Duff
2001-04-02 18:20 ` Ehud Lamm
2001-04-02 22:17 ` Jeffrey Carter
2001-04-04 16:36 ` tmoran
2001-04-04 17:18 ` Gary Scott [this message]
2001-04-04 19:18 ` tmoran
2001-04-02 19:57 ` Frank
2001-04-03 11:28 ` Matthias Kretschmer
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox