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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: f849b,d275ffeffdf83655 X-Google-Attributes: gidf849b,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public From: Marin David Condic Subject: Re: Ada vs C++ vs Java Date: 1999/01/18 Message-ID: <36A3814F.2058C2C2@pwfl.com> X-Deja-AN: 434091046 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <369C1F31.AE5AF7EF@concentric.net> <369D1F2B.138D1FB8@pwfl.com> <369E4A41.8D7DDA14@west.raytheon.com> <369E8081.D4FCFBA9@pwfl.com> <369F911E.8A85D333@west.raytheon.com> Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java,comp.java.advocacy,comp.realtime,comp.arch.embedded,comp.object,comp.lang.java.programmer Date: 1999-01-18T00:00:00+00:00 List-Id: Ken Keys wrote: > > Marin David Condic wrote: > > > Well, that depends on what y'all mean by "an RTOS environment". I built > > a rocket engine control based on a Mil-Std-1750a microprocessor which > > I really meant an OS which has support for tasks/threads independent of > the application program. That would certainly apply to UNIX/VMS/NT, but > I was more interested in cases where there was some incentive to be > small, fast or both which is why I used VxWorks as an example. > Believe me, if we had a commercial RTOS thrown into my little 1750 job, we'd have had no room left for the application! The XD-Ada runtime support for the whole of the Ada language, including the support for all of the tasking, was really incredibly small. The poor little box only had 64k words of memory for the whole job. By the time we were driving an RL10 rocket engine out on the stand, we were up to 90% memory utilization. I doubt we could have tolerated any unused OS routines lying around. It's been said that an elephant is a mouse with an operating system. > > So XD-Ada provided its own built-in RTOS which is pretty common for > > those of us in the bare machine business. A close comparison would be > > So obviously you are not going to bypass Ada and talk directly to the > RTOS. > I'm not sure I understand. There was no RTOS in the sense that most people use the word. Just a small collection of runtime support code to implement the tasking primitives needed to schedule tasks and handle rendesvous. There really wasn't anything to "call directly" - well, I guess we could have connected up to the primitives directly, but why? It's the same call the compiler would generate for you when using the "accept XYZ" statement anyway. I guess I'd apply the same logic if I had an RTOS or a "real" OS like VMS or NT. I could bother to learn all the OS calls to synchronize up threads and pass data between them, etc., but why bother? If the compiler is not a P.O.S., it's going to degenerate the Ada statements into exactly those OS calls anyway, so why go to the trouble and risk of trying to call them directly? > OK, you made me do it. I'm going to toss in a war story of my own. > > Back in the 80's I was involved in a bare metal Ada project. It was > entirely interrupt driven and didn't use tasks as such. Therefore, it is > not directly applicable to the above discussion. However, it involves > some language issues which apply to the outer thread. > > We used the Telesoft compiler which left a lot to be desired. More > important, it was a very Ada-unfriendly design. It was a direct port > from a C program which was in turn a more or less direct port from an > assembly language program that ran on a different processor. As just one > example, the design made heavy use of packed flag words and masks. At > the time Ada did not have a bit wise AND operator, so we emulated the > operation (rather expensively) with bit field operations. > > Not surprisingly, the Ada version was much bigger and much slower than > the C version. (We measured the performance by increasing the input data > rate until the program started missing interrupts.) If I would have had > the leeway (and the time) to make some design changes, I'm sure that I > could have brought the performance of the Ada version more in line with > that of the C version. However, getting the size of the Ada version down > would have required a better compiler. > Nice story. We all enjoy telling them, don't we? The Telesoft compiler was pretty crappy and the folks who were running the show were not doing a good job of customer support. (At least not to *this* customer!) It was many early implementations like this which succeeded in giving Ada a bad reputation. I guess compiler technology sort of had to catch up to the language, eh? At least Ada95 managed to get a good deal of those early Ada83 weaknesses taken care of. Bit level operations, unsigned integers, passive tasks, etc, all went a long way at improving life at the embedded level. While I have not yet acquired any direct personal experience with anybody hawking what would claim to be an "avionics quality" real time Ada95 compiler, I know some people in house who have done some evaluations of what is out there. So far, I have not heard any excessive cursing over the wall about gross inefficiencies, etc. so I'm guessing there are reasonably good quality Ada95 compilers out there for real time work. I know that lots of the vendors have done a good job at optimizing their back ends, and they seem to understand the language well enough that I have heard no complaints about performance from those using compilers on Unix and WinNT systems. I really wish this had been the case in the early days of Ada, but at least we're there now. MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 Ph: 561.796.8997 Fx: 561.796.4669 ***To reply, remove "bogon" from the domain name.*** "Nobody shot me." -- Last words of Frank Gusenberg when asked by police who shot him fourteen times with a machine gun in the Saint Valentine's Day Massacre.