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: 103376,5f8432149982f35e X-Google-Attributes: gid103376,public X-Google-Thread: fca1b,5f8432149982f35e X-Google-Attributes: gidfca1b,public From: Marin David Condic Subject: Re: Ada and QNX Date: 2000/10/16 Message-ID: <39EB662D.F2C8B55B@acm.org> X-Deja-AN: 682202223 Content-Transfer-Encoding: 7bit References: <8r1i82$ri3$1@kujawiak.man.lodz.pl> <8r5pe5$h70$1@nnrp1.deja.com> <8FCDFD7EEnopenopena@63.209.170.206> <39EA6305.CD5CFE1F@ix.netcom.com> <39EA9161.6469DDE2@home.com> <39EB1BA2.B5F2BFDF@acm.org> <39EB283A.9F7B4F76@motorola.com> X-Accept-Language: en X-Server-Date: 16 Oct 2000 20:33:24 GMT Content-Type: text/plain; charset=us-ascii Organization: Quadrus Corporation Mime-Version: 1.0 Newsgroups: comp.lang.ada,comp.os.qnx Date: 2000-10-16T20:33:24+00:00 List-Id: Igor Kovalenko wrote: > Summarizing what you and others replied, it looks like everything is > cool with Ada. Just wondering why it is not yet really resurrected and > blooming and shining in all its glory. > To use an analogy that's been used before: Which is better? Sony's Beta format or VHS? From most technical standpoints, Beta was a better format. Why didn't it catch on? A thousand reasons can be given, but few will be based on some sort of "Technical Superiority" of VHS. I suppose a lot of C programmers don't like Ada because it is strict, disciplined and not as amenable to "clever tricks". I suppose the biggest reason is that Ada is simply not C and people like what they know and hate what they don't know. Since C got out there first and proliferated all over God's Green Acres via Unix, there are a lot of C programmers and they just aren't going to automatically "like" something that is not C or at least C-ish. > > Perhaps my personal doubts aren't that personal, huh? Nobody appears to > write an OS in Ada, being so good for system level work. And by the way, Lots of people have doubts. I don't know many people with reasonable levels of familiarity and experience with Ada who have doubts about the language. Maybe they doubt its usefulness within a specific problem domain or a specific application because experience shows that some other way works better. Example: The kinds of things one might do with a shell script are not the sort of things Ada (or most other compiled languages) are as well suited for. As far as OS work goes, I think we ought to be clear about what we mean when we say "Operating System" or Systems Programming. There are lots of things I would consider to be an "Operating System" that have been written in Ada. Its a very good language for getting down to the bare metal as needed and provides the kinds of features that make building things like schedulers, interrupt handlers, DMA and port I/O access, etc. easy to do. The fact that Unix, Windows, OS/2 and maybe a few other "major" general purpose operating systems are not written in Ada hardly constitutes "proof" that you *can't* write something similar in Ada. It just demonstrates that the people responsible for picking the language for those operating systems didn't choose Ada. The reasons are largely non-technical - reasons like "Ada doesn't exist yet" or "I like C". You could write such an operating system in Ada. There is a group of folks off attempting to do just that - mostly as a labor of love. See: http://www.AdaOS.org/ and find out what they are up to. (Personally, I'd name the OS "Quixote" - but that's my sense of humor at work. :-) > > many people say that GCC does not generate good code for C, so I'm kinda > curious how does GNAT manage to generate good code for such a more > complex language as Ada. Aside from code generation itself, how do they Remember that GNAT is not the only Ada compiler on the planet. I don't have any reason to believe that GNAT is particularly bad at code generation. It certainly makes pretty fast code for most "general purpose" kinds of programming tasks. Is it as highly optimizing as some other compilers? Don't know. Never did a comparison with GNAT to other things because I've not had cause to look at that compiler for purposes of an embedded application. However, I've used other Ada compilers for embedded, hard-realtime applications and found the code generation to be very excellent. The problem with this sort of thing is that the question is just too fuzzy. There's "Ada-The-Language" and there's "Ada-The-Implementation". Some early implementations of Ada were excruciatingly bad - thus all the "Ada-Is-Slow-As-Commanded-By-God" sorts of misinformation that flows from those who either don't know Ada or don't know much about computer languages and compilers. (You never get a second chance to make a good first impression. :-) As people began to understand the language and what it would take to compile it, two things happened: Ada got fast and compiler technology got better. There is nothing inherent about Ada that guarantees it *can't* be compiled to fast code. You do have to know the language to use it efficiently - just as you would need to know C or Fortran to use it efficiently. There certainly isn't anything in Ada to stop you from writing bad code if you don't know what you are doing. Same goes for C or any other language you care to name. Another problem is the question: "Fast at what?" Benchmarking compilers is an extremely tricky business and as anyone who has ever done it can tell you, you have to pick benchmarks that represent the kind of things you intend to do. There is just no way to make a blanket statement that "Compiler A Sucks" without asking the question "Sucks At Doing What?" You can't lay out a broad category like "Sucks At Making Operating System Code" because that covers way too much territory to be of any use. Does it suck at making efficient code for floating point linear computations? Does it suck at making code to move things around in memory? Does it suck at optimizing away hundreds of really small procedures? Seldom will a compiler for any language generate really tight code for all kinds of computations and it isn't often that a compiler will be horrible at *everything* it attempts to compile. > > manage to implement things like rendesvous in an efficient AND portable > way? Such things normally belong to system-dependent runtime libraries, > but in Ada they are part of language and having no proof I nevertheless > suspect that they are implemented by trading efficiency for portability. > Portable in what sense? At the source code level, the standard requires specific behavior that for one target may be easy to implement efficiently and for another target may be difficult to make efficient. Portability at the object code level? That's a real can of worms. Is a rendezvous an inherently expensive operation? It depends. They *can* be costly depending on what you are doing, but the argument in their favor is that of semantic content. For example, it costs more to do a rendezvous that passes parameters than it does to simply synchronize - but go ahead and don't pass parameters and you may find you have to resort to all sorts of other tricks to keep your data from getting whacked in the head, so you spent as much time or more "rolling your own" as you would have by just letting the compiler take care of it for you. In my engine control experience, there used to be a wide spread belief that fixed point math was faster than floating point math - given the presence of native floating point math on the processor. In one sense, this was true. Adding two fixed point numbers would happen in fewer clock cycles than two floating point numbers. But we did a study that ended up concluding that it was a wash. By the time you got done doing the work needed to handle all the scalings and so on, you added about as much workload as you saved. We went to floating point as a result and wached our error rates plument in the process. In other words, we invested some processor time in floating point and reaped a profit. I'd think you could look at things like the rendezvous in the same light. You have to understand what you're doing with parallel programming and understand the best way to get what you want out of it. Its not profitable to look at one mechanism in the language, declare it inefficient or non-portable and be done with it. The question has to be how best to accomplish the job and look at the features you have to get it done. If all you want to do is spawn a subprocess that will work independent of the main process - maybe the best way is with an OS call - or maybe you should use a task with no rendezvous. What is the cost of each? Is it significantly different? Will you end up putting a lot of spackle around the OS call to compensate for the things you *don't* get because it isn't a task? Or maybe they're identical in implementation? You can't tell until you pop the hood and take a look. BTW: Ada will let you do either. > > It could be that I simply don't know enough and miss something. Would be > glad to be enlightened :) > Well, I hope that you'd not take the "defensiveness" we Ada-ites sometimes exhibit as reason to abandon any investigation. We get that way because we often find Ada criticized unfairly because someone heard some rumor or inuendo that has no basis in fact and it upsets us to see what we know to be a useful language getting bashed that way. If you take the time to learn the language and build some non-trivial software with it, I'd bet you would find it has some very useful and unique qualities that could be helpful in developing things you may be involved in. You may still end up liking C better than Ada, but remember that the two languages had entirely different design requirements. Learning Ada might just improve some things about the way you program in C. MDC -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ======================================================================