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,d1df6bc3799debed X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Not intended for use in medical, Date: 1997/05/13 Message-ID: #1/1 X-Deja-AN: 241330013 References: <97051217065652@psavax.pwfl.com> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-05-13T00:00:00+00:00 List-Id: 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