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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac55ec18f7b0a53c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-04 15:28:13 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeed.gamma.ru!Gamma.RU!opentransit.net!proxad.net!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Ada and embedded applications Date: Mon, 4 Jun 2001 18:09:43 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9fh0v9$dob$1@nh.pace.co.uk> References: <9fgnrm$auh$1@nh.pace.co.uk> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 991692585 14091 136.170.200.133 (4 Jun 2001 22:09:45 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 4 Jun 2001 22:09:45 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:8104 Date: 2001-06-04T22:09:45+00:00 List-Id: I have not followed GNORT with any serious use in mind. I can't speak for where that may or may not be. As for exceptions and DOS: That isn't specifically an Ada thing. I've used Ada compilers that targeted bare hardware and used no RTOS other than what they brought to the table. Typically, we turned off most of the run time error checking because of speed issues - but then we were unusually hard on processor budgets. You *always* have to remember that what GNAT does is *not* the same as saying what Ada does - whatever GNAT does for exception generating & handling is not necessarily going to be what all Ada compilers (or even GNAT) will do on all different platforms. As with any other embedded project, you must spend time up front evaluating compilers and vendors against your requirements. Failure to do so can get real expensive. When you talk about budgets, what precisely do you mean? Processor/Memory budgets or actual project $$$ budgets? There is no particular reason you can't do real-time, embedded work in Ada under the same processor/memory budgets as you would have for C. (Availability of compilers may be an issue for a particular processor...) You have to know your compiler and know what parts of it are going to cost you speed/space & try to understand how to work with it to optimize things best. That is the same issue with any language or compiler. For example - tasks are going to force you to have some kind of runtime library overhead plus space & speed. Usually, you can do something about it by simply not using tasks and having the linker eliminate dead code. Sometimes, you may need to tailor the RTK - but that is all compiler dependent. In the case of C you can't decide to *start* using tasks because they don't exist. You'll have to grow your own if your app needs some kind of multi-threading & I'll bet it gets more cumbersome & inefficient than had you just used Ada. FWIW, I've built realtime systems on incredibly small/slow processors using Ada and had to fight for every CPU cycle. I can't give you scientific evidence because we never tried to do it both in Ada and C, but from my experience, I don't think we'd have had any speed advantage using a C compiler. We had a very good Ada compiler and evaluating the code that came out of it, it was hard to imagine getting code that was better for the structures we were using. (Granted, we were using very few features - not lots of tasking (some) or complex data representations or OOP features or anything like that. Math calculations, if checks, data representations using records and not much else.) If you are talking $$$ to do a project, then it gets a little fuzzier. As well you know, GNAT is available at no cost, but you're on your own for support at that price. So is GCC. You can always buy support - sometimes at high prices - for either compiler. RR Software has an inexpensive Ada compiler, but I don't think they target the embedded market - unless your "embedded system" is really a PC running windows - which is a little like cheating. Aonix had a nice embedded Ada compiler for not too many $$$ for a number of targets. Price compared to C? Depends on what you get. There are C compilers given away with development kits for specific board level products. Aonix I think started at around $700 a bunch of years ago and depending on what you wanted, the $$$ went up. But on a product of any significant size, the cost of the compiler was pretty much below the noise level. Green Hills has a compiler with multiple front-ends that will target a number of processors. Essentially, you get Ada or C (or a few other languages) as a choice for the front end & buy basically the same back end & development tools. The cost has got to be roughly the same. I just don't see the costs as being hugely different or even a major concern since you have options in either case. If you've got some teeny-tiny processor you'll probably find that there is no Ada as a choice for it. That's one reason C is so popular with the embedded world. Most SBCs and smaller processors have a C compiler available. Could you get Ada on them? Maybe. Maybe not. Ada *will* have a problem fitting on a lot of smaller processors because if you want it validated, you've got to find a way to get lots of features out of a chip that may not offer much support for them. (Floating point? Context switching for tasks? Lots of things get to be a problem on small chips.) C, lacking much in the way of features and not exactly having validation as one of its strong points, has an easier time fitting on small chips. No floating point support? No problem. Integer-C only. No tasking support? No problem - there are no tasks. That's where Ada is going to have a hard time. But of course, hardware just keeps getting faster, bigger & cheaper, so maybe one day the 16-bit micro-controllers won't be an issue for anybody. (Want to build an embedded controller for a toaster? No sweat! Here's your PowerPC chip with on-board 128 meg of memory for $0.39 in production quantities of ten.) As for moving compilers to new targets - it depends a lot on the compiler. GCC (and by insinuation, GNAT) have a lot of unsupported back-ends out there that target a lot of wierd machines. I don't imagine they'd get so many if customizing the compiler was a horrendously hard effort - or was only easy if you were dealing with C on the front end. I don't think it would take a whole lot longer to build the back end for a new machine with Ada as the front end than it would for C. There would be some runtime library porting that may get a bit bigger with Ada, but the bulk of the work on *any* compiler is not the parsing of the source language, but the generation of code & optimization. If the compiler is set up to be easily retargeted, I don't think the source language is going to matter much. OTOH, if the compiler is itself highly customized to Ada language features, I could see how it might be a bigger job to retarget. The level of effort is going to be really dependent on the architecture of the compiler, not the language. -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Chris Campbell" wrote in message news:XPSS6.23515$HL5.2779772@news6-win.server.ntlworld.com... > > > Ada in general allows compilers to be creative about how they handle the > > implementation of features to be as small and/or efficient as possible. For > > example, GNAT has a version that restricts some features of the language in > > order to be able to go to a "No Runtime" result. (Its called GNORT, in case > > you want to do some searching for info on it.) You lose some features, but > > can make code that doesn't depend on anything but what you provide. GNAT > > itself is available for the cost of a download if you don't need support. > > (Don't know for sure about GNORT.) So I don't think it ought to be a > > budgetary issue. Many embedded projects are using GCC as their compiler - > > GNAT isn't any different in how it can be used. > > GNORT has been discontinued by ACT. Maybe they integrated it into GNAT. > > > > As for exceptions - the space/speed is going to vary depending on the > > compiler. Again, there isn't anything in there that requires megabytes of > > memory or huge processing overhead, but all compilers are different. I think > > you'd find that whatever overhead is there that it isn't excessive - or even > > the biggest ticket item on the list of features. > > I suppose if i could keep exceptions in it'd be good since i'd know where the OS > crashed. Still it I can't since GNAT must use some DOS or windows calls to > display the point where the exception occured. This is really annoying me now. > I didn't even consider exceptions when i settled on Ada for this project but now > i can see they could be benefitial -- In Ada exceptions are always there letting > you know when something goes barmy. > > > > With Ada, if you really need to, you can turn off the standard exceptions > > and if you don't create any of your own, you should impose no additional > > overhead on your program. C gives you no choice in the matter. You have to > > be *very careful* when listening to C programmers talk about Ada because > > usually they base their criticisms on a variety of rumors, FUD, > > misinformation, etc., or a BAD experience with one particular compiler > > developed 15 years ago. (Like getting a BAD meal in a restaurant - maybe it > > was just one bad day for an otherwise good restaurant, but it left a bad > > taste in your mouth and you never go back.) > > That's why i was curious and decided to find out why. I also wanted to put the > guy right if need be. I still can't do that because I still don't know if Ada > is less favoured when budgets are tight. It doesn't seem to me, from what's > been said in this thread so far that exceptions take up that much extra memory > and it shouldn't really matter(but then i've never programmed an embedded device > before). If i were a program developer for a life support machine i'd rather > use Ada than C. If the worst happened and someone died unneccessarily due to a > bug, you'd stand a better chance of finding it with Ada. > > The other reason he gave i tend to agree with: it can be slow to develop > compilers for new processors, but in some ways it can take a while to get a C > compiler for the new processor, Ada however is much more complex than C and will > take more time starting from scratch. > > Out of interest GNAT is based upon GCC i think and GCC compiles things to an > intermediate form -- a RTL -- (is this right?) so all you'd really need to do is > port specific parts of GNAT to the OS if any on the new processor and have a GCC > backend that compiles to that processor. It seems like it really wouldn't take > that long after you've got this. Is my understanding of this all barmy? > > > > > Chris Campbell > > >