Re: Ada is almost useless in embedded systems

[ralw@valiant.gmrc.gecm.com (R.A.L Williams)]

In article <4gea0h$ckd@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes:

> ralw@valiant.gmrc.gecm.com (R.A.L Williams) writes:
> >To be honest, the engineer in charge of the development didn't
> >even consider using Ada but, if he had, I would have advised strongly
> >against it because, leaving aside the issues of large projects and
> >portability of representation, Ada (83 at least) is IMO far harder to
> >use than C.
> 
> This statement, coming from someone with such a background, deserves
> a fuller exposition.  I hope R. A. L. Williams will provide one.

The specification for some of the data formats had things like:
- values split across several bit fields, ie.
   a bit of A
   a bit of B
   some more of A
   the rest of B
- bit reversed values
- fixed point numbers with 'weird' resolutions.

OK, so Ada (83 and 95) can handle all these things. 95 far easier than
83 I suspect (modulo types are a tremendous improvement for example).
My attitude to this sort of thing is that you find the right tool for 
the job. I strongly suspect, based on my experience with Ada 83 at
least and having seen the solution in C, that any solution is bound to
be pretty much unreadable because of the nature of the problem. That
said C seems to be the better tool for this particular type of low
level manipulation because it is, basically, a high level assembler
and, as such, has syntax and semantics which maps very directly to the
architecture of the 'typical' CPU. Ada implements a higher level
abstraction which, although useful for writing 'high level'
applications, makes it comparatively clumsy for this sort of low level
code. Essentially what I am saying is that, where this sort of low
level manipulation is required using Ada will tend to obscure the
solution because of its high level abstraction where C, which is
inherently low level, expresses it succinctly.

Of course, the decision must look at the whole problem. In the system
discussed above there was very little else. We do a lot of this sort
of thing - interfaces between existing pieces of kit which are too
complex to implement entirely in hardware - and, franly, C is still
the ideal language. If there had been significant other processing or
control to do we might have looked at Ada or C++ or a mixed language
solution. As it was, these other choices were sub-optimal.
> 
> My personal experience, having used C since 1979, and Ada only for the last
> couple of years, is precisely the opposite.  I consider myself expert in C;
> perhaps that's why I thought it was hard to use.  I may say that it seems
> to be easier to _teach_ Ada than to teach C; you can get a heck of a long
> way without worrying about pointers, and it is so refreshing to be able to
> answer questions of the form "how do I do X" with "well, it's really a topic
> for later, but here's how you do it in Ada" instead of "well, there's no
> language support for that in C in order to keep the compiler simple back in
> the 70's."
> 
That's an interesting point. Ada certainly makes it easy to avoid the 
normal C beginners mistakes. Also, of course, we don't normally let
beginners loose on implementing devious embedded systems so the places
where the issue we're discussing is relevant don't arise.

> (I hope this crashes before the written-in-C operating system crashes again...)
> 
On our network it's the P(ersonal) C(atastrophes) that cause all the
problems. What do Microsoft use?
> -- 
> Election time; but how to get Labour _out_ without letting Liberal _in_?
> Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Bill Williams
-- 
Bill Williams                     |GEC-Marconi does not necessarily
GEC-Marconi Research Centre       |endorse my opinions!

bill.williams@gecm.com
Tel: +44 1245 242016
Fax: +44 1245 478639