Re: Not intended for use in medical,

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Marin says

<<  I'm almost with you here - except for one possible problem. If a
    given language feature poses too much runtime overhead to be
    useful *and* requires non-trivial space in its support in the
    runtime kernel (or otherwise causes "other" features to compile
    inefficiently because of dependency on the inefficient feature),
    then you've got a case for why it would be "bad" to include it in
    a realtime language.

    Tasking had (and still has, for some) this same problem. If I've
    got a tiny little microcontroller to do some specific job and I've
    maybe only got 64k of memory to work with and no need for anything
    more complex than a cyclic exec, dragging around the tasking
    support could make it difficult or impossible to use Ada. Try
    finding a nice, small SBC to use as a microcontroller that
    actually has Ada targeted to it - if you find one, let me know.
    I'm still shopping for one that doesn't involve me putting
    together a home-brewed, cobbled-up compiler port that may or may
    not work. (Or is really too big for the job and/or comes with it's
    own realtime version of DOS, etc., etc.) Tasking thus shut Ada out
    of a sizeable segment of the market that is now served almost
    exclusively by C or even C subsets.

    Don't get me wrong - I like the fact that tasking is there and
    have used it effectively in realtime systems. But it would be nice
    to see some (dare I say it?) subset of Ada available that was
    targeted to some of these really small machines.
>>


This seems disconnected from reality. Any reasonable implementation of
Ada 95 loads in tasking runtime stuff only if you are using tasking, or
at the very least (e.g. via pragma Restrictions) has a way of getting
rid of it. For example in *all* GNAT implementations, if you use no
chapter 9 or annex D features, then you do not get any of the tasking
runtime, and the overhead that Marin is worrying about simply does not
exist.

If you want a simple cyclic exec, by all means write one, just as you
would in C. Then you won't be "dragging around the tasking support".
This is definitely NOT a reason for not using Ada.

Sure there is still the problem of finding an Ada for a small machine,
but the idea that tasking makes this harder is a complete red herring.
Whether or not there is a "nice small SBC to use as a microcontroller
that actually has Ada targetted to" has to do with whether or not there
is a commercial demand for such a target. We don't see such a demand,
at least not at the level to justify the work, so there is no GNAT for
such a beast. 

<<  Tasking thus shut Ada out         
    of a sizeable segment of the market that is now served almost              
    exclusively by C or even C subsets.                                        
>>

This statement is nonsense. In almost all Ada implementations, the main bulk
of the tasking support is simply a bunch of Ada runtime routines. If you have
an Ada compiler, then you simply compile these runtime routines, and hook
them to a small executive. If you don't want tasking, you don't bother
to do even this. For example, one group is using GNAT on an i960 with
Vxworks, but they have not bothered to port the tasking, even though it
would be quite easy to do so, because they do not need it.

Robert Dewar
Ada Core Technologies