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=0.5 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c78177ec2e61f4ac X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-93" Subject: Re: ada and robots Date: 1997/06/05 Message-ID: <97060510114032@psavax.pwfl.com> X-Deja-AN: 246335806 Sender: Ada programming language Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU X-Vms-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" Newsgroups: comp.lang.ada X-Vms-Cc: CONDIC Date: 1997-06-05T00:00:00+00:00 List-Id: Joe Gwinn writes: >In practice, C was much more successful than Ada83 at riding metal. >Experience with Ada83 shows that it is very bad at direct control of >hardware, especially I/O hardware, and simply does not handle shared >memory correctly. Ada95 is claimed to be better, but I don't have any >direct experience with it. Actually, not many people do just yet. I >suspect that most people are using C (perhaps called from Ada) for direct >control of I/O hardware and the like. > Maybe with some of the early generation compilers, but we've been "riding the metal" for years here in Ada and never had any trouble getting direct control over the hardware. Oh sure, once in a while you've got to dip into assembler to get at some real hardware specific feature, but that's true of *any* language and at least Ada specifies a way you can get at machine instructions without leaving the compiler. Not sure what the problem is you refer to with shared memory, but lots of embedded applications never use any shared memory. (Between processors? DMA devices? Shared between tasks?) If you mean shared between tasks, then Ada95 certainly did improve things with protected types, but I as yet have no practical real-time experience using protected types to point to as proof that it works well. I don't know why it wouldn't. But then, as I recall from my C programming days, C had neither any concept of tasks nor of shared memory between tasks, which left you "rolling your own" if you were multi-threading & sharing memory. If you had to "roll your own" in C, why would Ada be fundamentally any worse? >Most "Ada systems" I have seen built recently are actually mixed-language >systems, being a mix of C, C++, and Ada, with the Ada being in the >minority (maybe 25%), if one counts all the purchased COTS code in the >system. Typically, the operating system, middleware, and GUI stuff are >all in C, and the application code is mostly in Ada (with C bindings, and >no Ada runtime). > This might be true of someone developing under Motif or WindowsNT where you have a huge body of code someone else wrote in C that you're utilizing. But as I recall, the original post was about embedded microcontrollers for robotics and here there is no OS except what you build for yourself. (also very little GUI :-) Most of the Ada work I've done for either embedded systems or apps running under an OS have been 99% Ada and 1% other stuff. I may not be "typical" but my experience is that people usually pick a language for their app and build from there. The exception being if you've inherited some body of software you're trying to glue together with other stuff. >I would also comment that DoD's recent recinding of the Ada Mandate will >likely cause the Ada compiler and tools market to shrink to perhaps as >little as one tenth of its prior size, and that significant added >investment in Ada compilers and tools is therefore unlikely, at least >until the size of the remaining market becomes clear. A significant >shrink is widely expected because the many DoD customers who chose Ada >because of the mandate will now immediately vanish, and DoD's big push >towards COTS is in effect a push to C/C++. The Ada market used to be at >most one tenth the size of the C market, and things took forever to get to >the Ada world. Now, it will be one hundredth. So, if something Ada is >not in hand today, don't wait. It could be a long time coming. > Mandate? We don' have no Mandate! We don' need no steenkin' Mandate!!! :-) I think this is a sort of self fulfilling prophecy. If Ada is technically better, it ought to get fair consideration. (I believe it is.) The availability of high quality compilers at reasonable cost for a large number of platforms tends to limit any business or practical objections to its use. The only case I can see for using C in a given app (especially embedded!) is that you can't find an adequate Ada environment for the target. I believe that if we go out and "Just Do It!" instead of having C++ envy, Ada can end up widely successful. Remember that C basically sat on the shelf for *years* as a niche language while people built stuff out of Fortran, Cobol, assembler, etc. It was only recently in its history that it gained any widespread popularity. 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 =============================================================================== "Having an open mind is nothing. The object of opening the mind, as of opening the mouth, is to shut it again on something solid." -- G.K. Chesterton ===============================================================================