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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1f7d7b079ba46a43 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-31 15:21:34 PST Path: nntp.gmd.de!newsserver.jvnc.net!news.cac.psu.edu!news.pop.psu.edu!hudson.lm.com!godot.cc.duq.edu!newsfeed.pitt.edu!gatech!gt-news!ccrf-news!ccrf-news!not-for-mail From: jmills@ccrf-news.gatech.edu (John M. Mills) Newsgroups: comp.lang.ada Subject: Re: Ada in Embedded Systems Programming. Date: 31 Oct 1994 09:03:39 -0500 Organization: Georgia Tech Research Institute Message-ID: <392tfr$eng@siberia.gatech.edu> References: <1994Oct27.080032.1@corning.com> <38orsv$1sv@siberia.gatech.edu> <38qt85$as2@theopolis.orl.mmc.com> NNTP-Posting-Host: localhost.gatech.edu Date: 1994-10-31T09:03:39-05:00 List-Id: In article <38qt85$as2@theopolis.orl.mmc.com>, Ted Dennison wrote: >.. I think there is a lot more embedded >Ada programming than you may be aware of. I'm sure there are many I'm unaware of, but it is interesting how many folks suggest that we are pioneers for doing it. Actually we don't use any radical tools, and many better ones [than what we use] are now available. >So what is the problem with Ada for embedded applications? Nothing, if you can afford enough target processor. My point was that more applications would _benefit_ from Ada if some reduced-function compilers could target common microcontrollers and fit executables into a few tens of KBytes of RAM and ROM. You could benefit from the compile-time qualities, if you forwent some run-time features and libraries. >Well, a quick search through the list of validated compilers confirms your >suspicions; I couldn't find any validated 8051 cross compiler. The 8051 is WAY This doesn't explain the ads I see every couple of months for newer and faster 8-bit microcontrollers, including 8051-variants and compatibles, nor the number of ads for cross-compilers (C, of course), emulators, and related tools. The fire alarm/security system just installed in our building uses two 8085 CPUs. Appalling from a technical standpoint, but obviously current technology. (The last 80xx code I wrote was for 8085s, ten years ago. It's probably still running, however.) I would settle for a 16-bit target with small ROM and RAM partitions. I expect the processor chip isn't such a driver as the support silicon. Recently we were asked to identify Ada tools to transition a 16-bit single-card missile telemetry controller from assembly language. After hearing the price, the client was overjoyed to hear about the target memory requirement, since that was so much larger than their hardware, it allowed them to instantly dismiss the expen$ive Ada tools. (Our recommendations matched frequently-given advice here -- don't bother to flame me for not reading the validated compilers list. We also talked to support engineers identified by the vendors.) >Nonetheless, I'm sure someone will port GNAT to it if there is >any kind of demand. I've always thought of FSF and the GNU project as the one successful example of Supply Side Economics! >Cross compiler vendors commonly use a reduced version of the the Ada runtime >(eg: no tasking or dynamic memory allocation/deallocation). Is this the kind >of thing you are thinking of? Yes -- There are probably ways to address this and come out with smaller executables. This problem isn't restricted to Ada -- I managed one project with Intel FORTRAN 77 (extended) on a '286 processor. Our in-house-code size estimates were within about 20%, but Intel's libraries linked about five times what they had estimated for us. Fortunately it was no bell-ringer in that application. Regards --jmm-- -- John M. Mills, SRE -- john.m.mills@gtri.gatech.edu -- (404)528-3258 (voice) Georgia Tech/ GTRI/ SDL, 7220 Richardson Rd., Smyrna, GA 30080 Inez Has Tiny Fuzzy Poodles - II'67