Re: Not intended for use in medical,

["Marin David Condic, 561.796.8997, M/S 731-93" <condicma@PWFL.COM>]

Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
>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.
>
    Please notice that I *was* speaking of tasking in the past tense.
    I know that lots of compilers have become smart enough to find
    things you aren't using and remove them - tasking being one of
    those things that a lot of implementations at least give you some
    link time or system configuration options for getting rid of. But
    yes indeed I have seen and still use implementations of Ada(83)
    where kernel support for tasking comes along for the ride even if
    you don't want it.

    An aside: Are there GNAT ports readily available that are targeted
    to "bare machines?" (And I ask out of ignorance - no slight
    intended.) The one's I've seen on the web all ride on top
    of some operating sysytem. If there are readily available bare
    machine ports, I'm always willing to evaluate them against project
    demands.
>
>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.
>
    My point was that for some really small target machines, there
    *are* no Ada implementations. This may be specifically because
    people take a look at the architecture & decide that they
    couldn't easily get tasking into the machine (or other features -
    let's not single out tasking). I've seen microcontrollers which
    have a slick little processor that can do lots of useful stuff and
    for which you get a "tiny C" compiler (no floating point, real
    bare bones, yet useful) and PC programming environment that will
    download to the card via a UART. And I'd have to conclude that at
    least one reason Ada may not be available for it is because there's no
    such thing as "tiny Ada" with no floating point, restricted
    features, etc that make it easy to target (some subset of) Ada to
    some of these smaller machines. (Why do they use C subsets?)

    Let's face it: Ada doesn't get used in many applications simply
    because it isn't there - not because someone has an irrational
    fear of Ada. (Adaphobia?) If I need a cheap, little
    microcontroller in limited quantities for a small job, I'm not
    going to pay someone to make an Ada port for it or try to port it
    myself or spend hugh amounts of time cobbling together a
    programming system from bits & pieces even if a port does exist.
    Not if I can buy a prototype card, a C/C-subset compiler &
    programming environment all in one swell foop and be off
    programming the next day.
>
>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.
>
    I'm not picking on Ada or GNAT or telling anyone how to run their
    business. What I'm saying is that I can pretty easily find
    microcontroller kits that include a nice, small SBC with some
    analog & discrete connectors, a programming environment &
    everything you need for under $200. The only thing is, they
    typically have a C or C subset compiler and I'd prefer Ada (or some
    subset thereof) and as far as I can see, that doesn't exist. The
    kits are selling to *somebody* so there must be a market. If the
    market exists, it's a shame its not also being addressed by Ada.
    If it's not being addressed by Ada, maybe (maybe!) it might have
    something to do with difficulty of porting all the features of Ada
    into such machines. (Why do they provide *subsets* of C?) (Also,
    please read "difficult" to mean "not theoretically impossible -
    just time consuming, costly, inelegant or all of the above.)
>
><<  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.
>
    Well, maybe it's nonsense. Maybe I don't know what I'm talking
    about. Maybe I'm an idiot. Maybe a lot of things. But it sure
    seems that *something* is keeping Ada out of playing in the
    inexpensive, small microcontroller field. My experiences with most
    of the embedded Ada compilers I've played around with seems to be
    that they only target machines above a certain size and that you
    can't find a nice controller kit like some of the things I've seen
    at Z-World (http://www.zworld.com/) and others that come with an
    Ada programming environment. (Or for which yuou can get one.)

    Either folks have determined that it's not an easy, cheap port of
    a compiler to such an environment or the market has been conceded
    to C/C-subsets or nobody has thought to produce their own little
    microcontroller card with an Ada programming environment targeted
    to it as a means of selling compilers. (And selling controller
    hardware as well - which is going to be more lucrative than Ada
    compilers & will subsidize the compiler development part of the
    business.)

    As I said earlier, I think the problem with tasking was a _past
    tense_ thing, but it may still be an issue with some compilers.
    Depending on how the compiler is structured it may be difficult or
    impossible to squeeze the tasking, etc. into the limited space &
    processor throughput available on some of the smaller machines.
    And certainly because earlier on (past tense, again) Ada with
    tasking etc. was hard to fit into smaller boxes and C was easier
    to get in there, C won out & established itself as the dominant
    player. (Is it just because the market is conceded that Ada
    doesn't play there?)

    I like Ada and prefer to use Ada wherever possible. But sometimes
    it's just not there and I get to wondering if possibly Ada, in an
    attempt to cover all possible bases, tends to forget that there's
    us real-time, embedded guys out there who were the original
    customers. Maybe we'd settle for a quickly implemented,
    inexpensive, efficient, widely available *subset* of the language
    for some of these smaller jobs rather than have nothing at all.
    When someone starts proposing "Gee, it would be cool to have
    feature X in Ada..." I've got to reply with "If it keeps me from
    getting a compiler because it is too big, too slow, too difficult
    to implement on my machines, too....whatever, then I'd rather do
    without." An *available* compiler is infinitely superior to the
    full featured compiler that never makes it off the drawing
    board.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
West Palm Beach, FL                             Internet:   CONDICMA@PWFL.COM
===============================================================================
    "I saw a bank that said "24 Hour Banking", but I don't have that
    much time."

        --  Steven Wright
===============================================================================