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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f849b,d275ffeffdf83655 X-Google-Attributes: gidf849b,public X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public From: Marin David Condic Subject: Re: Ada vs C++ vs Java Date: 1999/01/14 Message-ID: <369E8081.D4FCFBA9@pwfl.com> X-Deja-AN: 432747142 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <369C1F31.AE5AF7EF@concentric.net> <369D1F2B.138D1FB8@pwfl.com> <369E4A41.8D7DDA14@west.raytheon.com> To: Ken Keys 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-14T00:00:00+00:00 List-Id: Ken Keys wrote: > > Marin David Condic wrote: > > > Not entirely accurate. Ada has the Task construct which allows parallel > > programming without dependence on the specific OS. Typical > > implementations on Unix and WinNT platforms will be via system calls. > > However, since Ada was originally targeted for embedded systems, a > > number of implementations go directly to the bare hardware and the > > implementation's runtime support has to provide the primitives for task > > scheduling, etc. > > I suppose this is terribly off-topic discussing technical details in the > middle of a flame war but... But I was beginning to enjoy the flame war! ;-) I seriously believe that most of the posts of the form "I hear that language X sucks..." or "Which language is better: X or Y?" are really experiments by doctoral students studying abnormal psychology. That, or they are started by someone's artificial intelligence experiment gone haywire. :-) > > Have you (or do you have first hand knowledge of anyone who has) ever > used an Ada Rendezvous in an RTOS environment, such as, say, Vxworks? Or > do you, like everyone I have ever met, use the OS services (semaphores > etc.) directly? 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 had 7 threads of control, 5 of which were tasks. We used Ada entries to initiate aperiodic and periodic tasks, but they were just simple entries, so the rendesvous was the simplest form and not very expensive. The higher speed tasks (1ms, 5ms) had some data sharing or synchronization issues which would have been well served by parameters & the handshaking possible with the rendesvous, but the time was too costly for the poor little 1750a. ****VERY IMPORTANT NOTE!!!!**** Before someone runs off screaming about how this "proves" that Ada sucks, let me state this: We were using ****ADA83!!!**** with the XD-Ada compiler and did not have access to the more efficient constructs of Ada95 (protected types, etc.). So now the situation is a bit different - although I know of no Ada95/1750a compiler and if one exists I have not had a chance to see its code generation. (XD-Ada was pretty good for the type of code we do.) 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 using something like RTEMS with the GNAT compiler, but I've never done any real time work with this setup. I have *never* used an RTOS of the kind that most "real time" programmers are used to (versions of MS-DOS, etc.) I have no objections to these - they just never seem to fit what we do. Basically, we start with the Ada support and build up a real time executive on top of that which allows our logic designers to schedule their workload and have all their I/O handled. This is not the environment most people are familiar with WRT real time. Other controls we have done have had faster processors but used fewer tasks, mostly because they were started a very long time ago before Ada tasking had been reasonably well understood and optimized. We don't have any problems doing tasks, etc. in Ada mostly because we were willing to simply bite the bullet and learn how to use Ada effectively. Most of the folks in our little shop here have grown quite expert in it and have learned to love it over the years. > > > Tasks in Ada provide parallelism in a machine-independent and > > invisible-to-the-programmer manner. I do not know of a similar mechanism > > in either C++ or Java. Maybe it is there. Maybe not. You'd need someone > > else to fill you in on that. > > Java has threads. In C++ it is more of a library issue. The C++ standard > doesn't address it but Posix does. The RTOS probably includes a Posix > library and if it doesn't, it probably doesn't support Ada either. Sorry. I don't know much of anything about "Posix" except that it is generally associated with Unix. We're down at the bare metal with hard real time constraints so we don't have the luxury of a "real" operating system. I hear that most of the Ada implementations that ride on top of something like Unix will use as their underlying implementation of tasking, Posix calls or similar. Still, this supports the point that the language hides all of this from you and does it in a portable manner. > > You need to be concerned with reentrancy and synchronization issues when > you choose a C++ STL library, especially if you plan to use iostreams > or other such goodies. > > KLK Ada subprograms are naturally reentrant (except of course when the programmer does stuff like accessing global memory without appropriate cautions.) and there are mechanisms for handling synchronization, so I kind of enjoy not having to worry so much about it. However one of Ada95's claim to fame is as the "glue" language for interfacing to libraries, etc. in other languages. (I've done some of this with Win32api calls, but not enough to consider myself an expert.) Obviously, when doing this it is wise to know about the calling conventions, etc. of the other language lest you create havoc with reentrancy from multiple tasks. I understand that CLAW - an interface to Win32api built by RR Software - is supposed to wrap the Win32api calls up in appropriate Ada constructs to make them tasking-safe. Something like this might be of value to more than just Ada programmers. 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.