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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!rutgers!ucsd!usc!cs.utexas.edu!mailrus!ncar!dinl!schwartz From: schwartz@dinl.uucp (Michael Schwartz) Newsgroups: comp.lang.ada Subject: Re: A farewell to Ada Summary: Longish discussion of Unix/Ada problems/solutions Keywords: Ada, C, Unix Message-ID: <1492@dinl.mmc.UUCP> Date: 17 Nov 89 17:19:33 GMT Article-I.D.: dinl.1492 References: <14033@grebyn.com> Reply-To: schwartz@dinl.UUCP (Michael Schwartz) Organization: Martin Marietta I&CS, Denver CO. List-Id: OK. You win. I have to put in my 2 cents' worth. It's hard, because I agree with many things that everybody has said. Ada has been getting a bum rap. Ada was not designed by committee, it was designed by competition. C, on the other hand, has been judged by its applications. Ada had no substantial applications to benchmark its design against. The software engineering requirements imposed on Ada were for programming in the large. Precisely what Ada has been shown to be good at. Not surprisingly, Ada has not been found perfect for every application area. Where it has failed, Ada-9X proposals have been submitted to change it. C was developed for systems programming. The worth of a compiler was judged by the ability to build a good, modular, maintainable operating system. Where C failed, the language was changed. And changed. And changed. It has surprised no one that C is more responsive to change requests than Ada. Nor is it surprising that inexperienced software engineers write better code in Ada than in C. It has not escaped anyone's attention that there are more inexperienced software engineers than experienced software engineers. Sorry for belaboring the obvious, but let's start somewhere. Now let's talk about Ada and Unix. Areas where Ada and Unix have problems: a) System-dependent features accessed from Ada b) Scheduler conflicts--Ada tasks vs Unix tasks c) Ada image sizes and startup times Of these areas, (c) is the most readily addressed. I have heard a number of Ada 9X proposals amounting to a mechanism to freeze the Ada image after elaboration, but before execution. So much for startup times. I have also heard several vendors tout smarter link-editors which will help resolve image size problems. I also hold hope for shared library implementations; the Ada runtime can be shared among all processes needing it. Area (a) is one that requires Ada vendor support. It is difficult to think of a non-trivial software system without some system-dependent feature. After all, we buy different hardware precisely because of these features. In my mind, a major difference between a good Ada compiler and a marginal one can be found in the support for operating system signals, pragma interfaces, and representation specifications. It is no anathema to me to have an Ada system contain bodies which are Pragma Interface (C,...) EVEN IF I DON'T HAVE TO. Maintenance costs must be kept foremost. Reducing maintenance costs is, after all, one of the major considerations in developing Ada. Let's not spoil this by insisting that every Unix guru learn Ada. Scheduler conflicts (b) remain a problem because Unix processes are not the same as Ada tasks. Several have pointed out that Ada tasks are 'lightweight'; they mean that Ada tasks are represented by different execution threads (instruction pointers and stack frames) but the same data space. At least one Unix vendor has implemented a lightweight process type in the Unix kernel. It is possible that a good solution will be to build an Ada compiler which maps its tasks to lightweight Unix processes, letting the Ada scheduler be either eliminated or vastly reduced. In the absence of this solution, a multi-tasking Ada program must build a monitor to mediate all operating system calls which may 'use up' its most vital resource -- the Unix operating system process. The efficiency with which this may be done is directly related to both the Ada compilation system's (ACS) ability to interface with Unix (see (a)), and the 'goodness' of the Unix in question. Since 'signals' are to Unix more or less what 'rendezvous' are to Ada, the more events which can be propogated to the Ada monitor from Unix via signals, the more efficient the implementation. Broad support for SIGIO seems to particularly help. With current compiler technology, one published result we have obtained is multi-tasking access through sockets within 20% of the performance of a C program using standard fork() and exec() calls. Both applications were able to exchange over 5000 tcp/ip messages per second with a cheap 68020 box. Turning off the time-sliced tasking in the Ada program helped significantly. One other result is that using our Ada abstraction, new employees were able to contribute to our project within one to two days, even with no prior Unix experience. Of course, a C abstraction is possible--but why doesn't anyone use one? A 'today' note: Dennis Ritchie spoke to the FRUUG (Front Range Unix Users Group) last night about 9th Edition IPC. He has developed a different IPC abstraction for his research. In syntax, it is similar to our Ada (and C) abstractions. Of course, it has kernel support :-). There. I feel better now ('thar she blows!) Michael ----------------------- schwartz@pogo.den.mmc.com "Expect everything ... mschwartz@mmc.com and the unexpected never happens." ncar!dinl!schwartz --the phantom tollbooth DISCLAIMER: The opinions expressesed are not necessarily those of my employer or myself. -- ----------------------- schwartz@pogo.den.mmc.com "Expect everything ... mschwartz@mmc.com and the unexpected never happens." ncar!dinl!schwartz --the phantom tollbooth DISCLAIMER: The opinions expressesed are not necessarily those of my employer or myself.