comp.lang.ada
 help / color / mirror / Atom feed
* Availability of compiler targets C vs Ada
@ 1992-04-21 20:19 Scott Carter
  0 siblings, 0 replies; only message in thread
From: Scott Carter @ 1992-04-21 20:19 UTC (permalink / raw)


<Sorry about the lack of a proper reference, weird rn error with 'F'>

In article <lost by rn bug> Robert I. Eachus writes:

<speaking of code generated from a higher level language tool - 
question of whether it would aid the maintainability of the *system*
to have to tool produce Ada rather than C [assuming that it is of
approximately equal difficulty to design the tool to produce either]>

>   It wasn't a "magical effect" but a quite real issue in maintaining
>systems with long lifetimes.  Parts for 10 or 20 year old computers
>are just not available, and the easiest way to maintain weapon systems
>with embedded computers is to upgrade the computer hardware.  If you
>have a tool which generates code for a specific variant of C, you may
>get lucky, but then again you may not.  It is MUCH more likely that
>Ada code generated by such a tool will run on the latest RISC
>processor than say C originally targeted to a PDP-11.

<I have a sneaking suspicion that this may be a FA,Q [Frequent Argument,
Quixotic], in which case everyone feel free to let it die here>

It is even more likely that there won't be *any* non-beta Ada compiler
for the first (N appears to be ~2-3) years of the "latest RISC"'s
product cycle.  [Processors which aim to derive a substantial fraction
of their revenue from the Mil market, e.g. the i960, may differ.  I've
only used Ada on the 960, so I couldn't comment on the relative
utility of C and Ada compilers for that machine].  There are also going to 
be rather more people banging on the C compiler in the early years than
banging on the Ada compiler if it does exist.

Ob data point - we have ported a few *medium* sized (10K-50K SLOC, typically)
applications (RTL processor models) which for ugly reasons have to be 
simulataneously implemented and maintained in both languages (with all
sorts of subtle variations to prevent using common designs, natch).
They run on VAXen and have recently been ported to the MIPS.  Yes, far
more lines of code had to be changed in the C versions than the Ada.
However, the total man-hours for the port of the Ada was about 3X that
of the C - the only C problems were is grumble damn inconsistent runtime
semantics and incomplete ANSI compliance, but for the Ada we had to
track down code gen bugs that should never have passed beta, but since
ACVC didn't catch it, that was that. [the C compiler had code gen bugs
at high optimization, but none that we saw at low opt.  The fact that
to get UNIX to run MIPS *had* to correctly compile beelyuns and beelyuns
of lines may have had some bearing]

The moral, I *think*, is that any evaluation of the relative port-robustness
of software systems in the two languages must account for the oft-lamented
differences in usage numbers, not some theoretical ideal.

BTW, for embedded systems I would still use Ada in most cases, even if I
didn't have to, and we sometimes use Ada for commercial applications
[overcoming some customer resistance in the process].  But, if I ever
thought I'd have to run on the most recent hardware generation of anything
(except 1750s) it would be C no questions.
--

>					Robert I. Eachus

>with STANDARD_DISCLAIMER;
>use  STANDARD_DISCLAIMER;
>function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Scott Carter - McDonnell Douglas Electronic Systems Company
carter%csvax.decnet@mdcgwy.mdc.com (preferred and faster) - or -
carters@ajpo.sei.cmu.edu		 (714)-566-5741
The opinions expressed herein are solely those of the author, and are not
necessarily those of McDonnell Douglas.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~1992-04-21 20:19 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1992-04-21 20:19 Availability of compiler targets C vs Ada Scott Carter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox