Re: Ada Streams usage (was Escape Sequences in Strings)

[Ted Dennison <dennison@telepath.com>]

In article <3A14108E.CCB398A1@acm.org>,
  Marin David Condic <mcondic.nospam@acm.org> wrote:

> Well, part of my objection to streams is the overhead of the data
> motion and the way it degenerates to a (potentially) large number of
> small procedure calls. (It wouldn't be so bad if the compiler could
> figure out when to generate a really fast block-move instruction
> instead of a bazillion procedure calls. But I suppose there may be

Quite true. There was one instance where we had to replace a 'Write on a
large array to a dispatching call to Ada.Streams.Write. The old way was
causing one 60Hz task to take 20ms to complete (Bzzzzt! Wrong. Thanks
for playing...) Since it was an unstructured array of bytes already, it
wasn't too painful to just change its native type to
Ada.Streams.Stream_Element array that cut it to less than 1 ms.

> Maybe my usage of the word is not entirely accurate. "Hard-real-time"
> usually means that failure to meet deadlines constitutes failure of
> the system. If your processor does a gazillion-instructions-per-second
> and you're only using 1% of your CPU, it can still be a
> "hard-real-time" system.

Well, we admitedly do have a bit of headroom, since we are using a PC as
our target. The last CPU utilization numbers I saw were running at about
%35 (Contractually we have to be under %50). Even if we do cut it close,
the march of technology will wipe out most problems. Now they are
ordering them as PIII's, next year, who knows?

> I suppose I was thinking more along the lines of "difficult" real time
> systems. :-)
Well, I don't know if there is a good word for that, but there probably
ought to be. A lot of embedded real-time work is done on older (slower)
microprocessors due to the cost factor.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.