From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,267eec8ad557a7d0
X-Google-Attributes: gid103376,public
From: vestal@src.honeywell.com (Steve Vestal)
Subject: Automatic code generation (was ARIANE-5 Failure (DC-X works))
Date: 1996/06/12
Message-ID: <4pn266$p7i@moon.htc.honeywell.com>#1/1
X-Deja-AN: 159907891
references: <834097751.22632.0@assen.demon.co.uk>
 <4pd540$rl2@Starbase.NeoSoft.COM>
organization: Honeywell Technology Center, Honeywell Inc.
newsgroups: comp.lang.ada
Date: 1996-06-12T00:00:00+00:00
List-Id: <comp.lang.ada>


MATRIXx is one of a number of toolsets that allow feed-back control
engineers to specify both control algorithms and models of physical systems
in what some call a domain-specific language (MATLAB, BEACON, ACSL, and our
own ControlH are other examples).  Such languages are used to model plants
(e.g. aircraft) as well as specify control algorithms.  The tools typically
support simulation and mathematical analysis as well as automatic
generation of code.  I think computer scientists would catalog them as data
flow languages, although they have a precise semantics based on dynamical
systems theory (the meaning of a specification is a system of differential
or difference equations, at least until the control engineer starts
throwing in discrete event or procedural constructs :-)

There are several reasons why we think the nature of the code produced by
such tools is a consideration, and we favor generation of well-structured
code where there is good traceability between specification and code (a
principle we try to follow in our tools):

  - Some bugs first manifest themselves at the "object" code level.  For
    example, on several occasions I have been given a specification that
    was debugged in simulation (using C code generation), flipped the
    translator switch to generate Ada code for a real-time target, and
    discovered the algorithm was dividing by zero (something C seems to
    allow and Ada seems to think objectionable).  It is helpful to be able to
    read the generated code and trace bugs found at that level back to the
    originating constructs in the control specification.

  - Safety-critical software requires various certification steps,
    typically including unit testing that achieves full path coverage
    (according to a particular definition of path) on the target hardware.
    It is helpful if the generated code is broken into units as that term is
    used by the software testers, and it is helpful if localized changes in
    the control specification cause only a few units to be re-generated and
    re-unit-tested.

  - There are other kinds of domain-specific languages and generators used
    by other kinds of engineers for other purposes, e.g. generators of
    display management code.  A complex system (such as an avionics system)
    consists of many kinds of functions, only some of which are candidates
    for automatic generation from feed-back control specifications.  In
    general, automatically generated code produced by various tools will
    need to be integrated with each other, with hand-written modules, and
    with modules re-engineered/re-used from previous systems. (Software and
    (computer) systems analysis and integration is a problem area in its
    own right, we have another language and toolset for that task called
    MetaH.)

We generate both Ada and C.  Unconstrained arrays were certainly a
convenience when generating code from a language where matrices are a
fundamental data type.  Discriminant records were also a convenience.

Our web pages contain some more information, although not about Ada
issues specifically:
        http://www.htc.honeywell.com/projects/dssa

Steve Vestal
Mail: Honeywell Technology Center, 3660 Technology Drive, Minneapolis MN 55418 
Phone: (612) 951-7049      Fax: 7438     Email: vestal_steve@htc.honeywell.com